It's in Python. It just _works_!

[Grant Edwards]

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.

 

[Erik Max Francis]

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 ...

 

[Tim Peters]

[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.

 

[Grant Edwards]

[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?

 

[Peter Hansen]

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

 

[Grant Edwards]

...

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.

 

[Christopher Koppler]

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...

 

[Peter Hansen]

>
> 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

 

[Mel Wilson]

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.

 

[Elbert Lev]

[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.

 

[Grant Edwards]

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]

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.

 

[Jp Calderone]

[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

 

[Erik Max Francis]

That sounds like a bit of mess...

Okay, Grant, now are you actually surprised at that?