Controlling separate VI's from one main VI

[VilleT]

So I have been tasked to build this measurement setup (Kretshmann setup) which consists of two motorized rotation stages, spectrometer and a CCD. Since I'm new to LabVIEW the task seems pretty overwhelming, and I would really use some help. I already have separate VI's for each component and the idea is to make a single main VI which will control these. The main VI will have a loop of some kind which should call the subVI's when they are needed. Programming the mainVI or the logic behind when to call the subVI's is not a problem. The problem is that I don't know how to modify the VI's such that they can be used as a subVI in the main program. I dont know if this is even possible since they are designed to be standalone programs. Any suggestions? The VI's that I plan to use are listed below in attachments

[RTSLVU]

Well it looks like you already understand the importance of using a proper program architecture like  a basic State Machine and try to do everything in "One Big Loop". (good for you!)

I would start with another State Machine and put these VI's inside. (Each individual test is a state)

Use your test plan as a guide. 

[ng1902]

Do these three loops need to communicate with each other, or do you just want one central VI to access them?

If the three VIs are standalone, how about a main VI which uses subpanels to display the subVI? You could have one subpanel and swap which VI is inserted into it using buttons or a dropdown menu, or a tab control where each tab contains a subpanel.

You could also have the main VI use the queued message handler framework. Have a button call on the main VI the various Setup VIs, with the front panels of the Setup VIs set to pop-up when called.

If you need the three subVIs and the main HMI to run all the time and communicate with each other, I'd definitely recommend looking into the Queued Message Handler framework. I think the ATM CLA Example is pretty good example of multiple QMH processes running in parallel.

[VilleT]

I think all the communication between subVI's should go through the main VI. Every subVI should still be running at all times when the main is running.

A typical usage case is like this: user turns on the mainVI program -> sets parameters for the measurements -> the device starts the measurement according to the user defined parameters -> user leaves the device to do it's thing autonomously

The mainVI loop cycle would be something like this: mainVI tells motor to move -> when movement is finished mainVI tells spectrometer and CCD to collect data -> repeat

As you can see the process is pretty simple and the best way to do this would probably be to just bite the bullet and do the subVI's from a scratch. The standalone VI's that I have now contain loops and event structures which I think are hard to implement on subVI as opposed to a simple subVI with just data in/out ports.

[wiebe@CARYA]

---

@VilleT wrote:

I think all the communication between subVI's should go through the main VI. Every subVI should still be running at all times when the main is running.

---

Simply put the three VIs parallel to the main VI's code (state machine). Then, they will always run when the main is running, and stop when you press the stop of the main VI (or any of the sub VIs). Dynamically started VI's don't do this. They tend to be dangling in memory, and it can be a hassle to get them to stop.

Make the main send command to them. This can be over a for instance a queue or user event. Both can be passed as a normal VI input, as they are on your main VI's diagram.

Guess this is a use case for Actor Framework, as you designed three actors... Not sure how easy or hard that would be. Haven't used it.

[Bob_Schor]

---

wiebe@CARYA wrote:

---

@VilleT wrote:

I think all the communication between subVI's should go through the main VI. Every subVI should still be running at all times when the main is running.

---

Simply put the three VIs parallel to the main VI's code (state machine). Then, they will always run when the main is running, and stop when you press the stop of the main VI (or any of the sub VIs). Dynamically started VI's don't do this. They tend to be dangling in memory, and it can be a hassle to get them to stop.

---

When you have parallel loops running, especially when they are configured as parallel loops in the Main VI's Block Diagram, you must stop all of the loops in order for the Main to Stop (think "Principle of Data Flow").  When the parallel loops are started dynamically, in contrast, you can stop the Main loop and the Main VI will exit, leaving the parallel loops potentially still running.  So if you want everything to stop, you need to do the same thing for Dynamic Loops, namely you need to tell them to stop.

I'm using a Messenger Channel model of the Queued Message Handler (I call it the Channel Message Handler) for my parallel loops, and use both "Loops in parallel in the Block Diagram" and "Loops started with Start Asynchronous Call" (including Reentrant Clone routines).  All of my CMH's have an "Exit" Message that gets suitably "broadcast" to all local and "detached" Loops, typically originating in the Main routine (though the Clones can also cause a Global Shutdown by sending the Main a Message asking it to initiate its Exit routine).

