Is there some sort of buffer for status bytes in some instruments?

[leec]

I am trying to obtain the state of an HP8160A Pulse Gen. The status Byte consists of the following:

bit 7 not used
bit 6 SRQ bit
bit 5 Unallowed error bit
bit 4 not used
bit 3downto0 error code

I am not interested in the SRQ bit, just the bits related to the error info. Everything works perfectly for some sequences of data entry. Other times it seems that the status byte's information is lagging behind the actual state of the instrument (which is known from the error display on the front panel of the actual instrument).

My understanding of the status byte is that it is stored in a piece of memory that contains info which is updated as soon as that info changes. When a request for
that info is made, the state the instrument is in should be delivered. Is this not correct? Maybe there is some kind of buffer? Also, my limited experience suggests status bytes are a single byte (8 bits), but the VISA ReadSTB function returns 16 bits. Is this a difference between IEEE 488.1 and 488.2 or could this discrepancy be my potential problem?

If you would like to help but need more details, please ask and I will post them ASAP. I am dried up as far as new ideas goes.

Thank you for any insight,
Chris

PS. I have included the complete llb I am using if anyone is interested. An example of the problem I am having can be exhibited with the follwing sequence:

PERIOD
111
ns
us

This should set the period to 111 ns., giving an error, then clicking the us button next should be an acceptable value and the timing error should no longer be reported.

[mikeporter]

There are two things I can think of off the top of my head: First, your assumptions about how the instrument should work are correct, it's possible though that the microcontroller in the instrument can't keep up with you. I had an instrument once that would occasionally fail because my computer was so fast it would send the command and check for a status change before the instrumnt had time to read the command from it's internal buffer--and that was with LV V1 running on a MacII! Second, it could be that the error has to be explicitly cleared before you go on. I have seen instruments that latch errors. Hope this helps... Mike....

[leec]

Hi Mike,

I thought of the speed issue and tried waiting up to 2 seconds before I sent for the status byte. This did not make a difference. I ruled the possiblity of this being the reason for my troubles.

I also thought of needing to explicitly clear the status byte, but the instrument's manual states:
"Bits 5 and 3-0 are cleared when the erroneous input is corrected". This put an end to the thought of this being the source of my problems.

Let me know if anything else pops in your head.

Thanks,
Chris

[DiegoF]

Hi,

The NI-488.2 driver has Automatic serial polling enabled by default. The driver automatically (when detecting the SRQ) performs a serial poll, read the status of the instrument requesting service and places it in a queue. The Status bytes are retreived using the ibrsp function.

You can disable this setting in MAX, right click on the GPIB interface entry >> Properties >> Advanced tab >> Disable Automatic Serial Polling. Refresh MAX and close all applications using the GPIB driver.

Without automatic serial polling the instrument will continue to assert the SRQ until you explicitly call ibrsp.

DiegoF
National Instruments.

[Dan_Mondrik]

The status byte is something that VISA or other drivers in the chain may cache. Unfortunately, disabling auto-poll in MAX will not solve the problem, because NI-VISA will re-enable it when it feels it is needed. Specifically, it will auto-enable auto-poll when you enable service request events, because that's the only way it can find out about it.

The correct way to clear out the queue is to call viDiscardEvents (in LabVIEW, VISA Discard Events) with the service request event type. This will cause NI-VISA to ensure no latent status bytes with SRQ bit set remain in the cache. This is a good defensive programming technique when you want to ensure a clean start.

By the way, the reason VISA uses a 16-bit type is for backward compatibility with older
Visual Basic (and other) environments that did not support an 8-bit parameter. In reality, you will never get back a response from VISA Read STB with any bit 8-15 set. The format is indeed the 488.x format with which you are familiar.

Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments

[leec]

Thanks for the help Diego and Dan.

FYI
I tried both suggestions, but neither seemed to work. Dan, I guess you are aware that Diego's suggestion would not work, but I thought you may be interested to know the viDiscardEvents did not work either. I only tried it for the default event type (all enabled) though. It did give me the idea to put a bunch of ReadSTB vis consecutively which displayed the cacheing of the status bytes nicely.

In the end, what worked was using a couple of ReadSTB vis and interpreting the output of the last one for my error conditions.

Thanks again,
chris

[Dan_Mondrik]

Chris:

Whether you call viDiscardEvents with the Service Request event type or All Enabled should not make a difference. However, this method only clears out the status byte queue when the SRQ event is actually enabled. It is a no-op if the event is not enabled for that instrument.

Dan Mondrik