This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCD3E65980A2E572FDFC37EEB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=
=2E

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



--------------enigCD3E65980A2E572FDFC37EEB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlUCMACgkQlZadkQh/RmFFtwCfdCYaZzRClrJxMvdsaz6fKbgN
EzsAnRxKXox1H+E5FV/w4y1Un5jdnnWD
=caMh
-----END PGP SIGNATURE-----

--------------enigCD3E65980A2E572FDFC37EEB--

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

On 31 Jan, 09:40, David Gravereaux <davyg...@pobox.com> wrote:
> 3) Would it be more proper to look at an open device on the bus as a Tcl
> channel? =A0That's just a bit of rewriting of the extension to an
> alternate form, right? =A0[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.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11A43B56847E71F6C3AAFCB1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Donal K. Fellows wrote:
> On 31 Jan, 09:40, David Gravereaux <davyg...@pobox.com> wrote:
>> 3) Would it be more proper to look at an open device on the bus as a T=
cl
>> 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.
>=20
> 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.
>=20
> 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.

--=20



--------------enig11A43B56847E71F6C3AAFCB1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlalkACgkQlZadkQh/RmE0NQCgpWSGwlpm83DHn5Iquio0lyHn
gusAn3Rjvz38X5lO40OlCIEQ2foeJDk+
=JSK8
-----END PGP SIGNATURE-----

--------------enig11A43B56847E71F6C3AAFCB1--

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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9766CF57B009AAB54FDB2A1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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've been out of Tcl for a while...  has this streams or messages thing
been solved yet?

--=20



--------------enigB9766CF57B009AAB54FDB2A1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlbvQACgkQlZadkQh/RmH/qQCfWe/5XlW/e+fNkhVmGXSiBsfm
w3sAmwZWXY4mRNtbaXYRUVHVvNh3gCV+
=Bfao
-----END PGP SIGNATURE-----

--------------enigB9766CF57B009AAB54FDB2A1--

Christian Gollwitzer schrieb:
> =========================
> 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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3E48BC65E5C0B071C1CD7227
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I see this and it makes me sick:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3D300391571447

It's like $550 new and probably cost $40 to manufacture.
--=20



--------------enig3E48BC65E5C0B071C1CD7227
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlctAACgkQlZadkQh/RmFAlQCeMu95LfHB5q3hSKm36ObN6lcW
AywAoPA7/+L31476jMjgKSW8j1O3QTPn
=m9ao
-----END PGP SIGNATURE-----

--------------enig3E48BC65E5C0B071C1CD7227--

David Gravereaux schrieb:
> 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 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 ;-?
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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5793F9A51132523780FD0A43
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Christian Gollwitzer wrote:
=2E..
> 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 o=
n
> 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 re=
ad.

app specific..  sigh.
--=20



--------------enig5793F9A51132523780FD0A43
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlewQACgkQlZadkQh/RmHodQCg1X9bf98sEXxCwdPzJ9GPp0Cl
ZLQAoPEmoQEIbGQIWbQLmejn1HU7oLwf
=BP4L
-----END PGP SIGNATURE-----

--------------enig5793F9A51132523780FD0A43--

On 31/01/2010 11:32, David Gravereaux wrote:
> 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.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2109A5A6CEC061CB1A44409E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Uwe Klein wrote:
> David Gravereaux wrote:
>> I see this and it makes me sick:
>> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3D300391571447
>>
>> 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.
--=20



--------------enig2109A5A6CEC061CB1A44409E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktlhpoACgkQlZadkQh/RmGiWQCeIf4sT4ZKXu0qCbHi8BdzZz1j
mfYAn2wytyUJf9lVYcavG3meN7tmOV8N
=TKcR
-----END PGP SIGNATURE-----

--------------enig2109A5A6CEC061CB1A44409E--

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig328B28DA522A6907508C4B30
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

David Gravereaux wrote:
> Christian Gollwitzer wrote:
> ...
>> Maybe it is possible to do asynchronous IO, where a read does not bloc=
k
>> - 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=
=2E
>=20
> 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.
>=20
> app specific..  sigh.


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.
--=20



--------------enig328B28DA522A6907508C4B30
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktmC+IACgkQlZadkQh/RmHf4wCgwaaNO4Ur2s6V5sBsASqcR5kY
+ToAoNPuilZ7GzZbeSY1JMgqOI7QD6RP
=95Nu
-----END PGP SIGNATURE-----

--------------enig328B28DA522A6907508C4B30--

The USB to GPIB devices from NI seem to work ok with te windows
version of the GPIB package

Derek

On 31 Jan, 11:44, Uwe Klein <uwe_klein_habertw...@t-online.de> wrote:
> David Gravereaux wrote:
> > Hi all,
>
> > First, it's been a while since I've done any serious goofing around wit=
h
> > 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. =A0And 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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA750733AEF28B5ECD7FF74AA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Derek wrote:
> 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

--=20



--------------enigA750733AEF28B5ECD7FF74AA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktnJGAACgkQlZadkQh/RmGNFQCfafaat4qydcYB8XO6pXHQ9Dzm
iwMAn13zC/u7tMtH/Z9ZNbRiO8hUQ1NK
=1ULQ
-----END PGP SIGNATURE-----

--------------enigA750733AEF28B5ECD7FF74AA--

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF83B512AEACBAEA16ED59885
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Christian Gollwitzer wrote:
=2E..
> 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?
--=20



