LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sharing complex data between LV applications on multiple machines

I have a complex data structure - plenty of controls spread on the pages of a Tab control - which I need multiple applications to have read/write access to.
Currently I have this Tab on the top-level VI, and I send its reference to applications who need to interact with the controls on its pages. This solution works great - as long as I don't try to send the reference to applications on other machines...
 
References nor global variables can pass  through the network. Any idea how I can share this data among multiple machines?
 
0 Kudos
Message 1 of 12
(5,508 Views)
why not look into using datasocket.



Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 2 of 12
(5,504 Views)

Well, basically because I have allready implemented what I need to work great on a single machine and I am afraid that using such method would require a huge amount of effort to integrate...

I've never worked yet with DataSockets. would a solution like require major changes?

0 Kudos
Message 3 of 12
(5,496 Views)

Using DS is simple. You publish the control on one side, and create a subscribing indicator on the other side and just run the server.

In this case, however, you don't need to make any changes to your code. You can get a reference to the tab from a remote computer by using Open Application Reference on the remote computer and wiring the IP address and VI server port of your computer into it, which will give you full VI server access to your application. You will need to enable the VI server first in the options menu. Read the help for Open App Reference for more details.


___________________
Try to take over the world!
Message 4 of 12
(5,492 Views)
Sorry to make trouble but I think I should say something.
 
DS will be easy to implement, but preventing race conditions across machines when more than one machine need to update a value is going to be an issue.
 
Re: accessing control references across machines did not work last time I checked. Has this changed?
 
I would suggest a more elaborate approach that will not be that easy to implement but should work.
 
1) In the existing app find all locations were the FP controls and indicators are used to control the proccess.
 
2) Use action engines (LV2's with all update operations encapsulated) to do any update operations and just use the FP to show the current values.
 
3) Serve the action engines to the "other machine" and use VI server Call by reference to act on the action engines in the same way as they are used in the first app.
 
I have used variations on this theme since LV 5.1 with great success.
 
Ben

Message Edited by Ben on 09-12-2005 12:42 PM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 12
(5,484 Views)
Hi tst,
  The 'top level' application which holds the data is in 'Run' mode while communicating with the remote application, therefore (as far as I have experianced) the remote application can't use the 'Open Application Reference' to open a reference to its caller. Please let me know if you know of any way to bypass that.
 
Ben,
 I completely lost you... Can you explain what is this 'action engine' you are refering to?
0 Kudos
Message 6 of 12
(5,476 Views)
An action engine can be thought of as a LV2 global on steroids.
 
They do whatever you need them to do depending on your app.
 
They differ from a LV2 in that they do more than just "read" and "write". Lets see if I can illustrate.
 
Lets say I have a buch of safety interlocks monitored by 8 DI lines and some motors I turn on and off with 8 DO.
 
Lets also say the DO lines can not be written individual but I have to write the whole 8-bit byte at once.
 
Continuing....
 
Lets also say that each set of interlocks and motor are used for a unique production line. DI-1 protect DO-1 etc.
 
When the operator of line 1 wants to start line 1 motor, the code should check if DI-1 is safe. So it turns out setting the DO-1 out true to turn on the motor for line 1 is dependent on DI-1 as well as the user request.
 
Using a FP you could just "disable" the line -1 motor button. In this way the FP is used to provide the protection.
 
Back to my story...
 
To turn on motor-1 the app running on machine 1 does a call by reference to an "action Engine" that holds the state of the interlocks and the states of the motors. It invokes an action like "Request motor 1 on". The action engine (running on the server) executes a state by that name that will set the boolean on for motor-1 IF the interlock for motor-1 is OK. The operation is skipped if interlock is not OK.
 
Meanwhile, back on the server...
THe server gets updates from all of the DI lines that are our interlocks. It invokes the action engine with a "update DI lines" action. In that action the DI-line states that are stored internal to the action engine and the motor DO states are shutdown if the motor was running when the false DI line was detected.
 
Depending on the complexity of the application actions are implmented inside of the action engine that provide the required functionality. Other states that come to mind would be "Stop all", "Init", Report interlock status", etc.
 
The idea boils down to putting all of the logic INSIDE the action engine so that if one line changes its output the other lines the state of the other lines is unchanged.
 
This appraoch reduces the code running on the other nodes to interfaces to the action engine.
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 7 of 12
(5,471 Views)

See attached zip (LV 7.1) for an example of a very simple action engine to control two lines.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 12
(5,467 Views)

Ben, I didn't try accessing the controls, I just assumed it will work. Does the VI server only go down to the VI level when used from a remote machine? I think it used to do that with ActiveX, but I also think that now AX can go down to the control level, so maybe network too?

Nice explanation about the action engines, BTW.

Malosh, I'm not sure what you mean by "the remote application can't use the 'Open Application Reference' to open a reference to its caller". As far as I know, if you have enabled the VI server, you should have no problem opening a reference to a running application on a remote computer.
Are you saying that the local app is the caller for the remote app???


___________________
Try to take over the world!
0 Kudos
Message 9 of 12
(5,459 Views)

Thanks tst,

 

"down to the control level, so maybe network too?"

 

That is the part that would be news to me. If I was not so busy, I'd test it for myself.

 

BTW:

You have been doing a great job here on the Exchange. If you were inclined to be so, you would be justified to be proud of what you have been doing, BUT, somehow I don't think you will have that problem.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 10 of 12
(5,449 Views)