LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

network-shared variables detailed documentation

Could someone point me to a document where the topic of network-shared variables are described properly? I cannot find a good guide, only some information fragments around at ni.com. For example, this guide states its a "detailed" description, but even do not mention "aliasing":

http://www.ni.com/white-paper/4679/en/#toc3

 

Yep, there are some other "info fragments", like this one about aliasing:

https://zone.ni.com/reference/en-XX/help/371361G-01/lvhowto/bind_to_source/

This one about NI-PSP:

https://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/ni_psp/

 

I really miss some proper detailed guide where all network-shared information is collected and described at one place. For example, describing when I should use aliasing, when not? Should I bind the variable to a "NI-PSP" or "project variable"? What are the differences? Working examples?

 

In my application I simply need a network-shared variable for lossy communication between two PXI units (no need to enable buffering or RT FIFO!). I only need to write data to the variable at one PXI, and I need to read out the most recent value at the other PXI. What is the recommendation in this case? Do I need "aliasing"? Since I do not see the whole picture due to inproper documentation, I am not sure...

 

EDit: ok, I think I do need aliasing, since I need to create a variable at both PXIs, so I need to "bind" them. But should I use NI-PSP, or "project" binding? What are the differences, pros, cons?

 

0 Kudos
Message 1 of 9
(4,437 Views)

Ok, it looks like more straightforward than I thought 🙂 I followed these steps (now only testing the principle using two Windows laptops), it might help for future noobies like me for network comms 🙂 :

  1. Created a network-shared variable at one laptop in a project. Right clicked on the variable's lvlib, and deployed it on this laptop. Now it is visible in the list of the "NI Distributed System Manager".
  2. Created another network-shared variable at the other laptop in a project. Checked "Enable Aliasing".
  3. Set to "Bind to PSP URL", and clicked on "Browse...". I can see the first laptop on the local network (same subnet too), but no variable is visible 😞
  4. Ah, Windows! 🙂 Disabling Firewall at both laptops 🙂
  5. Now I can select the variable from the dialog window, and bind it to the variable at the second laptop.
  6. All is working now...

Is there any difference when I need to do this for two PXI units?

0 Kudos
Message 2 of 9
(4,423 Views)

I may be a little biased, but I HATE Network Published Shared Variables.  They have given me nothing but headaches, especially in the realm of some really weird race conditions.  I much prefer to use direct TCP/IP using STM or to use Network Streams to pass the values from one machine to the next.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 9
(4,397 Views)

As usual, I agree completely with Crossrulz.  When Network Shared Variables were first introduced in one of the LabVIEW 8 versions, I played with them a lot, trying to use them to pass data back and forth between Host PC and Remote PXI in a LabVIEW RT Project.  I did a lot of "experimentation" to try to figure out how things worked, but was never able to get it to work smoothly, reliably, and "as the documentation suggested it should work".

 

When the Project got restarted a few LabVIEW versions later, Network Streams were available.  I used four streams -- two to create Host->Remote and Remote->Host Message Channels (both Host and Remote were built around a Queued Message Handler, and this allowed the Host to, say, send the Remote a "Start" Message with a set of Trial Parameters as the data), and two more for streaming point-in-time Event Data and sampled 1KHz Analog Data from the Remote to the PC.  I did put in a Network Shared Variable to pass some "monitoring" data (at, I think, 10 Hz) to the PC to keep tabs on the PXI, but even at this relatively slow rate, it proved problematic, so I removed it, and used Network Streams for all my Host-Remote communications.

 

Bob Schor

0 Kudos
Message 4 of 9
(4,392 Views)

In my case the rate will be 1 Hz, and I do not care about missing some data points. I just need to get the recent data at one PXI (master) from the other PXI (slave). I only transmitt data, and I write the data to the variable at only one single place (slave), and read it out at another single place on the other PXI (master). I do not see any possible race condition here, do you? Also, I know this is a lossy communication, but the nature of the experiment allows to do so (the PXI network is an extension of a Siemens PLC, monitoring and logging data for months/years).

Of course, the handling of incoming commands from the PLC is a different story. When the master PXI gets a command from the PLC, it transmits it via a Network Stream to the slave PXI (commands must be losless).

 

I decided to use variables due to the above requirements, and to simplify my code (one less Network Stream to setup, handle its possible errors like timeout due to network problem, or "Endpoint destroyed" error due to PXI unit crash...).

0 Kudos
Message 5 of 9
(4,385 Views)

Guys, let me ask a question. Beside the above mentioned possible race conditions (you meant the "classical" race condition, like the one can happen with local variables too?), and the lossy nature, do you have additional point why not to use network-shared local variables? Did you have other troubles, like deployment at RT, etc? 

 

I just would like to see clear before making decision. If the only problem you encountered in the past with such variables were race conditions and data loss, I am ok with it. If there are further serious issues, I will program a bit more and move to Network Streams (I did not start to test the PXI network yet)...

0 Kudos
Message 6 of 9
(4,377 Views)

Usually I hate when someone bumps his own thread, but I am still very interested in this topic: possible problems with network-shared variables in case of RT (PXI)? Do we have any non obvious (lossyness, race conditions) problem with them? Thanks! 🙂

0 Kudos
Message 7 of 9
(4,358 Views)

The biggest issue I have ran into are different forms of race conditions.  For instance, write to a NPSV and then immediately read from it.  You will read the old value since it takes what seems like a long time for the variable to get published by the server.  The actual timing is actually around the 10ms range, but that is a long time especially in RT.

 

Thinking about your situation, it sounds like you thought through it pretty well.  So for this exact situation, you will probably be just fine.  But I would actually consider using a UDP broadcast to update the remote systems.  Did I mention I am very biased against Network Published Shared Variables?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 9
(4,350 Views)
Thanks for the clarification! 🙂
0 Kudos
Message 9 of 9
(4,343 Views)