08-11-2016 08:16 AM - edited 08-11-2016 08:30 AM
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?
08-11-2016 08:47 AM - edited 08-11-2016 08:50 AM
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 🙂 :
Is there any difference when I need to do this for two PXI units?
08-11-2016 08:19 PM
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.
08-11-2016 08:36 PM
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
08-12-2016 12:46 AM - edited 08-12-2016 12:48 AM
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...).
08-12-2016 02:30 AM - edited 08-12-2016 02:30 AM
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)...
08-13-2016 04:30 AM
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! 🙂
08-13-2016 02:17 PM
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?
08-13-2016 04:32 PM