Calling other VIs to execution

[Pollux]

Hello,

I'm doing a project wich will have a front panel with 3 buttons, each of them calling to execution another VI.

Like this:

(main.vi is calling calibrare.vi and achizitie.vi)

main.vi:

For some reason after calling one of them, executing and exiting the vi, the main vi doesn't respond anymore to comands.

So, what si the best way to call a vi to execution?

[mross]

QUOTE (Pollux @ Apr 6 2009, 09:09 AM)

Hello,

I'm doing a project wich will have a front panel with 3 buttons, each of them calling to execution another VI.

Like this:

(main.vi is calling calibrare.vi and achizitie.vi)

main.vi:

For some reason after calling one of them, executing and exiting the vi, the main vi doesn't respond anymore to comands.

So, what si the best way to call a vi to execution?

The VI is doing only what you asked of it.

Please investigate some example code on the use of the Event Structure.

You will see that the event structure is always enclosed in a while loop structure. This is how it repeats more than one operation.

When have an while loop structure you will need to create a means to stop the loop.

I see also that you do not have the concept of wiring data. This is so very basic that is is hard to be of help to you. You need to start finding and using example code to learn how LabVIEW works. On the block diagram menu is a light bulb icon. This slows the operation and gives a visual means of watching the data flow through the program. You should use this and carfully observe how the graphical programming system works.

Mike

[jcarmody]

QUOTE (Pollux @ Apr 6 2009, 09:09 AM)

For some reason after calling one of them, executing and exiting the vi, the main vi doesn't respond anymore to comands.

I'm wondering if your SubVI is really closing. I see your While Loop termination in the 'Achizitie' case so execution should continue in your Main VI, but apparently it isn't. Take Mike's advice and use Execution Highlighting to see what happens after you close the second VI. Perhaps you have another event configured that is stopping the loop. What/how many cases have a True wired to the loop condition terminal?

I was first struck with the Mouse Up event you're acting on; is there any reason you didn't use the Value Change event? That is typically used.

[menghuihantang]

why bother to use event structure? a simple case structure in a while loop should do as good, if not better, in this case

[Pollux]

@mrross: I have the basic concept of wiring data. But in the main.vi I don't have any data to transmit to the called subvis.

To stop the loop in the main.vi I have a button (Quiter) with an associated event handler.

@jcarmody: I'm wondering also if my subvis are really closing. To close the VIs I'm using the same technique (button with event handler) like in the following figure:

The vis can be closed from one Stop button.

And also from the close botton (x) on the title bar. If I close a called vi from that button apparently it closes only the front panel but keeps running, blocking the main.vi. How should I correct this bug?

I have changed all the "Mouse Up" events to "Value change" events in all VIs.

(Although I knew the Value Change is the correct event to use, I mistakenly selected Mouse Up for one button and continued with this for the others...)

@menghuihantang: I'm using Event structure because a guru o this forum once told me "Event structure is THE WAY to build user interfaces" (sorry I can't remamber his name :worship: ). And besides, it's easyer than using case structure.

Vhat I'm really trying to do is a interface in which main.vi is able to call a subvi (take achizitie.vi for example) but at the same time, main.vi should remain active so the user can call another subvi (calibrare.vi for example). (I hope I am clear enough...)

Thank you for your advices!

[Michael Aivaliotis]

QUOTE (Pollux @ Apr 6 2009, 08:45 AM)

And also from the close botton (x) on the title bar. If I close a called vi from that button apparently it closes only the front panel but keeps running, blocking the main.vi. How should I correct this bug?

If you want to use the (X) button then you need to use another event case called this VI panel close.

QUOTE (Pollux @ Apr 6 2009, 08:45 AM)

Vhat I'm really trying to do is a interface in which main.vi is able to call a subvi (take achizitie.vi for example) but at the same time, main.vi should remain active so the user can call another subvi (calibrare.vi for example). (I hope I am clear enough...)

Using an event structure is fine. The problem is you can't do what you want with the existing design. When LabVIEW is inside an event structure executing your subVI code, it is stuck in there and cannot respond to other user events like button presses. Actually, it queues-up events and executes them upon the next iteration of the while loop. If you want to be able to launch multiple UIs in parallel (provided that your hardware can be accessed in parallel), then you need a different approach. See image:

http://lavag.org/old_files/monthly_04_2009/post-2-1239034898.png' target="_blank">

This, in my opinion, should get you to your desired goal faster.

The alternative is using dynamic calls to parallel process VIs which might be too much for your level of experience.

[Pollux]

QUOTE (Michael Aivaliotis @ Apr 6 2009, 07:23 PM)

If you want to use the (X) button then you need to use another event case called this VI panel close.

Done. It works fine now. :worship:

QUOTE (Michael Aivaliotis @ Apr 6 2009, 07:23 PM)

Using an event structure is fine. The problem is you can't do what you want with the existing design. When LabVIEW is inside an event structure executing your subVI code, it is stuck in there and cannot respond to other user events like button presses. Actually, it queues-up events and executes them upon the next iteration of the while loop. If you want to be able to launch multiple UIs in parallel (provided that your hardware can be accessed in parallel), then you need a different approach. See image:

This, in my opinion, should get you to your desired goal faster.

The alternative is using dynamic calls to parallel process VIs which might be too much for your level of experience.

I have tested your proposal, and found out that this approach works just like the event structure. It stacks the events.

Probably the dynamic calls to parallel process is the only way to achieve my goal. Can you recommend some documentation?

