NI-VISA Bug – setting timeout on GPIB instr resource clears STB

[Sebastian1516]

Hello,

I run into this strange issue/bug  while switching from Agilent to NI VISA. For some reason modifying timeout on the GPIB instrument resource causes status byte (STB) on that instrument to be cleared. Setting timeout without changing the value does not cause the problem. Modifying timeout should NOT perform any I/O or clear STB cached by auto polling.   

Here are the basic steps to reproduce the issue (> indicates writing and < indicates reading):

Timeout set to 200 ms.   

>*CLS;*SRE 32;:INIT:IMM;*OPC

<STB: 96

<STB: 32

>*CLS;*SRE 32;:INIT:IMM;*OPC

Timeout set to 200 ms.   <------- Setting timeout to the same value does not cause the problem

<STB: 96

<STB: 32

>*CLS;*SRE 32;:INIT:IMM;*OPC

Timeout set to 1200 ms.

<STB: 32                      <----- This should be 96 but was cleared on previous line

<STB: 32

 I have attached full NI IO Trace (with actual function calls) of the above.

I have tried several instruments and the problem appears on all of them (note: measurement was completed before any attempt to set timeout and read STB was made).      

Agilent VISA and hardware in this case work correctly by maintaining STB value until it is read out with viReadSTB.

Note: disabling auto polling in MAX does not have any effect. As soon as I enable events (omitted here for clarity) auto polling is performed regardless of the setting in MAX. Apparently this applies only to NI 488.2 API or is simply broken.

Another funny thing is that if another instance/process opens handle to the same instrument resource (without actively communicating with the instrument) the problem goes away.

Rearranging the sequence of triggering, setting timeout, and reading STB is not a viable workaround for me.   

Here are the details of my setup:

Win 7 x64

NI-488.2 v3.0.2

NI-VISA v5.1.1  (tried v5.1.2 – same thing)

GPIB interface: NI GPIB-USB-HS

The application using NI-VISA runs in the 32-bit mode.

Please fix this in the next rev, so I can switch to NI-VISA.

[Courtney_L]

Hey Sebastian 1516,

Thanks so much for posting these detailed steps to reproduce this issue. I'm going to try to replicate this issue, and I'll let you know if I require any additional information.

[Sebastian1516]

Hi Courtney,

Have you been able to reproduce the issue?

I tried rolling back to NI-488.2 v2.73. This version has the same problem.

Thanks,

Sebastian

[Courtney_L]

Hey Sebastian,

Thanks for that additional information. I've done some preliminary testing and research on your issue, and as a result I've brought this thread to the attention of our VISA team here. I will keep you posted as to what I find out!

[Sebastian1516]

Hi Courtney,
It has been a while and I did some more investing. I’ve tried using NI GPIB PCI card and I see the same behavior. STB is cleared as soon as timeout is modified.

Disabling auto polling in MAX only stops NI-488.2 software/driver from reading STB when events are not enabled. As soon as I enable events auto polling is performed regardless of the setting in MAX. I think setting in MAX should be honored in both cases. If there is a reason to the contrary it should be documented. Again, disabling auto polling (if it worked) could be a workaround to the cleared cached STB issue. However, I think both issues should be fixed.

Could you please answer the following?

1. Did your VISA team reproduce these problems?

2. Did your VISA team assign IDs to these bugs, are they tracked?

3. When can I expect the fix?

Thank you.
Sebastian

[Alex+ra]

Hi Sebastian,

Courtney is unavailable at this time, so I'm going to try to catch up on where she left off and see what I can find. I will try to get back to you within 48 hours.

Alexandra V

Applications Engineer

National Instruments

[Sebastian1516]

Alexandra,

It has been a while. Do you have any update for me?

Thanks,

Sebastian

[Alex+ra]

Hi Sebastian,

I'm sorry for the delay. I have contacted a colleague in R&D, and he is working to reproduce the issue. I will let you know what we find.

Regards,

Alexandra

