Network published shared variable changes not seen by real-time target unless in debug mode or running locally

[dmckETS]

I'm operating a cRIO-9056 with code that operates without error when I run it on a local computer (as in, the VI is located on the cRIO, but I press run from the front panel). It also runs fine when I build it as a rtexe and run as startup, but only when I have connected from Operate --> Debug... in the project explorer.

When not in one of these two conditions I don't get any errors, but any changes made to network published shared variables don't get 'seen' by the cRIO. I have a VI running on the local computer to monitor progress and allow for basic start/stop of an experiment.

Is there anywhere I can start in tracking down this issue? I already tried "Disconnect type definitions" in the build properties, as apparently there was an old bug involving shared variables on real time targets: https://forums.ni.com/t5/LabVIEW/Application-Builder-What-does-quot-disconnect-type-definitions/td-p... , but that didn't make a difference.

RT OS is NI Linux Real-Time x64 5.10.115-rt67 firmware 7.0.0f0, using LV 2022 Q3 22.3.1f8

[Bob_Schor · Accepted solution]

Once I moved my (first) LabVIEW RT project from LabVIEW 7 to LabVIEW (some early year in the Year-numbered versions of LabVIEW, maybe 2010?), I stopped using Network Published Shared Variables to communicate between Host (PC) and Target (a PXI system, running PharLap), and substituted Network Streams (which worked reliably and predictably).  At least once since then, I've attempted to add a Network Published Shared Variable for some "minor" task, but it always proved unreliable (for me), and I abandoned it.

Try using Network Streams instead.  It is a little more work, but a lot more robust.

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

Try using Network Streams instead.  It is a little more work, but a lot more robust.

I use direct TCP/IP as I find it a little easier than Network Streams.  Your mileage may vary.

After a certain project I was dragged into, I learned how horrible Network Published Shared Variables really are.  They are insecure (anybody on the network can write to them) and they are slow (a buffer has to be filled up before the values are written to the database, try writing a new value to one and then immediately read from it and you will get different values).

Therefore, my advice for the OP is to get rid of Network Published Shared Variables.  Use TCP/IP and/or Network Streams to pass data back and forth.  It is a little more effort upfront, but it will more than pay off in the debug.

[Bob_Schor]

---

@crossrulz wrote:

---

@Bob_Schor wrote:

Try using Network Streams instead.  It is a little more work, but a lot more robust.

I use direct TCP/IP as I find it a little easier than Network Streams.  Your mileage may vary.

---

@crossrulz and I are (I think) in complete agreement -- our "end-implementation" just differs slightly (based on our own "what has worked better for me" experiences).

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

---

@crossrulz wrote:

---

@Bob_Schor wrote:

Try using Network Streams instead.  It is a little more work, but a lot more robust.

I use direct TCP/IP as I find it a little easier than Network Streams.  Your mileage may vary.

---

@crossrulz and I are (I think) in complete agreement -- our "end-implementation" just differs slightly (based on our own "what has worked better for me" experiences).

Bob Schor

---

Yes, we are in complete agreement.

I understand why people like Network Streams and I will not discourage people from using them.  They do work well.  I just prefer having more control over the connection and message handling.

[dmckETS]

Thanks all. Not the answer I was hoping for (everyone loves a quick fix!) but sounds like sage advice; I'll get to work.