VISA timeout error on periodical communications

[1984]

I have a VI which communicates with a USB instrument with VISA. First we send a "get status" message and wait for the response and the immediately send a "get error" message which returns a number and a string if the instrument is in an error. This is running in a while loop with a static wait of 250ms between the iterations. The VISA timeout is set to 500ms.

We are not worried too much about a timeout, we said if there is a timeout then repeat the operation max 3 time or until no timeout like below. Before say that this implementation makes no sense pls note that this is simplified just to show how the retry mechanism is implemented:

Still from time to time I get an error message "-1073807339,"Message":"VISA: (Hex 0xBFFF0015) Timeout expired before operation completed."

There are no concurrent communication to the instruments. The communication is implemented like this, the wait for response is always set to true:

 

Any ideas what could cause a timeout on the instrument? I'm quite lost, because the code is very simple and there are plenty of time between the messages.

Thanks.

[crossrulz]

I have never needed to use the VISA Events.  And the Clear Buffers is another major red flag to me.  All you should need to do is do the VISA Write and then a VISA Read, letting the timeout work on the VISA Read.  Do not use the Bytes At Port when doing this:  just try to read more data than you expect in a response.

I would also recommend increasing your timeout.  It is not uncommon for devices (especially older ones) to freeze before sending out a response.

[1984]

So my thinking process during writing the VI was this:

After getting the VISA refnum I flush whatever is on the bus because if previously I sent a command to the instrument but for whatever reasons I either didnt or couldnt read its response BUT the response has arrived then sending another command and then reading the response will have the response of the previous command as well. So flushing is a mechanism, I assume. Is this assumption incorrect?

Before I respond to the VISA event part... lets assume the instrument returns only 1 byte plus a \n termination char after 5ms. If set the VISA read to read 1000 bytes with a 1000ms timeout whats gonna be the execution time of the VISA read and what will be on the outputs? I can't test this at the moment because I dont have any instruments around me, but you might know it by heart.

thanks.

[GerdW]

Hi 1984,

---

@1984 wrote:

lets assume the instrument returns only 1 byte plus a \n termination char after 5ms. If set the VISA read to read 1000 bytes with a 1000ms timeout whats gonna be the execution time of the VISA read and what will be on the outputs? I can't test this at the moment because I dont have any instruments around me, but you might know it by heart.

---

VISARead stops for those conditions:

• the requested number of bytes has been received
• the timeout has been reached
• the TermChar as configured has been received
• an error within the driver of the communication port occurs (rather uncommon?)

For your question the 3rd item applies…

[RTSLVU]

You are using a lot of things that normally are not used in serial communications like "bytes at port", VISA Flush Buffer, and VISA Discard events.

Most serial communication issues can be solved by watching this video: VIWeek 2020/Proper way to communicate over serial

[1984]

I see, thanks! In this case the VISA event is really not necessary, I can just try reading 1000 (or whatever) bytes an I'll be good.

I love the idea of this VISA event, but if you guys are saying that this fishy then I can remove that, no problem. I still think that the flush is necessary for the reason above. Any thoughts on that?

[GerdW]

Hi 1984,

---

@1984 wrote:

I still think that the flush is necessary for the reason above. Any thoughts on that?

---

When you send a command to your device then you should also read the expected answer!

What's the point of sending commands when you don't need/handle their answer???

I see only one reason for Flush: when you start communication with a device that sends data without request then it helps to flush the buffer to get rid of data garbage received between "start" and "first read"…

[1984]

---

---

When you send a command to your device then you should also read the expected answer!

What's the point of sending commands when you don't need/handle their answer???

I understand that you dont use the flush which is alright with me, but it just a habbit or is there something wrong with it?

I find overusing question marks marks pretty condesending.

[crossrulz]

---

@GerdW wrote:

I see only one reason for Flush: when you start communication with a device that sends data without request then it helps to flush the buffer to get rid of data garbage received between "start" and "first read"…

---

For ASCII protocols, I just do a read when I initialize the port.  The data from this read is thrown away, but it ensures the following reads are synched up, getting the full message.  Flush is not needed.

In the OP's situation, with the assumption the device only responds to requests (ie does not randomly send messages on its own), I can understand using the Flush before writing to make sure any previous unread response does not affect the current message and response.

[1984]

Sorry for getting back pretty late on the subject there we other - non sw related - issues which had to be solved by our customer.

I modified the code per the suggestions. The only exception is that I kept using the visa flush before writing anything (see the snippet). 

As mentioned before if the operation fails I repeat the it couple times before we say that we really have a problem.

It was not mentioned before but I use this VI to communicate with a GPT-9803 HIPOT tester instrument via USB. During the test we ramp up the voltage to couple kV (DC), then keep it steady for couple sec and finish the test. The instrument will respond to our query with a string indicating the current voltage, the current test time, a test in progress flag and a Pass/Fail flag. The instrument controls this porcess on its own, so losing the connection doesnt mean it will not shut the test down properly.

Once I also introduced pretty detailed logging of whats happened and I have found the followings:

1. The communication is either OK so there is no retry at all, or it fails all the time
2. When the problem occurs it exclusively occurs at the very end of the test. From logging the response from the instrument I see that the voltage increases and right at 0.1s before the test is completed the communication is lost.

Once fails the log shows the following:

Notice that the steps follow each other in every ~10s. This is interesting as when I initialize the instrument I explicitly sets the timeout to 500ms. 

At this point I assume that the problem is not really the VI itself but something happens right when the instrument starts discharging. This is not confirmed at all, but it would explain why we see the problem at the end of the process everytime.

Also - and give me some hints here - I assume that this would explain the 10s timeout. 10s is the default timeout for VISA operations and I guess if something bad happens and the the communication is dropped then once I try to flush or write to the VISA resource the default settings are applied again.

Any ideas are welcomed.