Jump to content
Sign in to follow this  
Pollux

Calling other VIs to execution

Recommended Posts

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:

post-10966-1239023191.jpg?width=400

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

main.vi:

post-10966-1239023075.jpg?width=400

post-10966-1239023081.jpg?width=400

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?

Share this post


Link to post
Share on other sites

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:

post-10966-1239023191.jpg?width=400

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

main.vi:

post-10966-1239023075.jpg?width=400

post-10966-1239023081.jpg?width=400

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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. :unsure: To close the VIs I'm using the same technique (button with event handler) like in the following figure:

post-10966-1239032036.jpg?width=400

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!

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

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

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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

I have done this and it works nice now.

post-10966-1239041619.jpg?width=400

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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.

post-10966-1239650825.jpg?width=400

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.