05-23-2014 05:39 AM
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.
05-23-2014 07:27 AM
Also posted here:
http://www1.tek.com/forum/viewtopic.php?f=6&t=6147&p=12127
05-23-2014 10:32 AM - edited 05-23-2014 10:35 AM
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.
05-23-2014 10:47 AM - edited 05-23-2014 10:50 AM
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.
05-23-2014 11:06 AM
05-23-2014 11:18 AM
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?
05-23-2014 11:20 AM
Oh, do you have an example of what it looked like before you tried to work around the issue? Thanks!
05-23-2014 11:41 AM
05-23-2014 12:21 PM - edited 05-23-2014 12:24 PM
<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.
05-23-2014 02:08 PM
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
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.
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?