LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

To summarise I have two main questions:

 

How can I clear the VISA operation queue and what causes an input protocol error during transfer?

 


 

I am using a Tektronix AFG3022B Function Generator with latest firmware connected via USB and LabVIEW 2013 SP1 patch 2 (13.0.1f2) 32bit with NI-VISA 5.4.1.

 

If I have a small timeout, say 100ms, and perform a save operation and op complete query on the device (*SAV 1;OPC?), then do up to 10 VISA reads; the first few reads time out (as expected), but then I frequently get the following error:

 

-1073807305 (0xBFFF0037) VI_ERROR_INP_PROT_VIOL. "Device reported an input protocol error during transfer."

 

Once this occurs, the whole VISA session seems to become unstable and lots of the read operations fail returing this error code and not the timeout error (0xBFFF0015 (VI_ERROR_TMO)).

 

This only seems to happen when I do save/recall operations (either internal or to a mass storage device connected to the instrument), all other commands/queries timeout for the first few reads (as expected) then return the value. Do you think this is probably down to poor instrument firmware/hardware? Or am I using the VISA incorrectly? I would have thought that attempting to read VISA data to soon should only generate a timeout error and not a protocol error.

 


Reason for small timeouts:

Instead of setting the timeout to 4 seconds and having no way of cancelling the read operation I set the timeout to 100ms and run a for loop up to 40 times ignoring timout errors unless it's the last loop iteration. This means I can the operation within ~100ms.


 

What causes the VISA protocol error? I can't find much information on it.

 

Once the protocol error occurs and I keep repeating the *SAV command, I get the following error:

-1073807303 (0xBFFF0039) VI_ERROR_IN_PROGRESS. "Unable to queue the asynchronous operation because there is already an operation in progress."

 

Once this error occurs, how can I force a clear on the VISA queue without unplugging/power cycling the instrument?

 

Some NI I/O trace captures attached to show what happens and test VI.

 



Using LV2018 32 bit

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

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

Also posted here:

http://www1.tek.com/forum/viewtopic.php?f=6&t=6147&p=12127



Using LV2018 32 bit

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

https://getsharex.com/
0 Kudos
Message 2 of 24
(7,855 Views)

You use the *OPC? command.  Are you sure that 100 ms is a long enough wait time for this command to complete?  I'm not assuming your level of experience here, but many novice programmers feel that a really small timeout is a good thing because they thing the timeout is the minimum amount of time to wait for a response, when it's just the opposite - it's the MAXIMUM wait time.  I think the wait is too short and it's timing out before the save can be completed.  Try at least doubling the timeout.  (I would probably have the timeout measured in seconds.)

 

LabVIEW reports "Unable to queue the asynchronous operation because there is already an operation in progress." because that is exactly what is happening.  You're not witing long enough and trying to send another command while it is still in the process of executing the save command.

 

Increase the timeout and you won't have to worry about trying to work around the error.

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 3 of 24
(7,829 Views)

Billko,

Many thanks for your reply.

I get what your saying, but that doesn't explain WHY it generates a protocol error. Surely it should only be generating a timeout error. I can increase the timeout like you suggest (the minimum i've got away with is 1500ms) and the problem would be less likely to occur, but it's still there.

Ah I see, so the queue is in the instrument, not the VISA?
That being said, the queue error happens on a VISA open command as well though. Even if a wait a few minutes it's still unable to queue the operation.



Using LV2018 32 bit

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

https://getsharex.com/
0 Kudos
Message 4 of 24
(7,820 Views)
P.s.
I've always had trouble with this model of instrument. I've been using similar code on a spectrum analyser over Ethernet without problems. It's just frustrating that I can't pinpoint the route cause.

I generally use a VISA wrapper class that I developed (to natively support FTDI and Bluetooth devices) but have gone back to basics to eliminate that from the problem.


Using LV2018 32 bit

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

https://getsharex.com/
0 Kudos
Message 5 of 24
(7,805 Views)

Sorry, my attenion span seems to be limited to only a few paragraphs.  I didn't get to the part explaining WHY you had such a small timeout.  I did a google search on "Device reported an input protocol error during transfer" because sometimes google does a better search of the NI forums than NI does.  😉

 

I found this.  Maybe it might help?

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 6 of 24
(7,797 Views)

Oh, do you have an example of what it looked like before you tried to work around the issue?  Thanks!

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 7 of 24
(7,792 Views)
Admittedly it was quite along post 😛
I wanted to include as much relevant information as possible.

I didn't come across that post. Thanks.
Still same problem though, no explanation on what caused it.

I'll do some more googling 😜
But any more information you come across would be great! 🙂

I could possibly upload the original, but it has lots of dependancies on other reusable libraries/classes that I have developed. Here's a list:
Error handling library
32 feet Bluetooth wrapper library
FTDI wrapper library
Object class
Instrument class
VISA comms class
Target simulator controller class


Using LV2018 32 bit

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

https://getsharex.com/
0 Kudos
Message 8 of 24
(7,779 Views)

<snip>

Reason for small timeouts:

Instead of setting the timeout to 4 seconds and having no way of cancelling the read operation I set the timeout to 100ms and run a for loop up to 40 times ignoring timout errors unless it's the last loop iteration. This means I can the operation within ~100ms.


 

<snip>

 


 I've been pondering this statement.  Just use the timout the way it's supposed to be used.  I think that sometimes the equipment can't process the read in time so you pile up the commands.

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 9 of 24
(7,767 Views)

I thought I would try to duplicate your problems, but I only have a Tektronix TDS Scope that has USB.

I am a big fan of using *OCP? to sync instruments control and your problem is of interest to me

 

This very simple write/read returns the *OPC '1' return char consistently between 175-185 ms. No problem

 

USB Simple.png

 


 

Trying your short timeout with a loop, I do not get what I or you expected.

If I run this with an adequate timeout (something well longer than the needed 185 ms) it returns in between 175-185 ms with one time through the for loop. As expected. No problem.

USB Looping.png 

BUT! If I try setting the timeout to something below the needed 175 ms like your 100ms...

Sometimes it works but it takes over 2000 ms to return but only goes though the for loop twice.

But sometime it does not work at all, taking well over 10 sec to exit out of the for loop with a timeout error.

 

I never see the queue error that you are seeing

 

How long does it take to do a simple *SAV

 

I don’t think the queue error is coming from the instrument. You would have to send the instruments the SYSTEM:ERROR? Request before the instrument would report any of the instruments errors. 

 

Be sure to set your Termination Char setting. I prefer to turn it off for the Writes so I control when to send it. But turn it on for the Reads

 

Also I noticed from your trace files that you use the *OPC? after a *IDN?. This is not needed as you will know the *IDN? is complete when your received the string back. In fact my Tektronix scope did not like it if I sent it "*IDN?;*OPC?\n". It would not send me anything back, not even the IDN.

 

Is the SAV command on your instrument so long that you need to be able to break out of the loop?

Omar
0 Kudos
Message 10 of 24
(7,737 Views)