LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT File I/O and Nework I/O priority

Solved!
Go to solution

I have a subvi which receives UDP packets and applies a timestamp to each.  This subVI is set to the data acquisition execution system (LabView RT) and high priority.  This UDP receiver pushes data into an RT FIFO.

 

I have another subVI which sets up a TDMS file (Creates and adds channel properties etc) which is called at the beginning of acquisition.  This subVI is normal priority and on the standard execution system.  Another subVI drains the RT FIFO into the TDMS file on the same normal priority execution system.

 

When the TDMS setup VI runs for the first time, there is a long delay in the UDP VI which causes many packets to backup in the UDP receive buffer (Causing a flurry of timestamps which are incorrect).

 

What can I do to ensure the UDP receive subVI doesn't get interrupted?  It seems as though the UDP receive function itself may not be running at the priority of the subVI that calls it.  But I'm not sure why.

 

The other oddity is that after the first execution of the UDP receive subVI, it can execute again with no apparant effect on the UDP receiver subVI (Even though it's doing the same thing).

 

Thanks,

XL600

0 Kudos
Message 1 of 2
(2,759 Views)
Solution
Accepted by topic author xl600

Answered my own question.  The RT trace viewer is your friend!  I had an FGV set to subroutine priority which was blocking the high priority UDP receive subVI which happened to be running in the same thread but only on the first run through of the VI.  Go figure...

 

Note to self...  Watch those priority settings!

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