some GPIB-tcl questions
David Gravereaux
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.
Long story short, the controller stinks. It's based on a
command/response architecture and the world just doesn't work that way,
sorry. SRQ is completely ignored as the hardware interrupt it is by the
CIC. Oh yeah, you can poll it, sure.. Blocking is one thing, but
polling is unacceptable.
Looks like I'll have to go to a National Instruments (or compat) PCI card.
Questions:
1) The 'gpib wait' command is sweet. But that's blocking. Blocking
makes the GUI stick. I hate stuck GUIs. Can tcl level threads be used
for the wait operation or is there an interp association involved?
Yes, use the source luke! I'm entering the learning curve now.. I like
the way it is written in C++ cause I can (used to!?) be able to read
that quite well.
2) Any suggested models of PCI cards for good x-plat driver support?
3) Would it be more proper to look at an open device on the bus as a Tcl
channel? That's just a bit of rewriting of the extension to an
alternate form, right? [fconfigure] is just a general entry to the
specifics a channel driver offers.
# free association fun
set chan [gpib::open 8]
fconfigure $chan -term eio -timeout 1000 -waitcond srq
fileevent $chan readable ...
...
TIA
--
Donal K. Fellows
> 3) Would it be more proper to look at an open device on the bus as a Tcl
> channel? That's just a bit of rewriting of the extension to an
> alternate form, right? [fconfigure] is just a general entry to the
> specifics a channel driver offers.
Sounds reasonable. You could also look into using the [chan create]
operation so that you can do most of the bridging work in Tcl. The
main thing you need for that to work nicely though is the ability to
do asynchronous IO with the device. If you can do async IO and get
events when things are ready to be done, you can do a nice bridge to
Tcl.
Donal.
Christian Gollwitzer
> 1) The 'gpib wait' command is sweet. But that's blocking. Blocking
> makes the GUI stick. I hate stuck GUIs. Can tcl level threads be used
> for the wait operation or is there an interp association involved?
Exactly this is one of the reasons that I decided to unroll my own GPIB
interface to Tcl, which is more object oriented and supports callbacks
on SRQ. An example program, which displays a temperature from a PREMA
diogital multimeter, looks like this:
=========================
load "gpibsrq.dll"
proc pause { ms } {
after $ms { set _ 0 }
vwait _
}
# This callback is invoked, when
# the PREMA fires the SRQ line
proc readvalue {spoll} {
set temp [prema query "RD?" ]
puts "got new value: [expr {$temp}]�C"
}
gpibdevice prema 22
# set temperature measurement&range
prema write "TC A0 F0 T5 Q1 L0"
# ask PREMA to enable SRQ on new value
prema write "*SRE1"
# enable callback on srq event
prema srq {readvalue %s}
pause 5000
prema stopsrq
=======================
Unfortunately, I could not get the hardware working under Linux, so this
extension is only tested on Windows. It should, however, work on Unix
also. The SRQ mechanism is based on ibnotify() and Tcl_Async*. If you
are interested, I can send you the sources. We could also put it on
sourceforge. The code needs some cleanup, though it is used almost
unchanged for 3 years now in our lab to control devices over GPIB.
Christian
David Gravereaux
Thank Donal,
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.
--
Uwe Klein
> 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
David Gravereaux
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?
--
David Gravereaux
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300391571447
It's like $550 new and probably cost $40 to manufacture.
--
Christian Gollwitzer
> =========================
> 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
Christian Gollwitzer
> 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
David Gravereaux
...
> 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.
--
Uwe Klein
I still have a GPIB-AT card in my attic stashed away ;-)
I had these in mind:
http://sewelldirect.com/Prologix-USB-to-GPIB-Controller.asp
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=160398381540
There was one item at ~$100, but that seller
seems to be sold out at the moment.
I found the Ethernet boxes to be the most versatile variety.
But they are so goddam pricey.
uwe
Donal K. Fellows
> 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.
David Gravereaux
> David Gravereaux wrote:
>> I see this and it makes me sick:
>> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=300391571447
>>
>> It's like $550 new and probably cost $40 to manufacture.
> Bend over ;-?
http://lpvo.fe.uni-lj.si/gpib/v1.html
poke 'em back?
don't know if it's usable, though.
--
David Gravereaux
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.
--
Derek
version of the GPIB package
Derek
David Gravereaux
> 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
--
David Gravereaux
...
> 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?
--
Christian Gollwitzer
> 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
Uwe Klein
> 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
David Gravereaux
> 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.
--
Christian Gollwitzer
>>> 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
Uwe Klein
> 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
David Gravereaux
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?
--
David Gravereaux
> ... 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?
--
Uwe Klein
( 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
Uwe Klein
> 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
David Gravereaux
> 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.
--
Uwe Klein
> 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)
Just "wrap" it with one of the cheap small ff ARM Linux boards?
i.e. buy an "Internet Radio" for a limited number of quids.
drop in the usb2gpib thingy and have a
wlan/tcp -> gpib gateway.
uwe
Uwe Klein
David Gravereaux
> http://www.picotux.com/producte.html
That's amazing. I'd need more I/O lines, though. Looks like around 24.
8 for DI0-8, another 8 for the signal lines and another 8 for buss
condition indicators.
--
Uwe Klein
Datasheet for the SOC:
http://www.integral.com.br/images/prd_ds_digiconnectme_nsdata.pdf
looks like one can use PIO for CS.
Got to read up a bit more.
uwe
David Gravereaux
MUX done on a xilinx CPLD or something.
Wait! This looks do-able.
http://www.digi.com/products/embeddedsolutions/digiconnectme9210.jsp#specs
--