FieldPoint Family
VISA Serial Read does not timeout correctly
I believe that the VISA serial read gives "false" timeouts when used in higly parallel circumstances. This problem was fixed in much older versions of VISA but it is a tricky error and has come back in the more recent versions.
I have a highly parallelized system with MANY concurrent loops executing. Upon upgrading from VISA 2.? to VISA 3.5 I started getting serial port timeouts that had not occurred before. If I run NI Spy the timeouts dissappear!! This can't be true, either the hardware replied in time or not. The hardware is fairly fast and the timeout is many times the expected reply time. These rare and intermittent errors have been driving me and the operators nuts for quite a while now.
This happens if the reads and writes are asynchronous or synchronous!!
So, I have a test VI that I created that allows one to spawn CPU sucking tasks while writing to a loop back connector. In this case the hardware cannot be timing out since the cable length / speed of light is a LOT less than the timeout period. I merely write one character to the serial port and read 1 character back, with a compare. Last night after 3208923 iterations the read back timed out with a BFFF0015 error.
What I believe is happening is a subtle timing error in the VISA read timeout logic. The following scenario describes it. I have indented a different thread that preempts the VISA thread.
VISA starts a timer
VISA starts its read
VISA tests to see if the data is available
----ANOTHER THREAD INTERRUPTS AND STEALS THE CPU CYCLES
----Lots of time passes
data arrives at serial port
----Execution returns to the VISA read thread sometime after the timout passes
VISA checks the time
The time is more than the timeout
VISA reports a timeout error.
What needs to be done is to check the VISA serial port AFTER you check the time. In this case you never report a false timeout, though sometimes on a heavily loaded system you will report that a communication was ok when it MAY have exceeded the timeout.
In this case CPU load prevents determining if the timeout occurred. So unless the system is certain that a timeout occurred it should not report an error. Basically when in doubt, don't blame external hardware. 🙂
System Details:
Mac OS X
VISA 4.0.1
LabVIEW 8.20
Keyspan 28X twin serial USB-Serial adaptor
Test program set to 18 parallel tasks. LabVIEW changed to use 8 threads for all execution engines all priorities using vi.lib/Utility/sysinfo.llb/threadconfig.vi. Changing the threads, the execution priorities, etc. does not seem to affect this problem much.
Open the Serial Port test VI
put a loop back connector on one of your serial ports
Enter that serial port VISA name into the serial port tester control
run the Serial port test VI
Tell it to think "harder" a few times (I had 18 in my test) until your CPU gets loaded up.
Wait about 24 hours and see if it quits with a timeout error.
Here is the front panel of the test VI when the error occurred.
I have attached a LV 8.20 project that I used for this test. This is a very simple test and the most complicated thing is to spawn all the CPU sucking sub tasks. Remember to bring the number of sub tasks back to zero before stopping the VI or it may cause LV to unexpectedly quit.
-Scott
I have a highly parallelized system with MANY concurrent loops executing. Upon upgrading from VISA 2.? to VISA 3.5 I started getting serial port timeouts that had not occurred before. If I run NI Spy the timeouts dissappear!! This can't be true, either the hardware replied in time or not. The hardware is fairly fast and the timeout is many times the expected reply time. These rare and intermittent errors have been driving me and the operators nuts for quite a while now.
This happens if the reads and writes are asynchronous or synchronous!!
So, I have a test VI that I created that allows one to spawn CPU sucking tasks while writing to a loop back connector. In this case the hardware cannot be timing out since the cable length / speed of light is a LOT less than the timeout period. I merely write one character to the serial port and read 1 character back, with a compare. Last night after 3208923 iterations the read back timed out with a BFFF0015 error.
What I believe is happening is a subtle timing error in the VISA read timeout logic. The following scenario describes it. I have indented a different thread that preempts the VISA thread.
VISA starts a timer
VISA starts its read
VISA tests to see if the data is available
----ANOTHER THREAD INTERRUPTS AND STEALS THE CPU CYCLES
----Lots of time passes
data arrives at serial port
----Execution returns to the VISA read thread sometime after the timout passes
VISA checks the time
The time is more than the timeout
VISA reports a timeout error.
What needs to be done is to check the VISA serial port AFTER you check the time. In this case you never report a false timeout, though sometimes on a heavily loaded system you will report that a communication was ok when it MAY have exceeded the timeout.
In this case CPU load prevents determining if the timeout occurred. So unless the system is certain that a timeout occurred it should not report an error. Basically when in doubt, don't blame external hardware. 🙂
System Details:
Mac OS X
VISA 4.0.1
LabVIEW 8.20
Keyspan 28X twin serial USB-Serial adaptor
Test program set to 18 parallel tasks. LabVIEW changed to use 8 threads for all execution engines all priorities using vi.lib/Utility/sysinfo.llb/threadconfig.vi. Changing the threads, the execution priorities, etc. does not seem to affect this problem much.
Open the Serial Port test VI
put a loop back connector on one of your serial ports
Enter that serial port VISA name into the serial port tester control
run the Serial port test VI
Tell it to think "harder" a few times (I had 18 in my test) until your CPU gets loaded up.
Wait about 24 hours and see if it quits with a timeout error.
Here is the front panel of the test VI when the error occurred.
I have attached a LV 8.20 project that I used for this test. This is a very simple test and the most complicated thing is to spawn all the CPU sucking sub tasks. Remember to bring the number of sub tasks back to zero before stopping the VI or it may cause LV to unexpectedly quit.
-Scott
Message Edited by sth on 01-19-2007 09:25 AM
