network streams vs shared variables

[faustina]

I send data from a PXI RT System to users on different Windows computers via Shared Variable and Network Stream.  The user that receives the data via Network Stream writes the data to a disk file (aka DAQ computer).  The users that receive the data via Shared Variable displays it on front panels (aka Observers). 

The data consists of a 1D SGL array where elements 0-3 are the timestamp, element 4 is the counter, and elements 5-1000+ are data.  The timestamp is GPS time and is displayed on all computers.  When I look at the timestamp on the DAQ it is slowly falling behind the current GPS time.  After 4 hours it can be up to a minute behind.  When I look at the timestamp on the Observers it is always displaying current GPS time.  When I look at the code on the PXI System, it is always sending the current GPS time.  The counter on the DAQ computer is also behind.

I am using the Read/Write Single Element Stream functions with the default read/write buffer size of 4096.  The 'timed out?' output is always FALSE for both functions.  No errors are generated.  LabVIEW memory usage is constant during the whole time.

On the PXI RT System the Network Stream and Shared Variable are being written to inside a Timed While Loop.  The users read the data within a standard While Loop.  Everyone is using LabVIEW 2011.

It sounds like a buffer is slowly being filled up somewhere, but where?

[SteveChandler]

I have not used network streams except to play around a little bit with them when they first came out. Is it possible you need to call the flush stream function?

Edit: I was just reading a little more about these. Do you have anything wired to timeout on the write single element?

[stevem181]

On the PXI RT System:

How often is data sent?

Are you using a “Flush Stream” function after your “Write Single Element to Stream”?

On the “DAQ Computer”:

Are you buffering the reading of the data (i.e. feeding it to a queue)?

You might try using a property node to read “Available Elements for Reading” to see if they are stacking up here.

The buffer size is another option to consider.

steve

[faustina]

There is nothing wired to the "timeout in ms (-1)" input of the Write Single Element to Stream function.  However, I do wire an indicator to the "timed out?" output of the function.  That is how I know it is not timing out. 

Data is sent every 6 ms on the RT System.  I never use the Flush Stream function on any of the computers.  There are no queues.  The 1D SGL array is assembled and wired directly into the Write Single Element to Stream function and Shared Variable on the RT System.  The Read Single Element to Stream function (DAQ computer) and Shared Variable (Observers) are wired to a subVI that parses out the desired elements for timestamp and counter and these are wired directly to indicators.  The elements for timestamp are converted to a timestamp data type prior to being displayed on the indicator.

[SteveChandler]

Try calling flush right after you send the element. The data could just be sitting in the buffer waiting for a good time to be transmitted over the network. Calling flush will tell it to start imediately.

[stevem181]

faustina,

In your first post you said that the "DAQ Computer" writes the data to disk.

So every 6 ms you are writing potentially 4K+ bytes to the hard drive.

That's 166 times per second.

I would buffer the reads from the Network Stream with a queue and also buffer the writing to file.

steve

[faustina]

Besides displaying the timestamp and counter immediately on the DAQ computer, the entire array is sent via a queue to another loop that writes the array to a disk file.  That loop is buffered. 

[faustina · Accepted solution]

Network Stream buffer was being used up too fast.  So, increase buffer size and/or insert small wait.

[BenDAE]

Faustina,

Are you still having issues with a lagging timestamp?

[faustina]

no, I incorporated a check in the VI that did the write stream and the problem when away - thank you