Shared variable choice revisited

[MarkBowles]

Good morning, all,

I have inherited management of a 6-year-old lab instrument control system, written in LabVIEW 14, that runs on a cRIO 9067 with a Windows-based LabVIEW HMI. Communication between the two is via bi-directional data streams, and a collection of 150 Network Shared Variables, all booleans and DBLs.  Our lab runs several identical instruments on a 24x7 basis.  The instruments do not communicate with each other.

The cRIO side consists of several hundred VIs, running a couple dozen loops, and includes a custom FPGA.

The NSVs are also being used to pass values between loops within the cRIO; in fact, there are only a few global variables, most of which are static after initialization.  The NSVs are all single-value types (i.e. not FIFOs).

Each variable has only one writer, and they are all in the same cRIO app, spread among several loops.

Last week, a technician was replacing a network switch in the lab, and temporarily disconnected a node.  At this point, on one of the units, the cRIO application caught errors from two NSV readers and one NSV writer, and chaos ensued. The original author of the system had dutifully chained the error line through all the NSV operations and into loop terminations. 

I hadn't paid much attention to the subtleties of these shared variables, because, well, they were working. Now that they have called attention to themselves, I wonder if this architecture is the best choice, and if not, how to replace it.

Question 1: when the writer and reader of a single-value NSV are in the same process, is there a write-to-read latency? I think I've seen this happen, and have put artificial delays in the system to compensate, but it would be very complex to ensure I've found all such issues. If this latency does exist, then it seems to me that NSVs are not best practice for intra-process communication.

Question 2: if there is only one writer per NSV (and they are all in the cRIO app), can I safely replace them with global variables without explicit synchronization?  That is, does LabVIEW guarantee that a reader will never see a "half-written" value, from another thread that's at that very moment updating it?

Thanks in advance,

-- Mark

[crossrulz]

---

@MarkBowles wrote:

Question 1: when the writer and reader of a single-value NSV are in the same process, is there a write-to-read latency? I think I've seen this happen, and have put artificial delays in the system to compensate, but it would be very complex to ensure I've found all such issues. If this latency does exist, then it seems to me that NSVs are not best practice for intra-process communication.

---

Yes there is, up to 100ms (or whatever the shared variable buffer write timeout is).  One of the MANY reasons I state that NPSVs are actually evil.  The only time I have had luck with them is when I took the CLED exam, and that was mostly due to the 4 hour time restraint.  If you need to send updates to a HMI, I highly recommend using the Network Streams or raw TCP/IP communications.  I personally am a big fan of using the STM library to help create the message protocol so you know what data is being received and therefore update the right variables.

---

@MarkBowles wrote:

Question 2: if there is only one writer per NSV (and they are all in the cRIO app), can I safely replace them with global variables without explicit synchronization?  That is, does LabVIEW guarantee that a reader will never see a "half-written" value, from another thread that's at that very moment updating it?

---

My only hesitation is I don't know the nature of your updates and if tag information is actually appropriate.  Assuming tag data is appropriate, you will be fine replacing with global variables.

[MarkBowles]

Thanks so much for your quick reply.

What do you mean by "tag information" ?  Are you referring to the fact that the data is distributed into 150 individual DBL and boolean variables, rather than more logically structured?  

Best,

-- M

[crossrulz · Accepted solution]

There are basically 3 types of communication:

1. Tags - Asynchronous, only care about the latest value

2. Messenger - Commands, no real rate of messages, may or may not care about all of the messages

3. Stream - High throughput, typically single data type, care about all of the data

You can probably get a slightly better explanation at the NI Week 2016 discussion I did: Are Global Variables Truly Evil?