LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA - unable to queue operation & device reported an input protocol error.

To be sure, it seems he's a bit overzealous about *opc? even after queries, but I don't think it does any harm beyond adding an extra command.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 11 of 24
(1,908 Views)

@billko wrote:

To be sure, it seems he's a bit overzealous about *opc? even after queries, but I don't think it does any harm beyond adding an extra command.  😉


Yes I had also notice his over use also.

But with my Tek Scope, it did do harm. My scope did not like it when I sent it "*IDN?;*OPC?\n"

 

I could send it "*IDN?;". Read in the reply. Then send it an "*OPC?\n" OK, but not as one command string.

 

The problem is that USB is single duplex and as soon as my scope sees the semicolon (;) at the end of the *IDN? it starts replying back at the same time I am still sending the '*OPC?' causing a clash.

 

I have some Agilent intruments that in the manual they warn about sending more than one request command (?) in the same command string when using serial communication (RS232). It's not a problem with GPIB as you control when the instrument talks.

Omar
0 Kudos
Message 12 of 24
(1,903 Views)

@Omar_II wrote:

@billko wrote:

To be sure, it seems he's a bit overzealous about *opc? even after queries, but I don't think it does any harm beyond adding an extra command.  😉


Yes I had also notice his over use also.

But with my Tek Scope, it did do harm. My scope did not like it when I sent it "*IDN?;*OPC?\n"

 

I could send it "*IDN?;". Read in the reply. Then send it an "*OPC?\n" OK, but not as one command string.

 

The problem is that USB is single duplex and as soon as my scope sees the semicolon (;) at the end of the *IDN? it starts replying back at the same time I am still sending the '*OPC?' causing a clash.

 

I have some Agilent intruments that in the manual they warn about sending more than one request command (?) in the same command string when using serial communication (RS232). It's not a problem with GPIB as you control when the instrument talks.


Hey, that IS interesting.  I never actually tried that combo before; it never occured to me to do so.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 24
(1,899 Views)

I should add that it might be a problem even with GPIB instruments.

 

Some GPIB instruments do not like it if you send it a query (?) and then send it a 2nd query (?) without first requesting the reply from the first. They will return an error when when you finally get around to telling them to "talk"

Omar
0 Kudos
Message 14 of 24
(1,895 Views)
Thanks for looking into this as well Omar.

The *OPC? query at the end of the *IDN? was a mistake in the test VI (well spotted + thanks for looking at the logs). I forgot to omit it on that command. I removed it on the example ESR query trace. I only use it (if I don't make mistakes 😉 ) on commands not queries.

The *SAV command can take up to 500ms the first time. I also use a save to USB drive MMEMory:STATe:STORe which I have more problems with. This can take 1-2 seconds on the first run. Subsequent runs execute in about 500ms, again using *OPC? at the end. Then I check for any errors in the instruments queue.

The way my VISA comms class works, is that on any read operation it reads the timeout value for the VISA session and divides this by 100ms. It takes the result and rounds up to the nearest integer. This is how many times I attempt a VISA read in the for loop before I pass the timeout error out, unless another error is generated in which case I break out of the for loop sooner. Hope that makes sense. Theoretically there shouldn't be any problem with doing this, even if it's not the normal practice. It is so deeply embedded in all of my instrument drivers.

Cheers


Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 15 of 24
(1,881 Views)
Forgot to mention before entering the for loop I set the timeout to 100ms then on exit, back to what it originally was.


Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 16 of 24
(1,877 Views)
Another example of a command which requires a long timeout (30 seconds to minutes) is the *TST? Self test. This is a good example of why I break up my timeouts into smaller chunks.


Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 17 of 24
(1,871 Views)

@matt.baker wrote:
Another example of a command which requires a long timeout (30 seconds to minutes) is the *TST? Self test. This is a good example of why I break up my timeouts into smaller chunks.

So how do you handle this case?  I mean, I can certainly see adjusting the timeout for this command, then shortening it back down for other commands.  I wouldn't use the looping thing, though.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 18 of 24
(1,865 Views)
I use the same loop case in my class for this. I would always want to give the user the ability to cancel long operations. It seems bad forcing them to wait a couple of minutes for the single VISA read to time out with no way of stopping it. Using the for loop method I can cancel the operation sooner (I also check a "user requested exiting" flag on each iteration).

Again, I do get where your coming from with just leaving the timeouts longer, but it should work for multiple reads surely. Sorry for sounding like a broken record 🙂


Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 19 of 24
(1,857 Views)
What reasons would you have against using a loop approach/multiple reads ignoring timeout errors? Is there any info/guidelines on not doing that? Just trying to fully understand the pitfalls 🙂


Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 20 of 24
(1,852 Views)