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

Question

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 LV2014 SP1
Attachments:
VISA problems.zip ‏38 KB

Answer 1

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?
Omar