LabVIEW
Ensure a single NSV is delivered
Solved!
@j.collins wrote:
I don't care about losing intermediate data but I do care that the last value I wrote is delivered (either to the cRIO or the PC) since I may only write to the NSV once ever.
In that case, disable buffering on that variable. This way, you receivers won't receive stale values.
By the way, when your cRIO starts up, it's best to initialize the variable by assigning a default value.
@j.collins wrote:
My question is two fold:
1) If I write a value to a shared variable once, assuming there are no network issues, is it guaranteed to eventually propagate to the other side? How do I know if it did?
2) Since the NSVs are hosted on the RT are values written to the NSVs from the RT immediately available to the RT for reading?
1) Yes, propagating data across a network is the whole point of NSVs 🙂 By default, NSVs are propagated every 10 ms. There is no receipt acknowledgement so you won't be informed when the data arrives, but you can check the connection quality. There are two ways to do that:
- In the block diagram, when your receiver reads the variable, check the error output. No error == Successfully retrieved the latest value
- On the front panel, if you use data binding on an indicator, there will be a little LED next to the indicator. Green LED == Connected and receiving data
Your receiver can also fetch the timestamp of the read variable, to know what time that value was written.
2) Yes. How "immediate" are you talking about though? Is 10 ms immediate enough?
You may also be interested in reading this
@j.collins wrote:
I still need to add the step where I loop continuously on an NSV read until my changes are propagated during initialization as is suggested here.
That example refers to initializing an SV hosted on a DIFFERENT target -- the RT target is initializing variables hosted on a PC, then waiting for the PC to propagate the initial values back to it as a way to confirm that the initialization was successful. It needs to wait and check because there's a chance that the link to the PC is down.
Since you're hosting your variable on your RT target, the wait is not necessary. If your cRIO does the writing, your cRIO's variable engine is guaranteed to receive the initial value.
@j.collins wrote:
1) Since data in this project is written to the NSVs infrequently and sporadically the readers don't know when they should be concerned that no new values have been written. I suppose I am more concerned that a writer knows that its value was published to the SVE (whether the writer is located on the same machine as the SVE or not). What initially prompted my concern was something I read in an NI article: "Writing to a publisher does not guarantee an update because the NI-PSP is lossy". This was from an article that was specific to buffering network shared variables though, which I am not doing.
2) 'Immediate' was a poor choice of phrasing on my part. What I wanted to know is if NSV access from the same device hosting the SVE will operate like accessing a single process variable in the sense that the network layer is avoided. Should I have a warm fuzzy feeling that an NSV read and written to from the same machine (or RT) hosting the SVE can handle having a critical value Boolean on it like 'should I be recording data or not'. On a remote system I have to error catch access to NSV otherwise a network disconnect will throw popup errors to the user if I go to read from it. Do I have to do this on the machine hosting the SVE or is NSV access as safe for the SVE machine as any other local variable? Would it be safer if I just read and wrote all NSVs to and from local variables on a periodic basis and use the local variables in the rest of my code?
1) "Lossy" in that context refers to the protocol. If your network goes down and your host writes 10 unbuffered values before the network is restored, the reader will only see the last value and not the first 9. No checking is done to ensure that every value is received, and there is no way to retrieve the old unreceived values. (Contrast this with TCP, a lossless protocol -- the sender retransmits packets that weren't received)
In your case, since your variable is a flag instead of a data stream, you don't have to worry about this. Even if your network goes down before your cRIO writes the "disk full" flag, your PC will see the flag after connection is restored. Just make sure that your connection is good.
2) Since the SVE is locally hosted, your cRIO doesn't need network access to write values to it. A machine can't lose connection with itself. However, you still need to "open a connection" to a locally-hosted NSV. I have never seen this fail with locally-hosted NSVs, but I guess I can't confirm with 100% certainty that it will never fail. You'll have to ask an NI engineer with knowledge of the SVE's inner secrets.
