running a local VI in a remote application instance

[John Lokanis]

I am trying to think this through and see if it is even possible.  I can think of a few possible paths to go down but am not sure if either will work or if there is a better way.

 

The goal:

I have two application instances running on two different machines on the same network.

I want a VI that is part of application instance A to be displayed and executed in a sub-panel of a running VI in application instance B

 

Why?

Well, I am splitting an existing application into two parts.  A server and a client.  The UI is hosted in the client running on app instance B.  The Server is running on app instance A.  The server executes a set of plugin modules.  Some plugins require a custom prompt to be displayed to the user.  In the old system (all on one app instance) I could pass the plugin a handle to the sub panel in the UI and it could insert it's prompt VI for the user to see and take an action.  But now that they are split, I cannot do that anymore.  The plugins are created outside of both the server and the client applications so they do not know what the prompt will be until run-time.

 

Option 1.

When I update the plugin libraries, I need to push a copy to both the server machines and all client machines (already this seems like a bad idea).  Then, the server can simply tell the client what prompt to load, display and run.  I would need a mechanism for the prompt to send its data back to the server plugin.  And there would be a lot of unused files on the client side since it only needed the plugin prompt VIs and their sub vis.

 

Option 2.

When I need the client to display a prompt, the plugin would determine the local path to the prompt VI and to all of it's sub-vis (this is not too hard) and then it would load the binary data from disk for each of those VIs, send it over the network and on the client side, save it to a temp folder.  The tricky part would be to re-name (using some temp pre/suffix) the destination files and re-link them together (no idea how to do this but I think it is possible).  Then the plugin would tell the client where to find the prompt VI locally to load, display and run.  I would again need the prompt to message the server with it's output once the user responds to it.

This option, while complex, seems like the best way to go.  Since it is similar to building a source distribution, I am hopeful there is a way to do this.  I just don't know how.

 

Option 3

I can't think of another option.  Any ideas?

 

Thanks for reading.  This one has me a bit stumped.

 

Oh, and all this needs to work under the run-time engine so no scripting allowed!

 

-John

[ShaunR]

Option 3.

The server has everything labview and the client is a browser with javascript prompts and interfaces. You wouldn't even need a labview run-time on the clients.

Edited July 31, 2013 by ShaunR

[John Lokanis]

Unfortunately that is not an option for me.  The client needs a lot of custom code.  It needs to manage multiple servers at multiple sites, shared views and access control for multiple clients viewing the same server session, database recall of historical output, etc...  The client is actually more complex than the server and has just as much parallelism if not more than the server.  So, LabVIEW is a natural fit.  I would need a whole team of Javascript devs to attempt to reproduce it.

 

But thanks for the idea anyways.

[ShaunR]

Unfortunately that is not an option for me.  The client needs a lot of custom code.  It needs to manage multiple servers at multiple sites, shared views and access control for multiple clients viewing the same server session, database recall of historical output, etc...  The client is actually more complex than the server and has just as much parallelism if not more than the server.  So, LabVIEW is a natural fit.  I would need a whole team of Javascript devs to attempt to reproduce it.

 

But thanks for the idea anyways.

 

So now you are talking about something completely different. These things are infrastructure topologies. (more like Dispatcher).and don't have a lot to do with showing prompts remotely et. al. It almost sounds (without a knowing exactly what you have at the moment) like you are trying to fit a square peg in a round hole. Distributed systems have to be designed as distributed systems and if your current software isn't (distributed) then just hacking at it will not be very fruitful IMHO.

[John Lokanis]

Now we are getting off topic, but the reason to split the current system is because having the UI tied to the engine that executes the plugins means that for each instance, only one user at a time can access and control the machine.  By splitting them, the client application can view sessions from multiple servers at the same time.  And multiple clients can view sessions from the same server.  I can have one server for everything or I can have N servers as demand increases.  And I can have N clients using that same server pool.  I can also have clients view sessions based on criteria besides what server they are executing one.  With the current system, you can only see the sessions on the server you are viewing since the UI is hosted by the same application that executes the plugins.

The best analogy I can think of is a web server and browser.  The current system would be equivalent to having the web server and browser be a single EXE.  To view the web page, you would have to log onto the machine running this exe and while you were using it, no one else could.  So, to view a web page, you would need to give each user their own server/browser application.  Also imagine that while the page is being viewed by one exe, it cannot be viewed by another at the same time.  The new architecture separates these functions but the server still needs to serve up some UI information at run-time that the client cannot have prior knowledge of.  Ideally I would prefer to have the flexibility of having the UI information be a fully functional VI.  That way I am not limited in the future to what my prompts can look like or do.  But, if that is impossible I might have to make a generic prompt and simply push configuration info from the server to the client.