[crossrulz]

The problem is that if you want three threads to run in parallel, they need to be in separate loops. If you are keeping your UI to two or three VIs, the following will be fine. Setup different while loops just like what you already have with the event structure, but have each event structure check for a different button (ie. one event structure to check Test 1, another for Test 2, and a third for Test 3 per Michael's example). If you go to more than two or three VIs, then dynamically calling would probably be best.

[Justin Reina]

@mross: that wasn't nice

Like a few other people mentioned, your deal is you want parallel stuff to run ('tasks'). So use your event structure to dispatch these tasks (use multiple loops).

Main Concept:

Responisve GUI handling should be lightweight (i.e. no event response greater than, say 20ms).

Try this concept:

Best of Luck.

-Justin

[Pollux]

QUOTE (crossrulz @ Apr 6 2009, 08:17 PM)

The problem is that if you want three threads to run in parallel, they need to be in separate loops. If you are keeping your UI to two or three VIs, the following will be fine. Setup different while loops just like what you already have with the event structure, but have each event structure check for a different button (ie. one event structure to check Test 1, another for Test 2, and a third for Test 3 per Michael's example). If you go to more than two or three VIs, then dynamically calling would probably be best.

I have done this and it works nice now.

I'm still curios to learn about dynamically processes.

QUOTE (JustinReina @ Apr 6 2009, 08:57 PM)

@mross:

that wasn't nice

Like a few other people mentioned, your deal is you want parallel stuff to run ('tasks'). So use your event structure to dispatch these tasks (use multiple loops).

Main Concept:

Responisve GUI handling should be lightweight (i.e. no event response greater than, say 20ms).

Try this concept:

Best of Luck.

-Justin

could you save the VIs in 8.0 version, please?

[Justin Reina]

oops

I've never saved for a previous version. Either the 'first' or 'second' directory contains the 8.0 version. Not sure which though, so let me know which one works!

Best of Luck,

Justin

[Neville D]

QUOTE (Pollux @ Apr 6 2009, 11:10 AM)

I have done this and it works nice now.

http://lavag.org/old_files/monthly_04_2009/post-10966-1239041619.jpg' target="_blank">

Just add a 100ms or so wait function in the false cases of the loops. So all the loops aren't running full-tilt, blocking other threads when idling waiting for User input.

Also, note, with independant loops there is no dependancy for the functions. A user can perform calibrate as the last step (instead of the first step usually..)

And the exit is a bit harsh.. quitting out of labview at a button-press. No hardware cleanup (stop process, close/release resources) required?

When you factor in all the above, it makes sense to use a Q-based State Machine with the event structure. Take a look at the templates already shipping with LabVIEW.. File>New> Frameworks>Design Patterns>Q'd Message Handler.

N.

[Mark Yedinak]

I would recommend reading up on the producer/consumer design pattern. Use the event structure to capture your UI events and process them quickly. Within the event structure you can notify the task or tasks that are processing the requests. You could use a notifier or a queue for sending the messages. I think that your last design using the four parallel loops may run into some problems. I assume that you don't want to execute your test at the same time that you are calibrating your system. This can happen in your last design since the tasks are truly independent of each other.

[Justin Reina]

@Mark: That's the pattern in my example

<br>

[Pollux]

QUOTE (Mark Yedinak @ Apr 6 2009, 09:29 PM)

I would recommend reading up on the producer/consumer design pattern. Use the event structure to capture your UI events and process them quickly. Within the event structure you can notify the task or tasks that are processing the requests. You could use a notifier or a queue for sending the messages. I think that your last design using the four parallel loops may run into some problems. I assume that you don't want to execute your test at the same time that you are calibrating your system. This can happen in your last design since the tasks are truly independent of each other.

I actually don't mind if the calibration runs at the same time with the data acquisition, since my calibration procedure doesn't access any hardware. It just corrects the data stored in a file previously acquired. If the computer running my software has enough processing power they should run fine in parallel.

@Neville D, JustinReina: I will read about queued message handler.

edit: the example in the first folder runs under LV8.0. Thank you.

[Michael Aivaliotis]

QUOTE (Pollux @ Apr 6 2009, 11:10 AM)

I have done this and it works nice now.

http://lavag.org/old_files/monthly_04_2009/post-2-1239043846.jpg' target="_blank">

Sorry, I must have been daydreaming when I wrote my suggestion. Yes, separate calls to the VIs but in separate parallel loops!

[Pollux]

Hy,

I have implemented the queue version and it works fine.

New question: what would be a clean method to close my program?

I have done this, but it does not work well.

If I enable the Exit primitive it halts LV and closes all others LV application.

If I disable the Exit primitive it stops the application but does not close it.

[Justin Reina]

This is the part where your own schemes take flight I think you're own the right track.

Perhaps a 'queue handler' that knows who is running and can be asked to kill those queues...

Maybe you enforce registering your threads with the 'queue handler'.

-Justin

[jdunham]

QUOTE (Pollux @ Apr 13 2009, 12:30 PM)

I have implemented the queue version and it works fine.

New question: what would be a clean method to close my program?

There was a diagram earlier in the thread which showed checking the App.Kind property and only exiting LabVIEW if the run-time system (a built executable) is running.

For killing a queued message handler, you can just destroy the queue itself (put this at the end of your event handler loop), and any other loop waiting on that queue will terminate immediately. Those other loops with throw Error 1, which you should filter out.