From: David Gravereaux on 2 Feb 2010 04:09 Christian Gollwitzer wrote: > ... But be careful with ibrda() ... Why in the world does this type I/O have to be so complicated? It really doesn't have to be. If the talker is ready to be read from, MAV will be set in the device status byte. That's just an SPOLL. I should stop talking and start writing some code. This is 2010.. HP came up with this in '67(?), standardized first in '78, then clarified in 80. There's been THIRTY years to get this right. What the hell? --
From: Uwe Klein on 2 Feb 2010 04:01 David Gravereaux wrote: > 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? > Only worked with the NI one using a transplanted installation. ( And earlier the AT-Bus and PCI Cards from same Manuf.) The NI installer barfs on non supported platforms but you can easily make your own installation bundle from the files. At least for the enet box it works everwhere. I had some issues getting the gpibtcl package to compile. http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/3fb0372a9ae0d7e1 Wrote myself some helper procs .. uwe
From: David Gravereaux on 2 Feb 2010 04:47 Ohhh.. so you're not talking direct over tcp? --
From: Uwe Klein on 2 Feb 2010 05:00 David Gravereaux wrote: > Ohhh.. so you're not talking direct over tcp? No, why should I recreate other peoples good work that hides the underlying ugliness quite well. ;-? I've watched someone writing a driver for the NI GPIB VME Board ~1990. My impression was that GPIB has been the creative playground of obfuscating halfwitted programmers and engineers for ages on the commercial side. Bells and Whistles added as entanglement for the latecomers? uwe
From: David Gravereaux on 2 Feb 2010 06:43
Uwe Klein wrote: > David Gravereaux wrote: >> Ohhh.. so you're not talking direct over tcp? > > No, why should I recreate other peoples good work > that hides the underlying ugliness quite well. ;-? I don't know about "well". I think the whole 488.2 API is ugly. libgpib-3.2 as an example with ibnotify and ibsngl missing and NI's flashing of the bird to Linux in general. They haven't touched their NI-488.2 driver library in 3 years and limit to three distros and there's some issue with kernels greater than 2.4.26 regarding the NI USB devices that require a firmware upload upon connect. Myself, I like LabWindows/CVI. The promise of building a test framework with it and have it run in Linux is basically an unmet promise from them and their runtime restrictions. I'm looking at coding my own ibnotify() as it doesn't look all that hard, thus I can keep the FOSS gpib driver set and use a compatible card. Want to talk about low-level? Examine this: http://lpvo.fe.uni-lj.si/gpib/v1.html Yank the USB chip, drop in an rj45 socket and associated parts. Add in an IP stack to the firmware (memory and probably faster processor too) and split the communication to the devices across different ports with a supervisor port for generating alerts and other ioctl sort of things and should work pretty good and you'd bypass all the old ib* API ugliness in favor of TCP direct. You could probably simplify the entire protocol and even tell the controller on a per device manner to manage RQS with MAB and do the reading of the talkers for you and push it out the port unsolicited the way it should be. I/O wants to be simple. Then package it up in a nice box and sell it for $300 a pop. And make it in China, too. -- |