I have tried to keep the problem description generic because the point of the thread was to find a way to dynamically push a VI to another machine and run it.  That seems like something that would have more applications than just my current design.

 

So, not concerning yourself with my motivation, does anyone know a good way to send a VI (actually a hierarchy of VIs) from one LabVIEW EXE to another and execute it at run-time?

[ShaunR]

By splitting them, the client application can view sessions from multiple servers at the same time.  And multiple clients can view sessions from the same server.  I can have one server for everything or I can have N servers as demand increases.  And I can have N clients using that same server pool.  I can also have clients view sessions based on criteria besides what server they are executing one.

This is exactly what dispatcher achieves (all of the above). But your client (or subscriber in dispatcher) still needs the software bit to show your dialogue which is what your first thing and the following is about.

Anyhoo.

 

With the current system, you can only see the sessions on the server you are viewing since the UI is hosted by the same application that executes the plugins.

The best analogy I can think of is a web server and browser.  The current system would be equivalent to having the web server and browser be a single EXE.  To view the web page, you would have to log onto the machine running this exe and while you were using it, no one else could.  So, to view a web page, you would need to give each user their own server/browser application.  Also imagine that while the page is being viewed by one exe, it cannot be viewed by another at the same time.  The new architecture separates these functions but the server still needs to serve up some UI information at run-time that the client cannot have prior knowledge of.  Ideally I would prefer to have the flexibility of having the UI information be a fully functional VI.  That way I am not limited in the future to what my prompts can look like or do.  But, if that is impossible I might have to make a generic prompt and simply push configuration info from the server to the client.

I have tried to keep the problem description generic because the point of the thread was to find a way to dynamically push a VI to another machine and run it.  That seems like something that would have more applications than just my current design.

 

So, not concerning yourself with my motivation, does anyone know a good way to send a VI (actually a hierarchy of VIs) from one LabVIEW EXE to another and execute it at run-time?

 

Zip it up (even an entire directory of VIs if you want-zipping maintains the directory structure). Send it across, unzip it and reload (LLBs are good for this). It's a standard plugin from that point on. Of course. If your current software is monolithic, then then you will need to re-factor it to be a plugin architecture. We are lucky in LabVIEW that LV doesn't lock source files so we can read/write/modify them whilst running.

Edited August 1, 2013 by ShaunR

[John Lokanis]

At this point I am thinking of using a PPL to store the prompt and it's support files.  That way, I should be able to just send the PPL across.

 

On a side note, I am playing around with reading a VI file into LabVIEW and then writing it back to disk in a new location.  (I will need to do this because I need to send the file over the network, regardless if it is a VI, PPL or ZIP.)

For some reason, LabVIEW does not want to open my new copy of the VI, even though it is an exact byte by byte duplicate of the original (verified by comparing the file data in LV and with WinDiff).  So that is not good.

<edit: nevermind. forgot to turn of convert EOL.  works fine now> 

[ShaunR]

At this point I am thinking of using a PPL to store the prompt and it's support files.  That way, I should be able to just send the PPL across.

 

On a side note, I am playing around with reading a VI file into LabVIEW and then writing it back to disk in a new location.  (I will need to do this because I need to send the file over the network, regardless if it is a VI, PPL or ZIP.)

For some reason, LabVIEW does not want to open my new copy of the VI, even though it is an exact byte by byte duplicate of the original (verified by comparing the file data in LV and with WinDiff).  So that is not good.

<edit: nevermind. forgot to turn of convert EOL.  works fine now> 

 

I have an aversion to PPLs since they are non-reversible and some people have had issues with them (that's why I prefer zipped LLBs). I tend to use directory structures quite a lot for dynamic loading, so zip files are an easy way to mirror the structure as well as compressing and including significant numbers of VIs/LLBs. At the end of the day, it's not really important. The important bit is that you have a plug-in (or in my case, modular) architecture.

[John Lokanis]

Even the original application (now over 10 years old) uses a plug-in architecture.  (LLBs created with OpenG Builder).  But it is time to move on and try new and (hopefully) better things.  So, I will give PPLs a whirl.  But I can always fall back to LLBs if it fails.  But that is a whole different can of worms I will solve later.

Maybe I should call this a dynamically distributed plugin architecture! 

[ShaunR]

But it is time to move on and try new and (hopefully) better things. 

 

I'm more of a "If it's not broken; don't fix it" sort of person  (Like waiting until LV 2013 SP1 is released ) 

 

I think the main difference in your approach is that it will be a push rather than the more common pull distribution. If this is the case. Then security may have to be a greater consideration depending on your environment and exposure.

Edited August 1, 2013 by ShaunR