some GPIB-tcl questions
in [TCL]
|
From: David Gravereaux on 31 Jan 2010 18:01 David Gravereaux wrote: > 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. I was just thinking about this and SRQ is still the perfect notification mechanism. It's what one does in the readable handler script that counts regarding the personality of the device. background reads could be done, though, from a service thread. It's not unsurmountable. We could just notify ourselves when done with a filled buffer instead of an epoll mask. --
From: Derek on 1 Feb 2010 08:59 The USB to GPIB devices from NI seem to work ok with te windows version of the GPIB package Derek On 31 Jan, 11:44, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote: > David Gravereaux wrote: > > Hi all, > > > First, it's been a while since I've done any serious goofing around with > > Tcl and am pleased to have a use for it again. > > > I've had old Tektronix DM5010 DMM > > <http://bama.edebris.com/download/tek/tm5006/tek-tm5006.pdf> for a > > couple years, but just a few weeks ago I finally got a TM5006 mainframe > > to plug it into. And just today got a Prologix <http://prologix.biz/> > > GPIB-ETHERNET controller in the mail. > > I've been using the GPIB-Enet box from NatInst. > via the provided linux libs and a tcl package wrapper. > > Works very well. But the box is hideously expensive :-( > So makes only sense if someone else ( like a customer ) > pays the bill ;-) > > Various PCI Cards seem to work ( to various levels ), > never tried due to the requirement for a laptop as host. > > My current idea of a workable cheap way was going via > one of the usb_serial to gpib converters ( go for ~100$ ) > > uwe
From: David Gravereaux on 1 Feb 2010 13:58 Derek wrote: > The USB to GPIB devices from NI seem to work ok with te windows > version of the GPIB package at $550, they're a bit expensive. The ones from AdLink are $350. The best cost effective method seems to be used PCI cards off eBay for around $100 --
From: David Gravereaux on 1 Feb 2010 15:16 Christian Gollwitzer wrote: ... > It should, however, work on Unix > also. The SRQ mechanism is based on ibnotify() and Tcl_Async*. ibnotify() is not included with the standard (FOSS) Linux library for gpib. It's probably not there because ibnotify() is patent encumbered <http://www.patentstorm.us/patents/5974541/description.html> There's an older NI build of their 488.2 library for 32-bit RedHat, but I'm on 64-bit debian based.. I'm not sure what to do. There's always WaitSRQ() in a service thread? --
From: Christian Gollwitzer on 1 Feb 2010 16:35
David Gravereaux schrieb: > Christian Gollwitzer wrote: > ... >> It should, however, work on Unix >> also. The SRQ mechanism is based on ibnotify() and Tcl_Async*. > > ibnotify() is not included with the standard (FOSS) Linux library for > gpib. It's probably not there because ibnotify() is patent encumbered > <http://www.patentstorm.us/patents/5974541/description.html> awkward. Before using ibnotify(), I read this: http://ftp.ni.com/support/gpib/linux/2.3/ and concluded that it should be there and used instead of the older ibsgnl(), which fires a unix signal. Do you have ibsgnl? > There's an older NI build of their 488.2 library for 32-bit RedHat, but > I'm on 64-bit debian based.. > > I'm not sure what to do. There's always WaitSRQ() in a service thread? OK that should be straight-forward.... maybe one should use ibwait(), I don't know. ibnotify() also has the nice feature, that it identifies the device for you. In the old-fashioned way, you need to spoll() every device on the bus in order to determine, which one holds the SRQ line. <rant> Why on earth is this stupid thing patentable? Where is the difference to a standard mechanism about intercepting hardware events, or maybe unix signals (man 3 signal), which exist at least since System V7, 20 years before that stupid patent? Yes, of course, the event source is a GPIB controller. wow THAT is the difference. Haha. </rant> Christian |