Prev: Create a simple standalone ap.
Next: Unable to edit wiki-pages... what's wrong?
From: David Gravereaux on 31 Jan 2010 04:40
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.

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
--


From: Donal K. Fellows on 31 Jan 2010 06:13
On 31 Jan, 09:40, David Gravereaux <davyg...(a)pobox.com> wrote:
> 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.
From: Christian Gollwitzer on 31 Jan 2010 05:47
David Gravereaux schrieb:
> 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
From: David Gravereaux on 31 Jan 2010 06:32
Donal K. Fellows wrote:
> On 31 Jan, 09:40, David Gravereaux <davyg...(a)pobox.com> wrote:
>> 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.


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.

--


From: Uwe Klein on 31 Jan 2010 06:44
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


 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Create a simple standalone ap.
Next: Unable to edit wiki-pages... what's wrong?