LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variable data loss

I am trying to verify a rumor i heard but cannot verify. 

Lets assume we are using networked shared variables on aWindows PC, writing to another Windows PC across a network at fairly fast write rates. 

 

Let's also assume our read loop on the other end is reading slower than we write to the engine.  My understanding is that ALL values will be sent across the network regardless of how fast I am reading them,  and values are lost (overwritten) on the read machine if the client side buffer fills up.

 

My question is- what happens if the network itself is painfully slow?  Does the engine write only the latest values across the network and discard some values, or does it try to ensure that every packet makes it across, cuasing the client side to fall farther and farther behind?  I guess I was hoping that it would behave sort of like UDP if the network was slow, choosing to lose data rather than allow the client application to build up a huge data delay that cannot be brought back to "real-time" data viewing.

 

It's not really clear to me from the documentation how PSP will behave on a slow, long distance network connection, but I have a colleauge who claims that on a slow network he has watched the read (client) side fall farther and farther behind with PSP.  If I dont care about getting every point but would rather see "real-time" snapshots of data, do I need to use UDP instead?



0 Kudos
Message 1 of 4
(3,274 Views)

Hi Garvacious,

 

Thanks for the post and I hope your well.

 

Network Published Shared Variables can be used to shared data between VIs running on different machines. However, due to network latency, the most recently data may not be avaiable to a VI running on a machine across the network. In this case, the VI attempting to read from the network published shared variable returns the previous value. For datalogging applications, you can use timestamps to programmatically ensure that each value logged once and only once. 

 

You can use buffering with the network-published shared variable. This would prevent data being lost. From more information I would recommend reading this very detailed article,

 

Using the LabVIEW Shared Variable

http://zone.ni.com/devzone/cda/tut/p/id/4679#toc2

 

Table of Contents

 You'll find all your answers (i hope) under 3. 

 

Also there is some example code regarding buffering,

 

How Does Buffering Work for Shared Variables?

http://digital.ni.com/public.nsf/allkb/5A2EB0E0BC56219C8625730C00232C09?OpenDocument

 

Finally, if your not concerned about losing data, then UDP is the fastest and easier to implement then TCP/IP.

 

Hope this helps,

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
0 Kudos
Message 2 of 4
(3,258 Views)
Thanks for the reply- actually I dont care about losing data points with PSP but would be more concerned about this statement I made earlier:  "on a slow network he has watched the read (client) side fall farther and farther behind with PSP".  In other words, does network latency cause the reader to read successively older data each time?  Or would this only happen if the shared variable has buffering turned on (in other words,with a 50 point buffer set up the oldest data I would be reading is "(current point)-50", and data older than that is lost?


0 Kudos
Message 3 of 4
(3,231 Views)

Hi Garvacious,

 

Thanks for the update and I hope your well.

 

I think I did mis-undertstand your comment/concern - sorry for that. 

 

Im not sure why it would fall further and further behind - I seem to think the delay/latency would be fairly constant. Surely it takes a similar time to update the variable on the Server from the Publisher and the similar time (every time) to read from the Server (subcriber). Everytime = iternation.

 

Have you seen this effect?

 

Kind Regards,

 

 

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
0 Kudos
Message 4 of 4
(3,211 Views)