Experimental Physics and
Industrial Control System

[email protected] (Bill Brown) · Wed, 23 Apr 97 09:52:32 PDT

We have this really cranky TWT amplifier that we're trying to monitor via
GPIB.  I won't go into all the details, but it has got to have one of the
three most unfriendly message formats imaginable.

One of its' features is that it doesn't assert "end-of-message" at the end
of each status message, which gets sent as the result of a "READ" operation.
Neither does it terminate the message with a <CR>, and it sends data in a
binary format, so even if it did one couldn't be sure that it's really
the end-of-message character.

The good news is that the message is always _exactly_ 17 bytes long.  The
bad news is that the 17th byte is somehow being eaten by the combination
of the GPIB Interface and DMA chips on the NI-1014.  Well, actually, I
think it's being placed in the buffer as a null, but I have no proof of
this.

We've been attempting to deal with the problem by making the length of the
devices' read buffer exactly the same length as the message.  As it turns
out, the device support was broken such that the last character would
always get written over by the null which it appends to the end of the
message, which is passed up from the GPIB driver via the devGpibCommon
stuff.  We fixed that.

That didn't fix the problem.  To make a long story short, I can see the
17th byte get transfered on the GPIB bus by watching it with a GPIB
analizer, but it doesn't get put into the buffer by the driver.

Has anyone tried (successfully, one would hope!) to do this?  Clearly,
depending on the byte-count to terminate the read is not a nice thing to
do, but we don't have a lot of choice.  I can understand why it was never
tested; in fact John may never have intended it to work the way I'm
trying to use it.

Any insights will be greatly appreciated.

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