What is the best way to monitor GPIB bus activity from LabVIEW?

[Chris_K.]

I have an existing system of 4 stations each with multiple GPIB-controlled instruments.  My goal is to set up another PC and independently monitor these systems for percent usage.  I do not want to modify the existing stations in any way, I only want to tap into the GPIB bus and monitor the traffic to determine how much they are being used.  The presence of GPIB traffic will indicate the stations are being run.  In addition to monitoring the presence of traffic, I also would like to capture the data on the bus and parse it for certain messages.  Basically I want to determine if the down time is caused by an operator abort or instrument errors. 

I looked into using the GPIB analyzer card (PCI-GPIB+) which is capable of capturing the GPIB traffic in great detail.  The difficulty for me is that the software interface to this card is a standalone application (GPIB Analyzer) without an API for me to access from LabVIEW.  Does anyone have experience with this application and controlling it externally?  I emailed NI support and they told me that there is currently no API available, however I wonder if there is another less obvious method for interfacing to it. Possibly by using the ActiveX interface to MAX?  Any suggestions or alternate approaches are welcome.  Thanks!

[Collin M]

This would be difficult to do with a GPIB analyzer because the analyzer has no API, as you stated.

There is a configuration setting, IbcLON, that forces a board to be a listener. The board will remain a listener regardless of addressing commands sent by the GPIB controller. You may be able to set this configuration and then do continuous GPIB reads (ibrd). You should make sure the you will terminate the read based on any possible END message the instruments or controller could send. You should also always do a read of more than the expected longest message.

One thing to be aware of is that in this mode the GPIB monitor is participating the GPIB handshake and can therefore holdoff of stop a data transfer. That is why you must always read at least the number of bytes expected in the longest possible message and terminate the read on any possible END message. This will also ensure coherancy in your reads.

The monitor may introduce some latency while it is processing the messages. Also, if a GPIB instrument were to fail, writes to the instrument would still appear to work because the monitor would be accepting the bytes.

I've never tried this before but don't foresee why it wouldn't work.

[Chris_K.]

So in this scenario, I would not need the analyzer card, only the standard GPIB controller card? And it should work from a separate PC, not the one that is currently controlling the system?

By END message, do you mean a termination character such as <CR>?  I also wonder about how I can make the read byte count large enough if one of my instruments returns a large array of data.  I don't know all the details of the system I am monitoring and think it may be difficult to find out with certainty the size of the largest message.

[Collin M]

>So in this scenario, I would not need the analyzer card, only the standard GPIB controller card? And it should work from a separate PC, not the one that is currently controlling the system?

Yes, that is correct. I don't know of a way to use the analyzer in a programmatic way.

>>By END message, do you mean a termination character such as <CR>? 

Yes, the END message can be a character such as <CR> or the GPIB EOI signal.

>>I also wonder about how I can make the read byte count large enough if one of my instruments returns a large array of data.  I don't know all the details of the system I am monitoring and think it may be difficult to find out with certainty the size of the largest message.

The issue here is coherency. When you do a GPIB read using an ibrd, you must specify a count. The read will complete once the END message is detected or count is reached.

Assume you have a loop on the GPIB monitor that does reads of 100 bytes. Assume an instrument sends 120 bytes. The monitor would capture the entire message but it would be split between two different reads. You would have to use some other means to reconstruct the message. You can probably do so but using a very large count for ibrd seems easier. If the data transfer can be arbitrarily large with no fixed upper limit you may have to spit it up among multiple reads. The GPIB transfer will stop between reads from your monitor. It will resume when the next read starts. This probably won't affect the overall operation of the system but there is a possibility.

Maybe one of the software folks has some comments about this.

[Chris_K.]

Thanks for the information, Collin.  It sounds like I may need to test this to find out if there is any effect on the system such as latency or missed messages between instrument and controller. 

Another possibility I considered would be to use the GPIB Analyzer card and software and configure it to log continuously to a file.  My application can then parse the file to determine percent utilization.  The question is if the GPIB Analyzer software can be configured to log to file and if so does the log file include timestamps.

[Collin M]

I haven't used an analyzer in a while but don't believe you can log directly to a file. You can manually save a capture to a file but that probably would not be useful. Can someone confirm that is correct?

You shouldn't ever miss any messages on the bus when your monitor is in listen only mode as I described earlier. In this mode the monitor will simply hold off data transfers if it is not ready, even if the instrument is ready. The implication is that the overall transfer rate may slow down if the monitor can't keep up with the instrument.