some GPIB-tcl questions
in [TCL]
|
From: Uwe Klein on 1 Feb 2010 17:27 Derek wrote: > The USB to GPIB devices from NI seem to work ok with te windows > version of the GPIB package And they are about as pricey as a GPIB Enet box. Nothing gained. uwe
From: David Gravereaux on 1 Feb 2010 18:31 Christian Gollwitzer wrote: > 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/ Yes, it's there, but I can't use that library. I run a 2.6.x kernel, amd64, and that's not a debian package. I could probably convert it with the alien tool, but being 32-bit it might not even work given the kernel level parts. > and concluded that it should be there and used instead of the older > ibsgnl(), which fires a unix signal. Do you have ibsgnl? No idsgnl() either. http://linux-gpib.sourceforge.net/doc_html/index.html http://osdir.com/ml/linux.hardware.gpib.general/2004-07/msg00011.html ^-- and that's from 6 years ago. >> 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. Whether I do it or they do it, what's it really matter 'cept for the debugging work to make sure I got it correct? idrda with the ibwait in a service thread might suffice and operate it overlapped... but I really just want an SRQ as my notice that the device needs attention. Yes, it's board-level and I'll have discover the culprit, but isn't that just FindRQS()? I'm still a newb to this, so I might have this all wrong. > <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> The whole patent system is amusing in a sad way. I think a year ago or so, someone patented the bubble sort algorithm. The system is totally crazy. You can even patent an electronic topology. I want to see if I can patent the long-tail pair! Prior art be damned! I hear patent troll companies are doing well for themselves. --
From: Christian Gollwitzer on 2 Feb 2010 02:56 David Gravereaux schrieb: >>> 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. > > Whether I do it or they do it, what's it really matter 'cept for the > debugging work to make sure I got it correct? > > idrda with the ibwait in a service thread might suffice and operate it > overlapped... but I really just want an SRQ as my notice that the > device needs attention. Yes, it's board-level and I'll have discover > the culprit, but isn't that just FindRQS()? I'm still a newb to this, > so I might have this all wrong. You are right, I forgot on these multidevice functions. But be careful with ibrda(): AFAIK, when you read asynchronously on a device with ibrda(), you cannot write to it to make it give an answer! It only keeps your mainprogram going, but you may only invoke it, when you know, that the device is really going to send anything. I think it is also not possible to ibrda() simultaneously on more than one device. Christian
From: Uwe Klein on 2 Feb 2010 03:24 David Gravereaux wrote: > Yes, it's there, but I can't use that library. I run a 2.6.x kernel, > amd64, and that's not a debian package. I could probably convert it > with the alien tool, but being 32-bit it might not even work given the > kernel level parts. That was another reason to prefer the -ENET boxes. No kernel level stuff. NI would not port their software away from 32bit x86. Probably the same high quality professional proprietery software problems Adobe has: A partly dried heap of fungoid spaghetti code. uwe
From: David Gravereaux on 2 Feb 2010 03:42
Uwe Klein wrote: > David Gravereaux wrote: >> Yes, it's there, but I can't use that library. I run a 2.6.x kernel, >> amd64, and that's not a debian package. I could probably convert it >> with the alien tool, but being 32-bit it might not even work given the >> kernel level parts. > > That was another reason to prefer the -ENET boxes. No kernel level > stuff. NI would not port their software away from 32bit x86. > Probably the same high quality professional proprietery software > problems Adobe has: > A partly dried heap of fungoid spaghetti code. > > uwe Enet boxes are preferred especially given multiple boxes around the shop. I totally agree, but I just tried one that stinks. The Prologix one is awful. SRQ is ignored as an interrupt and you have to poll it. EEwww! What ones do you like? -- |