VISA Read timeout problem again - caused by UUT power off

[MileP]

I have a subVI with state machine structure to decode data streams from serial port.

State1 is to check the Start of Frame

State2 is to read the payload

...

StateN is to check the checksum

Here is the problem:

Power down the UUTarget while the VI is still running, and I gets the VISA Read Timeout Error because there is no data in the serial port from target anymore.

Next time when you UUT is powered up again, I still get the VISA read Timeout Error and nothing works again.

Is there any suggestion how to handle this if I want to keep the VI running all the time?

I tried to use Elapsed Time VI to calculate certain amount of time and stop the VI by exiting the loop, but have problem understanding Elapsed Time VI and worried about its execution time.

Thank you for any advice.

[D_Biel]

MileP,

Have you tried the VISA Flus I/O Buffer.vi, or the VISA Clear.vi? These may free up the buffer for new data.

[Butch_Gates]

Have you cleared the error from your state machine?

I assume your error cluster is passed through a shift register.

Just one of those "flat forehead" checks.

[MileP]

Thank you all!

I did clear the error when the elapsed time reaches the expected time. The problem is, I wired the Error Out of VISA Read to Error In of "Elapsed Time" VI, so the "Elapsed Time" VI doesn't function at all when there is VISA Read timeout error. It's interesting. I thought the errors are sort of independent here.

[Albert.Geven]

The rule for handling errors is easy

If you have to do some IO in a vi that gets an error in, don't do the IO but pass the error.

Even better don't do anything except passing the error.

Except for closing a connection or file etc. Then close the file or connection and also pass the error!.

[MileP]

Thank you, Albert. But I think Elapsed Time VI should always work even when there is input error.

[Albert.Geven]

I would expect also but opening it and going into subElapsedTime I saw that in case of an error NO code is executed at all.

Seems the wrong way to handle an error.

It is not allowed to change the error but is anyhow except showing nothing also not touching the error.

SO it simply is a choice (and I think a wrong choice) of the developer of the Elapsed time VI