LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Serial Async Read in Reentrant SubVI viWaitOnEvent Errors - no side effects?

Solved!
Go to solution

Hi All,

I have a re-entrant subVI that contains VISA Configure Serial, VISA Serial Write and a VISA Serial Read.  The serial port is setup with line termination of 0xA, I setup the buffer to a default of 4096, send 1 line of command to my device and immediate start reading in loop with size to read set to 4096 (unrealistic and that's the point, since I have line termination setup, reading fast as I can).  The VISA Serial Read and Write are both set to Asynchronous IO mode.  I run this subVI with it opening communication to 4 serial devices at the same time.

 

When I run my program, I don't notices anytime out errors, but if I open NI-SPY/IOTrace, I notice tons of viWaitOnEvent Errors with BFFF0015 (timeout) errors.  However, at the end, the viWaitonEVent seems to clear up and will indicate "Completing viReadAsync".  I also don't seem to be seeing any errors with the function of my code.  If I switch to Synchronous IO mode, the errors clear up, but I don't notice any differences.

 

Is having all these errors across the COM ports a normal side effect of using Async?  Is there a reason to switch to Synchronous mode besides clearing up errors?

 

Regards,
Mike

Snip_viWaitOnEvent.PNG 

0 Kudos
Message 1 of 2
(2,071 Views)
Solution
Accepted by topic author Mikejj

I think this thread might help answer your question:

 

https://forums.ni.com/t5/LabVIEW/VISA-Synchronous-asynchronous-gt-Confused/td-p/878609?profile.langu...

 

My understanding is that in asynchronous mode, LabVIEW will regularly poll the VISA session to see if the read/write is event is complete and viWaitOnEvent the errors are just an indication that it is not complete yet. It would be similar to reading the Bytes At Port property node in a while loop until the desired data is available before calling VISA Read. In synchronous mode, LabVIEW will block execution in the calling thread until the read/write event is complete or timed out which is why you will not see the same low-level errors. For your application, asynchronous mode seems to be the appropriate setting.

0 Kudos
Message 2 of 2
(2,035 Views)