VISA Read and Write Sequence Causes Timeout Error Except in "Highlight Execution Mode"

[smallen]

Hello all,

A sub-VI I wrote a while back has suddenly stopped working, giving the following error:

"Error -1073807339 occured at VISA read

VISA: (Hex 0xBFFF0015) Timeout expired before operation completed."

The sub-VI just sends a sequence of commands and reads back the answers from the instrument. I have made a new sub-VI containing the read/write sequence to do this, but also added in the intialise and close steps so that it runs as a standalone VI. Please find attached two versions of this, one simple and one which breaks the sequence up with timings (both produce the same error).

Interestingly, this error only occurs when run normally. When run in "highlight execution" mode, both VIs I have attached run perfectly and as quickly as "highlight execution" allows. In normal mode they take a lot longer, only to produce no outputs and throw out the error above. Furthermore, the error doesn't occur when the sub-VI is called by certain higher-level VIs, but does with others. As a standalone VI however the error is consistent.

Here is a quick list of things I have tried already and that didn't work:

1. Explicitly opening the session to the serial port

2. Flushing or not flushing the serial buffer

3. Increasing the wait time in the flat sequence

4. Using "bytes at port" to set the number of bytes to read

I have also seen and taken note of the presentation everyone recommends on the proper way to communicate over serial in LabVIEW from VI week 2020 to no avail.

I would also like to note that the device responds instantaneously to the commands when written via NI Max or the serial monitor for the instrument, so the problem is not instrument-side as far as I can tell. Also, the string constants need to be formatted in this way, and the device responds to other commands formatted in this way too. The issue with the reading of the response when not in "highlight execution" mode.

Any help that anyone could offer would be greatly appreciated.

Best wishes,

Sam

[cstorey]

Running in Highlight Execution means you are adding an extra delay between each command, slowing dataflow.  If it works with longer delays of Highlight execution mode, then are you sure 40ms is long enough?  What happens if you give it 100ms or 1s?  Your current VISA timeout is 10s by default, so perhaps you are reading too soon after the write and it just doesn't have data to return and hangs until the timeout expires.  (Change timeout to 1s if the 10s is too long.) 

You're VISA serial port setup is also showing a termination character (\n) is being sent since the input are unwired and the default values are being used.  Then you are also appending \n in your write strings.  Perhaps this causing the device to return extra characters.

Which brings me to why not use "\ codes display" in your indicators and see what the real strings returned look like.

Next problem might be that if there are extra return charactrs you aren't reading them all.  Why are you reading 32 bytes?  Why not use 1024 in case it return extra chars from time to time.  Its not necessary to specify an exact size, just a memory buffer size so there's no real penalty in using something larger these days.

If you are going to program serial I suggest you watch this presentation - https://labviewwiki.org/wiki/VIWeek_2020/Proper_way_to_communicate_over_serial

If it was working, then what changed n your setup?  

[cstorey]

Here, try using something like this to easily vary all the parameters and see why its failing.

[smallen]

Hi there,

As I mentioned in my original post, the instrument response time is extremely fast as demonstrated by its response to serial monitor and/or NI MAX. You press enter, the value is printed back immediately. There is no delay on the instrument-side. I will try altering the wait times again anyway to check.

The strings are in "\ codes display" so as far as I understand there is no additional termination character being appended, only what is shown.

The return is just a number which can be up to 10 digits or so. I just chose 32 because it's bigger than the number expected but I will try upping this.

I mentioned also in my original post that I have already seen the presentation you suggest. Nothing changed, that is the strangest part. I just carried on building the top-level VI but nothing to do with the serial communication, I was building in the communication with another device via its own provided software/LabVIEW package.

I will make the changes you suggest and let you know what I find. Thank you for your help!

Sam

[smallen]

Thank you, I will try this!

Sam

[smallen]

Hi there,

The program works as long as the delay is above 934 ms. Anything less and I get the error. This is irrespective of what I set the VISA serial timeout to - I have set it anywhere from 10 s to 10 ms! This odd value is very consistent - with 934 ms delay the program runs perfectly, with 933 ms I get the timeout error!

I checked the return from the instrument is "x\n" as expected by changing the indicators to "\ codes display" format, so no issue there.

As far as I am aware, setting the termination character in the VISA serial initialise does not automatically append it to writes, it only means it looks for it in reads. Consistent with this, when I remove the "\n" from the write strings, I get no response from the instrument.

Sam

[GerdW]

Hi Samuel,

---

@smallen wrote:

As far as I am aware, setting the termination character in the VISA serial initialise does not automatically append it to writes, it only means it looks for it in reads. Consistent with this, when I remove the "\n" from the write strings, I get no response from the instrument.

---

Yes, the TermChar setting at ConfigureSerialPort only sets the "read termchar", but there is an additional property for the "write termchar". You could enable to add a termchar also for VISAWrite, but that isn't used so often…

---

@smallen wrote:

The program works as long as the delay is above 934 ms. Anything less and I get the error. This is irrespective of what I set the VISA serial timeout to - I have set it anywhere from 10 s to 10 ms! This odd value is very consistent - with 934 ms delay the program runs perfectly, with 933 ms I get the timeout error!

---

How fast does your device process data?

Some devices don't like "too many messages too often", but require a delay between each command message…

The VISA timeout is applied to VISARead: you get a timeout error when there is no device response within the given timeout duration…

[smallen]

Hi there,

The device processes the commands very quickly. In the case of sending these commands via arduino serial monitor, the value appears immediately after you press enter without any noticable delay. The example I attached sets a delay between sending the commands, but the version as a sub-VI works perfectly without this, and all the other commands I send to to the instrument can be sent in quick succession with no issues.

I think I also mentioned in my original post, but sometimes when called as a sub-VI, it will work very fast (so fast as to not be noticable) whereas as a standalone and at other times when called as a sub-VI, I get the error reported above.

The top-level VI that it works with works every time and very fast (well below 100 ms)! It is exactly the same code, exactly the same instrument, but when run as a standalone vs sub-VI it either times out with the error after 5 seconds or so, or works instantly and perfectly!

Best wishes,

Sam

[cstorey]

Did you change the number of bytes?

Bizzare that it works from a top-level vi but not in a small standalone application.  It suggest some setup is needed, or you aren't closing handles to the instrument.

Are you closing all other communication to the instrument before running this subvi?

Can you tell us more about the device?  Make, model, programming manual?

Are there setup commands you need to send before this subvi?

Craig

[smallen]

Hi there,

Yes, I changed the number of bytes all the way up to 1000 or more - it made no difference.

The instrument has been built in-house, and is based around an arduino microcontroller. Other than initialising the serial connection, there is no setup - it is a very simple motor controller.

The top-level VI that works with the sub-VI and the new top-level VI that does not have exactly identical set up routines!

I can look again at how I am handling the disconnect/closing of the serial connection and get back to you to see if any previous runs of other programs are causing issues?

Thank you for your help!

Best wishes,

Sam