Multiple VI application

[BCL@Servodan · Accepted solution]

What i meant was, You should have only one event structure, and add the different cases to this. (You know You can do this, right?)

Try looking up the User Interface Event Handler structure by clicking File->New...->From Template->Frameworks->User Interface Event Handler.

Or try searching help for "Event structure"

Hope this helps.

[ACAT02]

Hi BCL@Servodan,

Thank you for your suggestion, It solved major part my requirement.

But I am facing an error while terminating the application via "Stop_App" button, kindly can you help me to solve the issue, I have attached updated code of my project.

And Is there any ways of implementing Multiple Event Structures or similar examples in single while loop.

Thanks Again. 

[BCL@Servodan]

What Error do You get?

I could imagine that the VI references for the VI's You have started have become invalid, as You Autodispose of the Ref, when calling the VI.

Why would You have several Event structures inside Your Loop when one could do the Job?

Also....You are aware of that using the Abort VI method, will stop Your VI as if You pushed the Abort execution button in Your toolbar, right?!

This can cause all sorts of different problem. Instead You should make sure, that all running VI's are closed down in a safe way.

As an example: One of Your (Sub)VI's is controlling an engine which is then set to run for a certain period of time and then stop. If You Abort Your (Sub)VI, You have no clue whether the engine is running or not. (It might become overheated, or something else bad could happen).

[Bob_Schor]

You are attempting to run multiple parallel routines (which LabVIEW handles really well, by the way) in a rather "uncontrolled" fashion.  Who is in charge?  Do you really want VI Front Panels popping up and obscuring other VIs?  Do you really want one VI to "abort" another (which might be in the middle of doing some critical task, perhaps involving hardware)?

This does "smell" like a homework problem (though, I must admit, a pretty advanced one).  Since you seem "stuck" on using VI Server and running multiple VIs with independent Windows, and having "too many cooks" in charge, I won't bother telling you that you've missed the idea of a hierarchy, but rather seemed to have created more of an anarchy.  The suggestion to wire False to Autodispose Reference does eliminate one error, but will probably have other consequences.

I have two recommendations that would (perhaps) enhance a hierarchy:

• Consider Start Asynchronous Call.
• Learn about Sub-Panels.

And finally, there is no such word as "hierarchial".

Bob "Close, but no cigar" Schor

[ACAT02]

Thank you BCL@Servodan for your reply, As you suggested I am using Single Event Structure, And this method has solved major part of my issue.

Only problem now I am facing is in termination of application, here I want to run all my VI's in the background until I manually choose to terminate the application from main VI, which is the reason I am passing the "stop app" value to each SubVI's to terminate any while loops running, later Aborting the VI's in main VI.

If the method used is untidy or not correct, please let me know a better method to terminate all the subVI's from the main VI on my request.

Thank You

[ACAT02]

Thank you Bob_Schor for your suggestions, I will try to implement them.

According to my requirement, One main VI will control running & termination of all my SubVI's, and I do need to pop up my SubVI's over other, also I am not dealing with any hardware, just pure LabView simulation. 

[BCL@Servodan]

Your problem lies within Your SubVI's. Because the Event structure never fires (Unless You push the "Close" button in the SubVI) the SubVI will just "hang". Hence, when You pass a TRUE to the Stop_SubVI1/Stop_SubVI2 controls, they are actually never read by the stop terminal in Your loop, as the Event structure is waiting for frontpanel activity to happen. What in fact happens, is that the VI's are aborted by the subsequent Abort VI method, which in turn gives You all the aforementioned problems. (If You try to remove the AbortVI method, You will see that the SubVI's will keep running even if You press the StopApp-button)

As Bob_Schor suggested: Rethink Your Strategy.

[Bob_Schor]

---

@ACAT02 wrote:

According to my requirement, One main VI will control running & termination of all my SubVI's, and I do need to pop up my SubVI's over other, also I am not dealing with any hardware, just pure LabView simulation. 

---

"One main VI will control running and termination of all my SubVIs".  Then remove the "Stop" buttons from your sub-VI's Front Panels, and do not let them close themselves!  Hierarchy Rule #1:  There is only One Boss.

"I do need to pop up my SubVIs over (each) other".  As you know, you need to "see the Front Panel" in order to interact with it.  So if SubVI 1 is "popped up" over SubVI 2, you can interact with SubVI 1 through its Front Panel, but you can't "see" SubVI 2, so cannot interact with its Front Panel.  It will still be running, but you won't see its outputs, nor can you change any Front Panel controls.  Hierarchy Rule #2:  Think carefully about how you interact with your Employees, especially if you can only talk to them one at a time.

At the present, you have (somewhat poorly) defined an Abstract Problem, one with somewhat conflicting demands (as pointed out above).  I suggested a number of methods that have served me well when I have one Top Level VI that is in charge of a dozen or so parallel tasks, mostly running at the same time, some of which are "View my Front Panel Most of the Time, as I've got Information You Need", some of which are "I've got information, and if you need to see it, just tell me and I'll show it to you", and others of which just "do their job and stay out of sight, out of mind".  The responsibility for stopping these "workers" comes from the Top Level VI ("The Boss"), with the proviso that a Worker could "get sick" (i.e. throw an Error) and need to stop -- in this situation, the Worker always (well, once I got it debugged, "always") signals the Boss that he (or she) is not running, so the Boss knows about it at Quitting Time.  [I love these analogies ... makes participating on the Forum a lot of fun.]

Since you are clearly engaged in a Learning Process, and since Your Situation will be different from mine, I would suggest that you clearly outline your Hierarchy (Who is in control?  Who determines whose "buttons get pushed"?) and think about the roles of Boss and Workers.  [For example, the Worker rarely has a Front Panel Control that is operable by the Program's Operator -- most of the Commands come from the Boss].  My earlier comments to you mention the LabVIEW Structures and Functions that are key to my Hierarchical design.

Bob Schor

[ACAT02]

Thank you everyone for your suggestions, I am able achieve my requirement by use of single event structure (as suggested by BCL@Servodan, Thank you).

And the error faced during close of application, was able to solve it by removing close reference functions. 

Thank you Bob_Schor, for providing a better design example to my project.