Confused about calling vis from other vis...they seem to hang

[Hummer1]

I have a vi which works nicely to "capture an image".  There is one control named snap which causes the vi to take one image and update a global variable named current image.  There is one intensity graph which shows the image.  These are wired to the terminals of the vi.  This works fine.

Now I want to have a sequence of images taken...so I built a second vi with a timing loop and counter which I would like to use to manage when images are taken.  It works fine, except that when I get to the sequence stage where the "Capture an image" vi's snap button is pressed, the vi (Capture an image) seems to hang and never returns.  In step mode...there is a green arrow across the Capture an image vi, but there is never any output.

It's probably a newby problem, but that's what I am...

Anybody have any suggestions.

Not Humming along.

[TCPlomp]

Well most likely the 'capture and image.vi' isn't finishing. Could it be waiting on some user action?

Ton

[Hummer1]

Here is the code...what do you think?  I couldn't find a way to download the code capture tool that is on your link...any hints about that?

[Hummer1]

Here is the code again....if the attachment feature works.

[TCPlomp]

If this is the sub-VI you will have a problem.
It mainly is a VI that waits until you hit 'stop'.

The Code capture tool is located on this page if you scroll down you will find a 'Download file' button.

Ton

[Hummer1]

So, if the sub vi runs, finishes all its tasks, and then stops, it is "completed" or "finished".  Even if there is a timer running that will scan the keyboard?

Does this also apply to running sub vi's with lots of while loops, when they all "finish" and stop, is the sub vi "finished" or do you have to wrap the whole thing in a humongous (technical term from years ago) while loop and stop it to be "finished"?

Thanks a lot for your help!

Starting to Humm again.

[Dennis_Knutson]

You need to understand some basics about a while loop and a subVI. You have written a subVI with a couple of front panel controls. One is to do a snap and another is to stop the while loop. When you call this subVI, you pass control to it and it starts to run. Unless you make the front panel of the subVI visible, there is no way for the front panel buttons to be clicked. Since you pass control from the main, the main is paused - waiting for the subVI to finis.  The subVI will run forever until you kill LabVIEW. If you don't want to make the subVI's front panel visible, why even have a while loop in it? Get rid of the while loop and case statement. Make the decision in your main whether to perform a snap or not and call the modified subVI when you do.

[Hummer1]

Got it...thanks.

Fixin' to go Humm some more.

[Hummer1]

Well, I have been putting together some little demos trying to figure out how to control one vi from another.  Yes, I can strip all the controls out, make a sub vi and that works, BUT...What if I want to run lots of vi's and have them managed by some sort of executive?

I found that by using the application control vi, I can select another vi, check to make sure it is running, (if not I can start it), then cause the value of a specific control to change by using the invoke node/ method/Control Value/Set... methods.  If I run the vi without waiting for it to complete, and then use a global variable to let me know when it has done its job, that seems to work ok too.  I formed a global variable which contains all the "flags" I am passing around as booleans (very carefully named bookeans I might add) and that works too. 

I rediscovered the importance of the statement in the help files that only the change value event is useful between vi's.  This has led me to use a lot of change value events with integral case structures fed from the new value of the controls changed value.  It seems that using mechanical action (the first choice in the option box) Push down to go to true, and then reset to false in the event handler seems to work pretty well, as opposed to using a latch. 

Using the mouse down is very handy for creating events in the local vi, but the "mouse down" event doesn't exist when you are trying to make a control value (signaling) change in another vi through the invoke node method...only the change value event can be caused that way.  (since the mouse is not really interacting with the control in the remote vi.)

I watch for global variables to change by polling them in a while loop with a timer, this keeps the processor from spending all its time polling.  I wish there was an "interrupt" method of passing things around, which I guess could be done by setting a value on the executive control and and using the Generate Front Panel Activity ... that would probably work.  anything to avoid using processor time.

Anyway...thanks a bunch to all.  This has been very helpful and instructive.

If I didn't have a bunch of independently operating vis scattered in computers all over the lab that I needed to get data to and from with time stamps, It would be a lot simpler, but then it wouldn't be as much fun either.

Humming along again.

[Hummer1]

I have decided to adopt the following strategy and would appreciate comments.

When I want to exchange status information, I will place the status "flag" in a global.  One vi is thought of as being the executive.  Each vi, including the executive will have a button (hidden or not) on the front pannel called "check flags".  When a vi (other than the executive) changes a status flag, it uses the application control pallet / invoke node / control value / set  vi to set the "check flags" button on the executive to true.  This doesn't cause the executive to do anything, because I usually set all the button controls in a while loop which contains a wait for front pannel activity from the dialog and user interface control group.  BUT, you can cause a front pannel activity to occur by using the dialog and user interface control group/ cause front pannel activity right after setting the check flags button.

The result of all this should be.

None of the vis are running except the executive, other than using whatever cycles it takes to "wait for front panel activity".  The executive sets a "Do Your Thing" flag in one of the "service" vis. and causes a "check flag" event to occur on the front panel of the service vi.  The service vi finds that a front panel event has occured and does a one cycle for loop which contains the references to all the flags.  In the loop is an event loop which functions if any of the flags have changed.  Inside the event structure is a case structure which uses the new value of the flag to dictate what actions should be taken.  Since one of the flags changed when the executive changed it, the loop in the service vi operated, resets the flag, causes the service to be performed and then sets the "I'm done" flag in the global, then sets the "check flag" control on the executive, then causes a front panel change event in the executive and goes nicely back to sleep, waiting for another front panel event.

The flags can be watched on the front panel of the global for trouble shooting.

Now, whether this is more effecient than just scanning the global flags and looking for value change to cause events, I don't know.  It depends on how many vis are sitting there polling, waisting energy....(got to think green these days).  On the other hand, the speed of response to the flag change is now limited by the speed with which the control value set and cause front panel event functions occur rather than the amount of time waisted in the scanning loops looking for value changes.

That's what I think anyway.

Good luck.

the Humm