VISA STB with different USB-GPIB interfaces

[pwendel]

Hello,

I am working with an Agilent 4294 impedance analyser controlled with LabVIEW. The LabVIEW VI I am using has been written by someone who left the group some years ago, but I think it's based on an example provided. Ever since I'm using the device it didn't get the data from the very first measurement after turning it on, it got stuck somewhere in a loop. Stopping and restarting always solved that problem.

Now we had to change USB-GPIB adaptors. Before I was using a NI HS interface, not it's an Agilent 82357B. I can communicate with the instrument, start measurements and manually get the data. In the LabVIEW routine it gets stuck though.

I tried to find the error and found out that the VISA STB in the "wait for opc.vi" sends different results depending on the USB-GPIB adaptor. With the Agilent one it stays zero until at some point the timeout occurs. With the NI one it shows 68 if I probe the wire and the measurement is done. The program then continues to transfer the data. So somehow with the Agilent interface I don't get the correct information whether the measurement is over.

Does anyone have an idea what causes this difference? Why does the outcome of the STB request depend on the GPIB interface?

If it helps I can upload both the "wait for opc" and the program that I use.

Thanks in advance for your help!

[Albert.Geven]

Maybe the device uses autopolling and takes the result of the statusbyte itself.

I also would try to select the slowest bus speed for this analyzer.

[Albert.Geven]

Maybe the device uses autopolling and takes the result of the statusbyte itself.

I also would try to select the slowest bus speed for this analyzer. 

[pwendel]

Hello Albert,

thanks for the suggestions! Changing the bus speed didn't change the problem. It was set to intermediate speeds (500ns), I tried it with 2us as well. The NI adapter that is working is set to 500ns, I therefore changed the setting back.
In what way would the autopoll crash the stb readout and what can I do to test it?

Here you see the settings of the working NI adapter from NI MAX and the non working Agilent adapter from Agilent Connection Expert.

[Albert.Geven]

autopolling could reset the STB without noticing the client.

The busspeed is anyhow determined by the slowest instrument on the bus but most older instruments don't handshake that fast and 2 useconds is still faster than most older instruments. It gives some more time to the bus by not reacting to a ringing signal.

[Albert.Geven]

Hi

I saw that automatic serial poll was enabled, that is the same as what NI cals autopolling.

[pwendel]

So autopolling is off. The first measurement after the change returned the data, the following got stuck at the same point. The measurements don't always fail, but the vast majority does. I tried to get the result from the stb but whenever I "probe" the cable or do highlighted execution it fails..

If the bus speed is the same with the NI adapter that works, could that still be the source of the error? They both wait the same time for a signal.

[cymrieg]

Try replacing the viReadSTB with a viWrite (*stb?) and read the result. For this to work I think you would have to disable the auto polling.

[pwendel]

I'm puzzled!

If I turn on both the device and the computer the first measurement does not return any results. But the second one does. After the measurement is done the STB query gives a 68. Any further measurement after that one results in STB staying constantly 0.

Sometimes opening the USB/GPIB adapter settings in Agilent Connection Expert (ACE) and saving without any changes helps to get a succesful measurement. But at max only one measurement returns the data, further measurements fail. A part from once where I could measure 5 times in a row, but after closing and reopening LabVIEW it got stuck again.

I tried to find a dependence on ACE and restarts of PC and device without success.

So apparently the STB sometimes gives the correct result, but not reliably.

Any further ideas what I could test?

BTW cymrieg I tried to replace viReadSTB with viWrite (*STB?) which resulted in a GPIB command error on the device. But I included an indicator to display the result of viReadSTB.

[pwendel]

Today I checked the VI again and played around a bit. I was always wondering about the ESNB and CLS commands in the "wait for opc.vi". So I just removed the CLS and the thing worked.

I attached a screenshot of the VI, can anybody please explain me the use of the ESNB and CLS commands in this example? Is it a safe workaround to remove the CLS command? And how can it matter whether I use the Agilent or the NI USB-GPIB interface?