I finally got it all working. I can now cause an actor to launch on a remote system just by replacing the normal Launch Actor.vi with a new Remote Launch Actor.vi... the new VI has the identical conpane as Launch Actor but with the App Refnum input terminal. I chose to make it a separate VI instead of just adding to Launch Actor so that the AF itself is still entirely unencumbered by network code. Thus anyone who isn't using network connectivity doesn't pay the price of having to load the network classes into memory.
The connection uses VI Server. I could have used any of several other protocols, some of which would have been more secure, but I chose to go with what I know, and even that I had some difficulties with.
There's lots of documentation and comments throughout the newly added VIs. The biggest documentation is on the block diagram of "Upper Proxy Actor.lvclass:Launch Remote Actor.vi"... there you'll find a PNG of the network topology and the relationships among all the various parts.
The *only* change to the main Actor class is the addition of one new method: Receive Message.vi, which is protected and dynamic dispatch, meaning this change is fully backward compatible with AF 4.1 should we decide to make it official.
The two machines do have to be peers on the network... I did not figure out how to make a bi-directional network connection where one machine is behind a router and using port forwarding. That would have required using a different communications protocol than VI Server since I cannot open an app refnum on the client side to itself and then pass that to the server, nor is there any other credentials that I know that would work.
To see it work, here's a demo:
On the Client Machine
- Install the new experimental fork that I've posted below... this will require you to uninstall any existing AF install first (the installer checks for that).
- Unzip "Demo App.zip" posted below.
- Configure your VI Server properties in Tools >> Options to allow the server machine to connect by putting its address in the options. Or just put in "*" which will allow any machine to connect -- terribly unsecure, but works great when you keep getting your DHCP lease bumped while testing... *shakes fist at ISP*
- Open this VI: "TEST Open This on Remote Machine But Do Not Run It.vi".
On the Server Machine
- Install the new experimental fork that I've posted below... this will require you to uninstall any existing AF install first (the installer checks for that).
- Unzip "Demo App.zip" posted below.
- Configure your VI Server to allow the client machine, as described above.
- Open the VI "TEST Local With Proxy.vi".
- Before running the VI, type in the IP Address and the VI Server port for the client.
- Run the VI. You should see the panel open on the client side, and you'll see 5 heartbeat messages from the client to the server, and then the whole system should shut down cleanly.
- Run it again, but this time leave the IP Address blank... this will cause the nested actor to launch on the local system.
That's it. Let me know what you think.
Update by niACS (8/24/15): I have attached a new version of the Launch Remote Actor package, which can be used with LabVIEW 2014 and later. The new package consists of only three actors (Proxy, Upper Proxy, and Lower Proxy) and does not modify the core framework that ships with LabVIEW.
This version comes in a VI Package Configuration, and includes the demo files (which get installed in the examples folder).
This version does not include support for the Desktop Execution Trace Toolkit. In the near future, I will post a version that does, but that version will only work with LabVIEW 2015 and later.
Update by niACS (9/9/15): The VIPC I posted last month had a bug that affected redirection of Stop and Last Ack messages. I have removed that version, and attached a new one that fixes the problem. The new VIPC has the version number of the core package attached (1.0.0.15, in this case). If you have downloaded the previous version, I strongly recommend you upgrade to the new version.
