VI refuses to run when network published shared variable is unavailable

[eclay42]

I have a data logging VI on my PC that gathers data from several sources, including several network published shared variables hosted on a RT target.

The problem I'm having is that the data logger VI refuses to run if the RT target is off, and the VI aborts if the network connection is interrupted.

Is there an easy way to detect at runtime whether these network published variables are available, and use a placeholder value if they aren't instead of the current behavior of refusing to work?

I've seen a lot of people using data sockets, but I'm trying to avoid the extra work of setting up and testing a relatively complex network handling loop on both ends when the network published shared variables are so simple to use and work perfectly other than this ungraceful behavior.

[altenbach · Accepted solution]

You could replace them with programmatic access (open shared variable and friends) and subtitute dummy data if the variable is not reachable.

[crossrulz]

---

@eclay42 wrote:

I've seen a lot of people using data sockets,

---

Do not go with Data Sockets.  They are severely dated and NI does not exactly support them anymore.  Shared Variables was the replacement for Data Sockets way back with LabVIEW 8.

I would like to see at least part of your code.  The shared variable should just throw an error if it could not be read and return the default data for the type.

Personally, I much rather use Network Streams to have the RT stream all of the data to the PC and then the PC just uses the latest values for each data point for logging.  Yes, it is a little more work but I have had very little luck with Network Published Shared Variables.

[altenbach]

---

@crossrulz wrote:
The shared variable should just throw an error if it could not be read and return the default data for the type.

---

 Maybe it has to do with automatic error handing, so it would just be a matter of handling the errors explicitely, e.g. by not leaving them unwired. 😄

[crossrulz]

---

@altenbach wrote:

---

@crossrulz wrote:
The shared variable should just throw an error if it could not be read and return the default data for the type.

---

 Maybe it has to do with automatic error handing, so it would just be a matter of handling the errors explicitely, e.g. by not leaving them unwired. 😄

---

Or my thought is that all of the errors are wired up and the VI is stopping on an error.  Kind of the opposite extreme on error handlling.

[eclay42]

Thanks everyone for your input. The open shared variable connection method sounds like the most reasonable approach, I'll go ahead and give it a try.

Network streams look like a powerful tool, but that's the kind of extra complexity I was hoping to avoid by using the shared variables.

For those who asked, the specific error is that when I try to run my data logger VI on my PC when the RT is turned off, it gives a deployment error and never actually runs since it can't reach the target. If I turn the RT off while the data logger is running, it gives a disconnect error and aborts the data logging VI. Neither behavior is acceptable for my use case since I want the data logging to function even if some of the data sources are unreachable. I'm only recording a data point about once every 5 seconds so I don't need anything high performance.

A screenshot of the variable use is attached, all it does is read the variables and build an array that's written to a spreadsheet.