Why do network shared variables get wrong values on start?

[Southern_Cross]

I'm running the shipping example "RT FIFO Variables - Networked.lvproj". Once I deploy the shared variables I can successfully run both the host and target VIs. Data is exchanged as expected. However, once I press the STOP button on the host VI the target VI cannot be restarted regardless of the running state of the host VI. The only way that I can get the target VI to start running again is to edit it (e.g. add a text box or somekind of NOP) and then redeploy. 

It seems that some incorrect value gets stuck in the targets Stop variable FIFO and therefore the target cannot run. I've tried adding a variable write to the STOP variable before the loop in the example but this does not help.

Can anyone explain to me why this shipping example cannot be run two time sequentially w/o a required redeploy?

[Bob_Schor]

This may be the "expected behavior".  [I haven't tested this -- my Remote system is running LabVIEW 2012, and I don't have this particular Example loaded ...].  Normally, the Remote is not connected to the Host, and when it stops, the RT-OS reboots and starts it running again.  Here, you are "doing it all manually".  I suspect that has something to do with it.  I've certainly noticed that when I try to debug some LabVIEW RT routines "by hand", it isn't always smooth sailing -- I need to do the Connect/Deploy/Run sequence in the right order (and sometimes need to include "Reboot Remote").

Remember, this is an Example, meant to be run once, to show (hmm, how to say this?) an "example" of an RT-FIFO communication.

BS

[Southern_Cross]

I sure hope that this is not expected. I do normally have my host connected to the target and I don't have the RT system reboot to start running again. This seems like a poor design if all users are forced into this type of operation model.

I'm hoping that this is not the case and that there is another explanation, else, Shared Variables seem to fail to solve my need.

[Bob_Schor · Accepted solution]

I vaguely remembered something about initializing Shared Variables (I can't find the reference right now).  But I did (finally) try the demo code out, and (as it turns out) I was right -- it is a poorly-written example, precisely because it is "designed by omission" to work exactly once!

Recall that the instructions are to start the Host, then start the Target.  The first time, when the Target starts, you get a sinusoid.  But once you stop the Host (which also stops the Target), if you again start Host, then Target, the Target stops immediately.  This is because the Target (but not the Host) sees the Stop Shared Variable (when the Target starts running) as True (which it was the previous time the Target ran), and stops itself.  What you need to do is provide enough time for the (re-initialized) Shared Variable from the Host to propagate through the Network and get to the Target.  I tried putting a 50 ms delay before entering the Target's loop -- not long enough.  But 500 ms was fine -- the Example ran fine the second, third, and fourth time.

I'll bring this to NI's attention.

Bob Schor

[Southern_Cross]

That makes sense. I appreciate the explanation Bob. 

[Bob_Schor]

You are most welcome.  Sorry I've forgotten the "NI-approved" way of ensuring that Network Shared Variables are properly initialized, but I just talked to NI Application Engineering, they are (now) aware of this "flawed example", and I've urged them to add the initialization code, with explanation, as another "teaching moment".  With luck, it will appear in 2015, and possibly as a 2014 "patch".

 

Bob Schor