--------------enigF83B512AEACBAEA16ED59885
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktnNrkACgkQlZadkQh/RmHKXwCdGB1O+9yFOUWnn6R4AU1LFfGB
Kh0AmwYo6HlAqqzezWssFbaHWFzKV62G
=S1dN
-----END PGP SIGNATURE-----

--------------enigF83B512AEACBAEA16ED59885--

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/

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

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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB2337EE56BD5EECE7E00121E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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>
>=20
> awkward. Before using ibnotify(), I read this:
>=20
> 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.htm=
l
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, bu=
t
>> I'm on 64-bit debian based..
>>
>> I'm not sure what to do.  There's always WaitSRQ() in a service thread=
?
>=20
> OK that should be straight-forward.... maybe one should use ibwait(), I=

> don't know. ibnotify() also has the nice feature, that it identifies th=
e
> 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 t=
o
> 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.

--=20



--------------enigB2337EE56BD5EECE7E00121E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktnZDkACgkQlZadkQh/RmEQPACeLIOn5lYNuHwcjrUoObTyDvo3
fhQAoJVYU7kmhjIcBHhKUrSrNpLIFQWE
=81vq
-----END PGP SIGNATURE-----

--------------enigB2337EE56BD5EECE7E00121E--

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

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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig02BC4C4E64F55BB1D7E34225
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.
>=20
> 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?

--=20



--------------enig02BC4C4E64F55BB1D7E34225
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktn5XMACgkQlZadkQh/RmEsRACfQ81YyTvvanbsITUQGg8h7aC8
KPQAnjAQMZWRW69p9Q4sn1CzPpeyarVW
=d1V7
-----END PGP SIGNATURE-----

--------------enig02BC4C4E64F55BB1D7E34225--

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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9E682AA8C610D8F43455145A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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?
--=20



--------------enig9E682AA8C610D8F43455145A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktn68UACgkQlZadkQh/RmExlgCePBQJX+APk/tbxFlEB13XV9ik
AugAn3VExvPYRyxZmRdI+xbRH2qHJ10o
=ZYTz
-----END PGP SIGNATURE-----

--------------enig9E682AA8C610D8F43455145A--

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC60DB91CC9AC8BDB537F3FFD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ohhh..  so you're not talking direct over tcp?

--=20



--------------enigC60DB91CC9AC8BDB537F3FFD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktn9JoACgkQlZadkQh/RmFHkQCfYhtZuKGXqNo5Mya84VvauFAr
icUAoOGElyHxIuW3WMHi8pgX+Ib4FDMp
=/OUv
-----END PGP SIGNATURE-----

--------------enigC60DB91CC9AC8BDB537F3FFD--

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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4B7CC3A5BE184431954F6A87
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Uwe Klein wrote:
> David Gravereaux wrote:
>> Ohhh..  so you're not talking direct over tcp?
>=20
> 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.
--=20



--------------enig4B7CC3A5BE184431954F6A87
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktoD/cACgkQlZadkQh/RmHnIwCfcA8TmAlfaSD1aTJueWNEUysZ
n80AnArNzhQlj3q+mUuPH30ijhEVgpLD
=Z/wo
-----END PGP SIGNATURE-----

--------------enig4B7CC3A5BE184431954F6A87--

David Gravereaux wrote:
> 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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6D5733F0BF1F74C96627302A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Uwe Klein wrote:
> David Gravereaux wrote:
>> 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)=

>=20
> 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.

Now you're talkin' ;)

--=20



--------------enig6D5733F0BF1F74C96627302A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktoH6sACgkQlZadkQh/RmEK3wCgmfv5QNyC8a9LqwP3yvMaiPik
GyYAnAgaW/sW1lKmGkiZRHPqqIPKKoN4
=Ac4o
-----END PGP SIGNATURE-----

--------------enig6D5733F0BF1F74C96627302A--

David Gravereaux wrote:
> Uwe Klein wrote:
> 
>>David Gravereaux wrote:
>>
>>>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.
> 
> 
> Now you're talkin' ;)
> 
http://www.picotux.com/producte.html

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig979D7A2CD401BE873BFBAE6A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Uwe Klein wrote:
> 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.
--=20



--------------enig979D7A2CD401BE873BFBAE6A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktojFwACgkQlZadkQh/RmGcUgCePblI8t0rIVoKi8QS9HZ3kRQg
kAwAoJ2HE2TciCZ/mM7RkV77XDlnONBe
=XgTl
-----END PGP SIGNATURE-----

--------------enig979D7A2CD401BE873BFBAE6A--

David Gravereaux wrote:
> Uwe Klein wrote:
> 
>>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.


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

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7465CA93D8FFBC5BB3944576
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'd think the serial lines could be I2C(?)  I'd just need some simple
MUX done on a xilinx CPLD or something.

Wait!  This looks do-able.

http://www.digi.com/products/embeddedsolutions/digiconnectme9210.jsp#spec=
s
--=20



--------------enig7465CA93D8FFBC5BB3944576
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktolb4ACgkQlZadkQh/RmH1vQCbBcJpiECeqM8f44xnKj6PIjaj
KTQAn1qMbR7Cmb/t4rsxPBIlyLS5HW8I
=SoRK
-----END PGP SIGNATURE-----

--------------enig7465CA93D8FFBC5BB3944576--