468,133 Members | 1,475 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,133 developers. It's quick & easy.

It's in Python. It just _works_!

A few months back I wrote a sort of a strip-chart recorder
program that talks DeviceNet to a measurement widget and plots
the received data in more-or-less real time using the Gnuplot
module. It was written on Linux system with absolutely no
thought given to portability. It's nothing big (about 650
lines of code).

Today, just for fun, I decide to try to run it under Win32.
After installing the Numeric and Gnuplot modules, I only had to
make 1-line changes to two places in the code, and it started
working.

Apparently, the file descriptor you get from a socket object
under Win32 can't be used with os.read() and os.write()? I
couldn't find anywhere in the docs that said so, but I sure
couldn't get it to work. At least not under WinMe.

--
Grant Edwards grante Yow! RELAX!!... This
at is gonna be a HEALING
visi.com EXPERIENCE!! Besides,
I work for DING DONGS!
Jul 18 '05 #1
13 2583
Grant Edwards wrote:
Today, just for fun, I decide to try to run it under Win32.
After installing the Numeric and Gnuplot modules, I only had to
make 1-line changes to two places in the code, and it started
working.


I was similarly surprised when, after writing ZOE (a simple 3D rendering
engine using OpenGL) for Linux, I decided on a whim to try it on Windows
(since I don't use Windows for anything other than playing games).
After installing PyOpenGL, a fairly involved simulation worked with
absolutely no hitches. In my case, I didn't even have to change one
line of code!

Now, granted, the whole purpose of OpenGL is platform independence. But
my experience has been that hardly matters when you're trying to get
things working on Windows ...

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I can paint a portrait of myself / I will call me a black Mona
Lisa -- Lamya
Jul 18 '05 #2
[Grant Edwards]
...
Apparently, the file descriptor you get from a socket object
under Win32 can't be used with os.read() and os.write()? I
couldn't find anywhere in the docs that said so, but I sure
couldn't get it to work. At least not under WinMe.


Socket handles and file descriptors are disjoint concepts in Windows
(any flavor), and aren't interchangeable in any context.
Jul 18 '05 #3
On 2004-09-03, Tim Peters <ti********@gmail.com> wrote:
[Grant Edwards]
...
Apparently, the file descriptor you get from a socket object
under Win32 can't be used with os.read() and os.write()? I
couldn't find anywhere in the docs that said so, but I sure
couldn't get it to work. At least not under WinMe.


Socket handles and file descriptors are disjoint concepts in Windows
(any flavor), and aren't interchangeable in any context.


I think I knew that at one time. IIRC, Windows was so far
behind the curve when it came to networking that TCP/IP was
implimented by the third-party "WinSock" library duct-taped
onto the side of Windows. Surely MS must have added real
networking support to the OS itself eventually?

--
Grant Edwards grante Yow! Jesuit priests are
at DATING CAREER DIPLOMATS!!
visi.com
Jul 18 '05 #4
Grant Edwards wrote:
A few months back I wrote a sort of a strip-chart recorder
program that talks DeviceNet to a measurement widget and plots

....

Grant, could you say anything about what gadgets were involved
that let you talk to DeviceNet with Python? Did it have a
serial port, or talk TCP directly, or something else?

-Peter
Jul 18 '05 #5
On 2004-09-03, Peter Hansen <pe***@engcorp.com> wrote:
Grant Edwards wrote:
A few months back I wrote a sort of a strip-chart recorder
program that talks DeviceNet to a measurement widget and plots

...

Grant, could you say anything about what gadgets were involved
that let you talk to DeviceNet with Python? Did it have a
serial port, or talk TCP directly, or something else?


I use a USB/CAN interface from PEAK-System Technik GmbH.
[Warning: rather sucky website designed by somebody obsessed
with frames] http://www.peak-system.com/

In the US it's distributed by Grid Connect:

http://www.gridconnect.com/usbcanin.html

I don't have the Python code talking to it under Windows yet
(that's tomorrow's project). Apprently it doesn't come with a
stand-alone Windows device driver, but rather a DLL that you
make calls into to send/receive frames. There are VB example
programs, so I should be able to get Python to talk to it.

In the meantime, the windows app has been talking TCP/IP to a
Linux machine that has the CAN/USB interface plugged into it.
The Linux machine runs a transparent multiplexor program that
allows multiple programs to talk to the USB CAN interface
simultaneously via TCP/IP and/or Unix domain sockets.

[Actually, the windows app was running under WinMe inside a
Win4Lin virtual machine under Linux and talking TCP/IP to the
host Linux OS which has the USB/CAN adapter plugged into it.]

FYI, the Linux driver for PEAK products has two API's for
sending and receiving CAN frames: one uses newline-terminated
ASCII hex strings and the normal read()/write() calls. That's
the one I'm currently using, since it's so easy to multiplex
access and troubleshoot.

If you want to reduce overhead, you can make ioctl() calls to
send/receive frames in binary structures, but that would mean
that my multiplexor program would need to be smarter. Right
now the multiplexor has no clue what the data means or what the
device is, it just shovels newline-terminated strings back and
forth between a file descriptor and some sockets.

--
Grant Edwards grante Yow! I want a VEGETARIAN
at BURRITO to go... with
visi.com EXTRA MSG!!
Jul 18 '05 #6
On Fri, 03 Sep 2004 02:24:23 +0000, Grant Edwards wrote:
I think I knew that at one time. IIRC, Windows was so far
behind the curve when it came to networking that TCP/IP was
implimented by the third-party "WinSock" library duct-taped
onto the side of Windows. Surely MS must have added real
networking support to the OS itself eventually?


Yes, someone had a look at BSD code...

--
Christopher

Jul 18 '05 #7
Grant Edwards wrote:
On 2004-09-03, Peter Hansen <pe***@engcorp.com> wrote:
Grant, could you say anything about what gadgets were involved
that let you talk to DeviceNet with Python? Did it have a
serial port, or talk TCP directly, or something else?


I use a USB/CAN interface from PEAK-System Technik GmbH.

[snip]

Thanks so much for that detailed description! I've
filed it for reference the next time we have to talk
CAN to something, and passed it on to a number of
people.

Our own approach used a CAN4USB device from Zanthic
Technologies, and talked to a Windows DLL using calldll.
We had also experimented with a plug-in card from a
German company (different one, I think), but that
didn't work out as well.

I'm curious if anyone has yet contrived a working
solution for both Linux and Windows... Zanthic
didn't have a Linux driver for theirs, and I don't
know what the API would have been to talk to it
from Linux.

-Peter
Jul 18 '05 #8
In article <41***************@alcyone.com>,
Erik Max Francis <ma*@alcyone.com> wrote:
Grant Edwards wrote:
Today, just for fun, I decide to try to run it under Win32.
After installing the Numeric and Gnuplot modules, I only had to
make 1-line changes to two places in the code, and it started
working.


I was similarly surprised when, after writing ZOE (a simple 3D rendering
engine using OpenGL) for Linux, I decided on a whim to try it on Windows
(since I don't use Windows for anything other than playing games).
After installing PyOpenGL, a fairly involved simulation worked with
absolutely no hitches. In my case, I didn't even have to change one
line of code!


Ditto for a couple of wxPython-based programs that I
wrote on Win32 (I haven't gotten around to installing OpenGL
on my Linux machines.) Handed to the users, who use mostly
OS-X and Linux, the programs did just work.

Regards. Mel.
Jul 18 '05 #9
Tim Peters <ti********@gmail.com> wrote in message news:<ma**************************************@pyt hon.org>...
[Grant Edwards]
...
Apparently, the file descriptor you get from a socket object
under Win32 can't be used with os.read() and os.write()? I
couldn't find anywhere in the docs that said so, but I sure
couldn't get it to work. At least not under WinMe.


Socket handles and file descriptors are disjoint concepts in Windows
(any flavor), and aren't interchangeable in any context.


Not exactly. In WIN32 API WriteFile() one can use SOCKET and file
handle returned by CreateFile(). os.read() uses handles returned by
open(), which on WIN32 are not the same as returned by CreateFile.
Jul 18 '05 #10
On 2004-09-03, Elbert Lev <el*******@hotmail.com> wrote:
Apparently, the file descriptor you get from a socket object
under Win32 can't be used with os.read() and os.write()? I
couldn't find anywhere in the docs that said so, but I sure
couldn't get it to work. At least not under WinMe.


Socket handles and file descriptors are disjoint concepts in
Windows (any flavor), and aren't interchangeable in any
context.


Not exactly. In WIN32 API WriteFile() one can use SOCKET and
file handle returned by CreateFile(). os.read() uses handles
returned by open(), which on WIN32 are not the same as
returned by CreateFile.


That sounds like a bit of mess...

--
Grant Edwards grante Yow! I need to discuss
at BUY-BACK PROVISIONS
visi.com with at least six studio
SLEAZEBALLS!!
Jul 18 '05 #11
On 2004-09-03, Peter Hansen <pe***@engcorp.com> wrote:
I use a USB/CAN interface from PEAK-System Technik GmbH. [snip]

[...]
I'm curious if anyone has yet contrived a working solution for
both Linux and Windows... Zanthic didn't have a Linux driver
for theirs, and I don't know what the API would have been to
talk to it from Linux.


I think there is an enhanced Windows device driver for the Peak
CAN interfaces, but it costs extra, and I'm not sure what
advantages it has over the DLL that comes free with the device.

So far I'm happy with the Peak device, they've been very quick
to respond to questions and suggestions on the Linux driver.
Some of the documentation is in German, but the example
programs are mostly in English.

--
Grant Edwards grante Yow! Is there something
at I should be DOING with a
visi.com GLAZED DONUT??
Jul 18 '05 #12
Elbert Lev wrote:
Tim Peters <ti********@gmail.com> wrote in message news:<ma**************************************@pyt hon.org>...
[Grant Edwards]
...
Apparently, the file descriptor you get from a socket object
under Win32 can't be used with os.read() and os.write()? I
couldn't find anywhere in the docs that said so, but I sure
couldn't get it to work. At least not under WinMe.


Socket handles and file descriptors are disjoint concepts in Windows
(any flavor), and aren't interchangeable in any context.

Not exactly. In WIN32 API WriteFile() one can use SOCKET and file
handle returned by CreateFile(). os.read() uses handles returned by
open(), which on WIN32 are not the same as returned by CreateFile.


Note he said "socket handles" and "file descriptors" while you are
talking about "socket handles" and "file handles". On Windows, file
descriptors exist, but they are just a compatibility layer over some
kind of handle. This compatibility layer is generally fairly limited,
and only allows file descriptors to be used in certain contexts.

If you use the real handles and the real win32 APIs (which you can do
with the pywin32 extension), things are indeed much more consistent.

Jp
Jul 18 '05 #13
Grant Edwards wrote:
That sounds like a bit of mess...


Okay, Grant, now are you actually surprised at that? :-)

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I am still learning.
-- (Michaelangelo's motto)
Jul 18 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Thomas Nücker | last post: by
4 posts views Thread by anonymous | last post: by
2 posts views Thread by Kurt B. Kaiser | last post: by
2 posts views Thread by Steve Doody | last post: by
69 posts views Thread by Edward K Ream | last post: by
27 posts views Thread by scott | last post: by
34 posts views Thread by pamela fluente | last post: by
27 posts views Thread by didacticone | last post: by
1 post views Thread by gcdp | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.