Experimental Physics and
Industrial Control System

[email protected] (Bill Brown) · Tue, 10 Feb 1998 07:40:31 -0800

> Dear All,

> I'm using EPICS R3.13.0.beta11, MV162, VxWorks 5.2 and
> GPIB-1014 (Gpib-VME by National Instruments).

I'm sorry!  But one must do what one must do.

> I'm testing a gpib device. The rules are two :

> 1) I must use only EOI true for message termination;
OK.  (I think...)

> 2) All data sent to, or read from, the device must be in 
>      binary, not in ASCII characters.
Bummer!  We've got a box that acts like that, except that it doesn't doe EOI
either.

> Now I have a sequence of numbers to execute a device command :
> 30 0 17 0 0 128
> For this test I'm using GPIBInteract, then write:
> \x1e\x0\x11\x0\x0\x80
> but the device don't execute the command (only busy led
> turn on for a second).

> Where is my mistake ?

Well, it's not really your mistake.  The problem is that way down in the
bowels of the device/driver support John used some functions from the string
library.  When it sees a NULL (\x0) in the string being sent it thinks it's
done and stops.  The remainder of the command string goes into the bit bucket.
Our device wanted to see  "\x0" as a command - it simply doesn't work.

A similar thing happens to input strings that include NULL characters.

I spent quite a bit of time trying to figure out a work-around, but never got
a solution.  In our case, we were able to get the manufacturer of the device to
fix it so that he never sent (or expected) a NULL.

Unfortunately the device can't assert EOI, so we have trouble detecting
the end of the message.  There's a bug (or feature, if you prefer) in the
code that swallows the last character when one depends on setting the buffer
size so that End of Message is determined by the buffer being filled.  While
I found several places that needed fixing for the input to work, I never
found all of the places that needed to be fixed.

Most GPIB devices are rather more civilized and only use the ascii characters
in their message format, which is how I believe God & H.P. intended things to
work.  But I could be wrong.

I _suspect_ that all of the implimentations of GPIB interfaces under EPICS will
suffer from this feature.  I haven't tried it on Ben Franksens' HP2050A code,
but I'd be surprised if the device itself can deal with embedded NULLS, much
less the code.  One more thing to add to my list of things to poke at!

> Thanks in advance

You're most welcome.  And if you find a solution, please let the rest of us
know.  Sometimes ya just gotta deal with these uncivilized devices.  Sorry
I don't have a solution.

Disclaimer:  Any opinions are my own and have	    |  -bill
    nothing to do with the official policy or the   |   [email protected]
    management of L.B.N.L, who probably couldn't    |   Berkeley, CA
    care less about employees who play with trains. |   aka [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System