Jump to content

Calling an subVI asynchronously


Recommended Posts

Hello:

 

I am working on an application where a main User Interface will need to open a subVI for a motion control system asynchronously using a menu selection.  The motion control subVI should run independently in its own window separately from the main application that initiated it.  I have the code working using the following ...

 

 

post-5394-0-27990100-1454949935.png
 
This works fine up to a point... the subVI opens in its own window and runs independently in its own window.  I use VI server within the subVI to open its front panel on startup.  
 
The problem occurs if the subVI hasn't been closed/stopped yet and the user selects the menu item again from the main UI.  An additional instance of the subVI is queued up serially.  If the user then stops the subVI then the other instance starts right up again.  
 
What I thought would work to avoid this problem is to check to see if the subVI is already running when my menu event triggers and if so just bring its window to the front using some code like...
 
post-5394-0-84848900-1454949935.png
 
and then if it is Idle I would call the subVI asynchronously using
 
post-5394-0-38504400-1454949936.png
 
However, the VI server call for the execution state never returns idle.  It always returns Running even though the subVI hasn't been started yet.  I was surprised by this, expecting it to return Idle when the subVI hadn't been called yet.
 
Does anyone have suggestions for starting this subVI and if then if it has already been started to just bring its front panel to the front?
 
Thanks,
 
Doug Harper
 
PS.  Please ignore the incorrectly labeled global variable that is passed to my subVI.  I had this in there temporarily and forgot to change it before taking screenshots.  It doesn't have any bearing on my question.
 
 
Link to comment

‘Running†means “reserved for runningâ€.   I don’t think the LabVIEW execution system, designed to handle very fast-finishing subVIs without overhead, can actually tell you if a VI is actually running at a specific point in time.   What you can do is create a reference (a queue, say) in the async-called VI and pass that back into the caller (via another temporary queue).   References like queues are automatically cleaned up when a VI hierarchy goes idle (each async-called VI runs in its own separate hierarchy), so this queue can be used to tell if a VI is still running.  

Link to comment

Well, I could probably make it work but I was hoping to be able to pass a control value to the subVI which is why I was attempting to use the asynchronous call node.

 

One could argue that if the value comes from a global like in your example, that global could well be buried inside the VI. Anyway, if the workflow is such that  the opened sub-UI has to be made aware at later time of a value change, I agree with Tim that a better message-passing channel can be set up.

 

Another UI possibility, don't know if relevant for your case, would be to make your subVI behavior modal (on entry; revert to standard on exit to avoid development trouble). That way your user would be prevented to do anything like choosing a second time from a menu in the main UI.

Link to comment

I normally use the window state to determine if the function is running already or not here. So i make sure the pop-up window will always close itself when completed, and the calling code will just check if the window is already open to determine if it should initialize and run the VI. I have attached an example here.

 

Now, this does not work if you really want the Furnace control to continue running even if the window is closed, but in such cases I would separate the GUI (only runs when window is opened) from the Furnace control (runs continously in the background), and just send adjustments to the latter from the former when they occur.

Init, run and open if not already running. Open only otherwise.zip

Link to comment

I can't explain the behavior you're seeing, but I do as shown below.  This was the only option before 'Start Asynchronous Call' existed.  The Ctrl Val.Set is obviously an example and you should modify it for your needs

post-1881-0-55332400-1455041603.png

Edited by djolivet
Link to comment
  • 2 weeks later...

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.

×
×
  • Create New...

Important Information

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