some GPIB-tcl questions
in [TCL]
|
From: David Gravereaux on 31 Jan 2010 06:52 Two heads are better than one. Yes, I'd love to see your code. I can't promise much, but I'm a man on a mission. Do you think a device on a bus can be moved to a channel driver and looked at as a stream or are message boundaries important to keep? IOW, streams or messages? I've been out of Tcl for a while... has this streams or messages thing been solved yet? --
From: Christian Gollwitzer on 31 Jan 2010 06:52 Christian Gollwitzer schrieb: > ========================= > load "gpibsrq.dll" > [...] OK, I managed to upload the code to sourceforge: http://gpib-tclsrq.svn.sourceforge.net/viewvc/gpib-tclsrq/ There is also the ready Windows package in "bin" From a quick review, I found the following flaws: 1) The time is queried using a WinAPI function. This is because 8.4 didn't provide high resolution timers. It should be replaced by the equivalent of [clock microseconds], to make it work cross platform 2) The %-substitutions are done by a simple string replacement. I should look it up in the Tk sources, how they do it 3) The callback is run directly in the Tcl_AsyncProc. Instead we should post an event. I suspect this can lead to race conditions 4) The constructor currently accepts many positional parameters with defaults. Instead it should have an interface with options like gpibdevice <devicename> -eof eoftranstaltion -timeout timeout ... This is a SWIG limitation, could be easily done by a wrapper in Tcl Christian
From: Christian Gollwitzer on 31 Jan 2010 07:25 David Gravereaux schrieb: > Two heads are better than one. Yes, I'd love to see your code. I can't > promise much, but I'm a man on a mission. Do you think a device on a > bus can be moved to a channel driver and looked at as a stream or are > message boundaries important to keep? IOW, streams or messages? I also thought about making a Tcl channel, but there is another fundamental reason against it: SRQ does NOT mean the same as "filevent readable". By firing SRQ, a device can signal very different conditions. Usually one can mask these conditions (like "overflow", "button pressed", "fuse destroyed"...) with the "*SRE" command. Even in case that SRQ is configured to mean "got a new measurement", the devices I know expect that you send them a message "give me that value" first BEFORE you read - otherwise the read blocks. E.g. in the example program I attached to my previous message, the protocol is like this: PREMA fires SRQ --> readvalue is called computer writes "RD?" --> prema query "RD?" PREMA writes "24.5�C" --> return value of [prema query] Maybe it is possible to do asynchronous IO, where a read does not block - but that is different from SRQ, and, AFAIR while the computer waits on the answer from that device, no other device can send/recieve anything. > I've been out of Tcl for a while... has this streams or messages thing > been solved yet? I'm not so much into the C side of Tcl, so I don't even understand this question?? Christian
From: David Gravereaux on 31 Jan 2010 07:43 Christian Gollwitzer wrote: ... > Maybe it is possible to do asynchronous IO, where a read does not block > - but that is different from SRQ, and, AFAIR while the computer waits on > the answer from that device, no other device can send/recieve anything. Yes, I'm still the specs and trying to a handle on it. At least for my DMM, a raised SRQ can mean a bunch of things. Only if SPOLL gives back a 132 (10000100h) does it mean a measurement is ready. And there's two ways to actually read. Straight read from the listener for the low precision data or issue a request for the high precision followed by a read. app specific.. sigh. --
From: Donal K. Fellows on 31 Jan 2010 08:26
On 31/01/2010 11:32, David Gravereaux wrote: > I'm digging into the National Instruments driver interface and it > appears to have to been modernized a bit for async notification through > callbacks with ibnotify(). Not exactly a select(), though. Or there's > thread pools on ibwait().. not sure yet what direction to go. If you're stuck with blocking, you're stuck with using a thread to help out. Oh well. (I think you could post events from the service thread that the main thread can listen for, but that's not something I've tried so I can't offer more advice.) Donal. |