Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Using the driver for the Agilent 54621A oscilloscope

I am trying to obtain data from this agilent oscilloscope. However, using the "ag5462x Getting Started.vi" fails to work properly.
First it has the wrong GPIB resource number (I have to rewrite GPIB::14::INSTR => GPIB::7::INSTR). There is some communication with the
oscilloscope after this, but the oscilloscope complains "Querty UNTERMINATED," and the vi eventually tells me the operation timed out before
completion. I am very dissatisfied with this.
0 Kudos
Message 1 of 11
(4,460 Views)
Since a primary address can be 0-30, you only have a small chance of having a default value in a driver match what your instrument is set to. I usually leave the resource name blank. Also, you shouldn't have to type anything. Right clicking on the arrow of a VISA Resource Name control will display a list of all instruments detected by MAX.

As far as the problem, are you using the IVI or native LabVIEW driver? If you don't know, then open the VI and see if there's a bunch of subVIs that you can view all of the source code or if there's a Call Library Function Node. If you're using the IVI driver, it will be harder to find the problem and unless you have a copy of LabWindow/CVI, you won't be able to fix any problems. If you're using the native LabVIEW driver, try to determine which subVI is generating the error. All getting started VIs consist of several subVIs (that you can call separately). Try single stepping through the subVIs until the error occurs.
0 Kudos
Message 2 of 11
(4,450 Views)
The Error -420 means the instrument was addressed to talk, but but the command sent to it was not a query command. If you are using the getting started vi, see if there is a "ID Query" input, the default value for this input is true, change it to false and see if that helps.

Also have you have checked the instrument's user manual for the valid commands to use? Some instrument requires certain termination character with a command.
0 Kudos
Message 3 of 11
(4,437 Views)


@Dennis Knutson wrote:
Since a primary address can be 0-30, you only have a small chance of having a default value in a driver match what your instrument is set to. I usually leave the resource name blank. Also, you shouldn't have to type anything. Right clicking on the arrow of a VISA Resource Name control will display a list of all instruments detected by MAX.




The getting started VI for the Agilent 33120A waveform generator picked the right resource name, so I was surprised when the VI for the oscilliscope did not. There was not a list of instruments detected by the MAX, and leaving the resource name blank caused I/O error.



As far as the problem, are you using the IVI or native LabVIEW driver? If you don't know, then open the VI and see if there's a bunch of subVIs that you can view all of the source code or if there's a Call Library Function Node. If you're using the IVI driver, it will be harder to find the problem and unless you have a copy of LabWindow/CVI, you won't be able to fix any problems. If you're using the native LabVIEW driver, try to determine which subVI is generating the error. All getting started VIs consist of several subVIs (that you can call separately). Try single stepping through the subVIs until the error occurs.




As long as I set QueryInstrStatus to 0, I was able to collect data from the oscilloscope, but there was still the "Query UNTERMINATED" warning on the oscilloscope display, and there was a noticeable long delay before the VI finished executing and displayed the waveform obtained from the oscilloscope.

The labview program is using several Call Library Function Node, and I had downloaded the VI specially from an NI website, so I believe I am using the IVI. I was able to narrow the cause of the problem of the "Query UNTERMINATED" to the ag5462x_ReadWaveform function in ag5462x_32.dll.

I believe the lack of query termination is responsible for the intolerable delay in return of the waveform data. I suppose you are suggesting I can edit the code, and perhaps repair the problem with the LabWindow/CVI. I do have a copy of this, and am installing now.

Your reply was very helpful. Thankyou.
0 Kudos
Message 4 of 11
(4,432 Views)


@TongY wrote:
The Error -420 means the instrument was addressed to talk, but but the command sent to it was not a query command. If you are using the getting started vi, see if there is a "ID Query" input, the default value for this input is true, change it to false and see if that helps.

Also have you have checked the instrument's user manual for the valid commands to use? Some instrument requires certain termination character with a command.




I believe some instrument status query was responsible for the lack of reponse from the oscilloscope.

I do have the manual for the oscilloscope. I hope that I can edit the driver, or someone else can, so that it will communicate properly with the instrument.
0 Kudos
Message 5 of 11
(4,430 Views)


@TongY wrote:
The Error -420 means the instrument was addressed to talk, but but the command sent to it was not a query command. If you are using the getting started vi, see if there is a "ID Query" input, the default value for this input is true, change it to false and see if that helps.

Also have you have checked the instrument's user manual for the valid commands to use? Some instrument requires certain termination character with a command.





I took a closer look at this.


The session is initialized with
ag5462x_InitWithOptions (ViRsrc resourceName, ViBoolean IDQuery,
ViBoolean resetDevice, ViConstString optionString,
ViSession *newVi)

Setting the IDQuery to true or false as you say seems to make little difference. But in
the optionString, the default in the example is: "Simulate=0,RangeCheck=1,QueryInstrStatus=1,Cache=1".

At first, I simply noticed that I got no result whatsoever so long as I let QueryInstrStatus=1. However,
upon closer investigation, it appears that the setting this option causes the following code to be executed.

viCheckErr( viWrite (io, "*ESR?\n", 7, VI_NULL));
viCheckErr( viScanf (io, "%hd", &esr));

On the viScanf, I get a timeout error, as the device doesn't respond. The reason seems to be because of the preceeding viWrite. It claims to write 7 characters, but the line is obviously only 6. Changing this number to 6 causes this problem to disappear.

I still have the other problem however.
0 Kudos
Message 6 of 11
(4,425 Views)
Is there a specific reason for using the IVI driver? Why don't you give the native LabVIEW driver a try? It's got a more recent release date. The LabVIEW driver can be found here.
0 Kudos
Message 7 of 11
(4,416 Views)
It seems like your instrument either: A. Does not take termination "\n" or B. not set up to do so. I have never used an ag54261 before so I don't know which one is the case, you can check the instrument's user manual for more info.

What you have done is taking the "n" off the write string so there will be no termination for it. I bet you can reduce the string length by one more byte to get rid of "\" and your program would still run fine.
0 Kudos
Message 8 of 11
(4,387 Views)
\n is an escape sequence which represents the single "newline character," ascii value 10.
0 Kudos
Message 9 of 11
(4,384 Views)
I know what "\n" is, what I was suggesting is that the instrument timeouts because it does not receive an acceptable termination and is waiting for more data. By taking the last byte off the write string, "\n" is not read by the instrument anymore.
0 Kudos
Message 10 of 11
(4,354 Views)