[Justin_P]

Hi Sebastian,

I attempted to reproduce this with a Keithley 2700.  I looked at your log and made the same calls and even tried to replicate the delays that you had.  Attached is my nitrace log.  In it you will see:

21. VISA Set Attribute ("GPIB0::16::INSTR", 0x3FFF001A, 1200)
Process ID: 0x00001D68 Thread ID: 0x00001E24
Start Time: 14:17:30.408 Call Duration 00:00:00.001
Status: 0 (VI_SUCCESS)

22. VISA Read STB ("GPIB0::16::INSTR", 96)
Process ID: 0x00001D68 Thread ID: 0x00001E24
Start Time: 14:17:30.409 Call Duration 00:00:00.001
Status: 0 (VI_SUCCESS)

23. VISA Read STB ("GPIB0::16::INSTR", 32)
Process ID: 0x00001D68 Thread ID: 0x00001E24
Start Time: 14:17:31.210 Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

Is there something else that I need to be doing to replicate this, or do you see anything that I am doing that is inconsistent with what you are doing?

Thanks

[Sebastian1516]

Hi Justin,

I’m so glad someone at NI is finally (after 4 months) trying to reproduce the issue and hopefully offer a bug fix.

The key to reproduce this problem is to set up the status bit (STB) in such a way that reading it causes one or more of its bits to be cleared.

I do not have Keithley Model 2700, but I do have Model 2010. I think status reporting system should be pretty similar on these instruments. I have been able to reproduce the same issue on Keithley 2010 quite easily. I only had to set ESE register to 1 and read/clear *ESR register after reading STB (in addition to what I showed before). I believe I used R&S ESU receiver to produce the previous log. It did not require clearing ESR to rearm SRQ event generation.

Here is what I did on Keithley 2010:

Resource manager session opened!

Instrument sesion opened!

Timeout set to 200 ms.

Terminating character disabled.

End of Identity (EOI) eneabled.

>*ESR?                <------- This clears power up state of Event Status Register (ESR)  

<128

>*ESR?                  <------- This makes sure ESR register has been cleared  

<0

<STB: 0                  <------- Also read STB to make sure it is 0  

>*ESE 1;*SRE 32                <------- Enable event on operation complete; enable SRQ on that event              

Enabling SRQ Event Capture   <------- This will allow you to see that disabling auto polling has no effect once VISA SRQ event capture is enabled  

>*OPC      

<SRQ Event Received     <------- If auto polling is disabled NI-488.2 still reads, clears, and caches STB (It is especially easy to see on instruments that have a dedicated SRQ indicator/LED on the front panel).  

<STB: 96               <------- Request for Service (RQS) bit 6 and Event Summary (ESB) bit 5 are set (2^5+2^6=96) – this is expected behavior

<STB: 32               <------- Reading STB cleared RQS bit but ESB bit 5 (2^5=32) remains set until underlying ESR is cleared.

>*ESR?                  <------- Clear ESR to clear ESB bit on STB – this rearms service request generation.

<1

>*ESR?

<0

>*OPC                  

<SRQ Event Received

Timeout set to 500 ms. <------- This inadvertently clears cached STB (read out previously with auto polling)

<STB: 32               <------- This reads STB again, but now Request for Service (RQS) bit is not set because it was cleared when auto polling was performed and discarded when timeout was changed

<STB: 32

>*ESR?

<1

>*ESR?

<0

Disabling SRQ Event Capture

Instrument sesion closed!

I’m attaching full NI Trace log of this.

I could not open your attachment. It seems to be either corrupted or perhaps generated with a different version of NI Trace. I have version 3.0.1. The funny thing is – in the status bar it shows 27 events, but only one is displayed. Perhaps that is another bug. I found some reference to it here. However, it might not be the same issue.

I appreciate you looking at this. Perhaps NI can come up with a fix so I can finally use these 5 NI GPIB-USB-HS interfaces I bought 4 months ago.

Thanks,

Sebastian