From: David Gravereaux on
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
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
Ohhh.. so you're not talking direct over tcp?

--


From: Uwe Klein on
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
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.
--