Bob Schor

[wiebe@CARYA]

---

@Bob_Schor wrote:

---

wiebe@CARYA wrote:

---

@VilleT wrote:

I think all the communication between subVI's should go through the main VI. Every subVI should still be running at all times when the main is running.

---

Simply put the three VIs parallel to the main VI's code (state machine). Then, they will always run when the main is running, and stop when you press the stop of the main VI (or any of the sub VIs). Dynamically started VI's don't do this. They tend to be dangling in memory, and it can be a hassle to get them to stop.

---

When you have parallel loops running, especially when they are configured as parallel loops in the Main VI's Block Diagram, you must stop all of the loops in order for the Main to Stop (think "Principle of Data Flow").  When the parallel loops are started dynamically, in contrast, you can stop the Main loop and the Main VI will exit, leaving the parallel loops potentially still running.  So if you want everything to stop, you need to do the same thing for Dynamic Loops, namely you need to tell them to stop.

I'm using a Messenger Channel model of the Queued Message Handler (I call it the Channel Message Handler) for my parallel loops, and use both "Loops in parallel in the Block Diagram" and "Loops started with Start Asynchronous Call" (including Reentrant Clone routines).  All of my CMH's have an "Exit" Message that gets suitably "broadcast" to all local and "detached" Loops, typically originating in the Main routine (though the Clones can also cause a Global Shutdown by sending the Main a Message asking it to initiate its Exit routine).

Bob Schor

---

Yes, Both dynamic VIs and normal parallel VIs should be stopped. The biggest problem with dynamic VIs is that the message doesn't get send when the main VI stops irregularly. That can be quite annoying when developing. With normal parallel VIs, they will stop when you press the red dot.

Also want to note that the choice dynamic vs normal VIs is independent from reentrant or not. I use normal (not dynamic) parallel VIs that are reentrant, so each main instantiates it's own parallel running subVIs. Pretty basic stuff, but often people seem to forget how easy it can be.

As a bonus, note that you can put the front panels of these normal parallel running VIs in a SubPanel, just like a dynamically started VI. Trick is to pass the SubPanel reference as an input, so the VI inserts itself. That also works for dynamic VIs, but dynamic VIs can be put in a subpanel by the caller, which is much harder with a normal VI that runs parallel (because you don't get a reference to it). A static reference works, but only for non-reentrant VIs.

And so on...

[Bob_Schor]

---

wiebe@CARYA wrote:

---

Yes, Both dynamic VIs and normal parallel VIs should be stopped. The biggest problem with dynamic VIs is that the message doesn't get send when the main VI stops irregularly. That can be quite annoying when developing. With normal parallel VIs, they will stop when you press the red dot.

---

We are in complete agreement!  Decent Error Handlers are an important part of a well-designed LabVIEW Project -- I usually put an "Error Trapper" as the final VI inside my Message Handler (which clears the Error line, passing the Error as data to the Error State which logs or otherwise "processes" the Error and then decides whether to try a "repair/correct" or to simply call the Exit State (which initiates the global Exits in the other parallel loops).

And what is this "Red Dot" that you press?  You aren't referring to the Abort Button on the Tool Bar, are you?  

Bob Schor

[wiebe@CARYA]

---

@Bob_Schor wrote:

And what is this "Red Dot" that you press?  You aren't referring to the Abort Button on the Tool Bar, are you?  

---

Yes, I am. "Abort Execution" formally.

Not meant at all to be used in production, but I tend to use it often during development. And since that where most of my time is spend, I want my code to behave.

Just stressing that the choice dynamic\normal parallel execution has consequences. Both have there ups and downs, and these often depend on the situation. Sometimes stopping the main should stop all code, sometimes it's very convenient to stop one part while the rest keeps running...

What I see on the forum, is that dynamic starting VIs is the de facto solution. That's OK, but it does add complexity and some practical issues (like how to stop hidden dynamic VIs (clones)).

[drjdpowell]

The OP might want to spend some time at some of the existing ”frameworks" available out there.  A lot of people have developed solutions to this problem and some of those are free and available on the tools network, including the very popular DQMH and my own Messenger Library.