Shared Variables and Me

[jmltinc]

Hi Folks,

I need help, please. I created a Single Process Shared Variable in the Project Explorer and 2 VIs that write/read to it.

One VI writes to the variable, the other reads. Both VIs work as expected when run as Vis in the development environment. If I create Builds for both (or, even one), no data is transferred on my development machine. I changed the variable to a Network-Processed variable and can move data between executables, but only on my development machine. When executed on a Runtime platform, they fail with an error message of not having Enhanced DSC Runtime. I spent hours running in circles - researching, making Builds, you name it.

The goal is simple - send data from one LabVIEW exe to another - both on the same machine. Can anyone help?

Thanks,

-John

Edited July 6, 2017 by jmltinc

[Chris_Collier]

Does the mechanism have to be a shared variable? I'm currently working on testing out some TCP protocols for distributed user-interfaces, allowing one of the UIs to be on the local system. You would need to specify your data transfer protocol/how to parse messages to give you the data that you need, but it should work on any system which has TCP capabilities. This would allow for data transfer to programs other than those on the same machine as well.

If you create a TCP listener in the software receiving data, then you create a TCP connection to the IP address "Localhost" and the port specified by the listener, you should be able to open a string-based communication channel.

I haven't worked a lot with LabVIEW's network shared variables, because I like to know how stuff works (as much as possible). I also like being able to extend those solutions beyond LabVIEW, in case that becomes necessary.

Hopefully that gives a few ideas!

[ShaunR]

Each executable is a "Single Process" so the variable is only relevant in that executable. The same with "Global Variables".

You have two main options for sharing between processes. Network (TCPIP, UDP et.al) or memory mapped files..

[jmltinc]

Thanks for the replies,

Duh. "Single Process" Well, that explains that.

My first thought was to use TCP. However, and unless I am missing something here, the 'Master' application would constantly be polling for data. Due to the lag between sent and received data, I cannot have the "Master" close the second app without risk of losing any changes that were recently made, but not received. I must wait until the user closes the second app and have the master check if the second is open or not before proceeding with its database write. Maybe there is a work-around here. In the past, I have passed data using a text file and deleting it upon read - not very elegant.

OK, back to the variable. Does anyone know if a Network-Published variable can work in LabVIEW Runtime?

Thanks,

John

[Tim_S]

Network published shared variables work fine in the runtime environment. Do you have the shared variable engine installed on the runtime-only PC?

If you're going across PCs then you want to look at the shared variable primatives rather than the global/local-looking variable on the client side. You'll need to specify an IP address; the primitives is a good route to do that.

[jacobson]

4 hours ago, jmltinc said:

OK, back to the variable. Does anyone know if a Network-Published variable can work in LabVIEW Runtime?

Are you sure that your network shared variable isn't using things that require the DSC Runtime? Alarming, Deadband, Initial Value, Logging, and Scaling are all options you can configure for shared variables that would lead to the DSC Runtime being required if you aren't careful.

[JKSH]

1 hour ago, jacobson said:

Alarming, Deadband, Initial Value, Logging, and Scaling are all options you can configure for shared variables that would lead to the DSC Runtime being required if you aren't careful.

To clarify @jacobson's comment: In your .lvlib, right-click your variable and select "Properties". Disable "Alarming", "Update Deadband", "Initial Value", "Logging", and "Scaling".

Now, your variables will work with LabVIEW Runtime without the DSC module.

 

6 hours ago, jmltinc said:

My first thought was to use TCP. However, and unless I am missing something here, the 'Master' application would constantly be polling for data. Due to the lag between sent and received data, I cannot have the "Master" close the second app without risk of losing any changes that were recently made, but not received.

I'm not sure I understand. The issue would be the same, regardless of whether you use raw TCP or Network Shared Variables, right?