How to configure the GPIB controller in LABVIEW or MAX to send UNLISTEN and UNTALK when each message ends?

[Eyal]

In a PC to PC GPIB configuration, one PC is used as a non-controller and it reads either LACS or TACS status bits continuously. It apears that the controller PC does not send UNTALK and UNLISTEN at the end of each message. The non-controller reads and writes therefor times-out.
What is the correct message synchronisation for a non-controller?
I use Labview 6, PCIIA, WIN98SE.
Thanks.

[Ray K]

See this KnowledgeBase: Computer to Computer Communication via the GPIB
Ray K
NI Applications Engineer

[Eyal]

This publication does not go into my problem. The communication is working correctly as far as described in this publication.
At the non-controller PC, my application program is continouosly monitoring the status bits LACS and TACS in order to act accordingly - read a message from the GPIB controller when LACS is TRUE or write a message when TACS is true.
Initially when the controller is taking charge of the GPIB bus, both bits are FALSE, then after the first operation like ibwrt "hello", the non-controller reads it correctly since its LACS goes TRUE as expected.
However, at this point, the non-controller stays with LACS=TRUE and times-out on the next attempt to read.

How should it turn FALSE?
I assume the controller should have unaddress the non-contr
oller by sending UNL command at the end of ibwrt "hello".
The same problem occurs in the other direction with TACS staying TRUE after the first message.
I use "GPIB Status" function in Labview to read the status bits.

[GPIB_Guru]

Are you using LabVIEW as the controller, non-controller, or both?

NI-488.2 does have a configuration option to enable unaddressing. I am not sure of where it is in LabVIEW, but if you search for unaddressing, you should find some information on it. With unaddressing, NI-488. will unaddress the device after communicating with it.

If you are not using LabVIEW as the non-controller, National Instruments does have a software package called NI-Device that may help. This is an API designed for non-controllers. It does not currently have a LabVIEW interface. It works under C++ with a PCI-GPIB board.

A third option is to rewrite your device application. Your device should really not care about TACS or LACS as you read them from the status register Your device
should only look for LACS, DCAS, and perhaps DTAS (if you desire triggering). When it is LACS, it should read data. After a read has completed, it should interpret the data and get ready for a response. It is only at that moment that the device should look for TACS (and DCAS). It is hard to put a flowchart here, but if you design the flow of a standard instrument, you will see some patterns about when to look for certain status bits.

[Eyal]

I currently use both with Labview, however the final controller is not mine. I am programming the device/non-controller side and use another PC with Labview as a controller to test it.

I tried to assume patterns or sequences of my device, but the controller can issue many random patterns including read sequences and write sequences. I can not deal with just read/write combinations.

I can not find anywhere in Labview or in MAX a way to force the controller to unaddress the device after each message.
Isn't it a requirement of IEEE-488?
As it appears in my tests, it is either the controller not performing unaddressing, or GPIB Status function in Labview on the device side, does not show current and correct status of LACS and TACS.

Many thanks.

[GPIB_Guru]

The host can ask you to talk, but if the device has nothing to say, it can just ignore it. Normally, you would create an IEEE 488.2 instrument, which has defined patterns (including only reading data from an instrument after you have sent it a request for the data).

You should program your instrument driver using VISA (I would create an instrument driver for your device to guarantee that it is communiated to using unaddressing). If you create a VISA property node, one of the GPIB options is unaddressing. Wire a true to this node when configuring the device.

[Eyal]

I have tried many combinations (with standard Labview GPIB vi's and with VISA) but ended up with the following problem:
The noncontroller device has a report message that it sends when addressed as a Talker. To send this report, it does not require a prior command. The problem is how to differentiate between succesive report requests, e.g. succesive Talker states.
I tried monitoring the state of the ATN line, assuming that if the ATN is asserted and then unasserted by the controller, the TACS bit at this point should indicate whether my device is the current Talker on the bus. This procedure works except Labview seems to miss occasionally the changes of the ATN line.
A similiar problem occurs with successive commands my device has to deal w
ith, since the only way I found to distinguish between successive Listen requests is again by monitoring the ATN line as I described above.

It looks like a GPIB status such as "bytes in" or "byte out" could help, like the serial port "Bytes At Port" VISA property. Another help could be if the device could reset it's TACS and LACS bits as a result of the "End of Message" (EOI) signal.

[Michael Wade]

I have exactly this problem. Did you ever find an answer? According the the document you were told to reference (which I read also) one is supposed to monitor the LACS line ( with !ATN ). But once the CIC addresses the NonController to listen, it never addresses it to unlisten. I am using Borland C++ Builder on both sides and it is driving me nuts. The ( ibsta & LACS ) end up in permenant loops, or at least until the CIC addresses someone else to talk. This is frustrating and I don't know where to go to find help. If you have any suggestions, I sure would appreciate them. Thanks, Michael

[Eyal]

Michael,
I just noticed that you commented on this GPIB problem, since I gave up and did not check this correspondence for a long time.
If it is still interesting, I still use short timeout of 25msec on GPIB commands and simply retry to send or receive a string continuously. TACS and LACS are only used to select whether to talk or to listen.

It could be helpful if National Instruments can provide a correct method of implementing a GPIB device using Labview or even MAX / GPIB Interactive Control tool, that does not rely on timeouts.
Eyal