Jump to content

How can you tell if a dynamically called VI (async call) is running?

Recommended Posts

Hi All,


I'm designing the architecture for a new application. I'm looking at keeping things modular and breaking down the functionality of the system into modules (that can ultimately be re-used). For the UI, I was planning to use a subpanel vi control and load the modules into that when needed. I haven't used subpanels much in the past (we've always ended up going with a tab control, but it makes the interface less-reusable and less modular as all the user events for each "module" are in the same diagram.


Anyways, I'm having a little play and running into a small problem - how can I tell if a VI that I've called dynamically is still running? I'd half expected there to be a property for it from the same referenced used to run the VI in the first instance (I'm using the start async call to run the VI and then I place it in the subpanel). I'm quite happy that I can switch between VIs once they've been called initially, but I only want to try to call them if they've not previously been called, OR if they have been called but stopped (not sure this will actually come up as I'm still planning, but I think it could!). 


I tried putting the VI reference into a shift register and checking for valid refnum, but when I stop the dynamic VI (using a simple stop button on an event driven while loop within the dynamic VI for testing purposes), my shift reg reference remains valid (or at least, the "non a number/refnum VI returns F indicating it's still ok). Interestingly this method "does" work if I restart my calling VI after pressing stop on the dynamic vi! 


Any thoughts or suggestions would be most welcome. I'll try to put a sensible demo of what I've been trying together so people can comment if possible!





Link to comment

Does the VI Execution >> State property help at all?  The VI reference is still valid, LabVIEW still has that VI in memory even after it stops running so it will remain not Not-a-refnum until the VI is no longer in memory.  For instance you could use that reference and call the Run VI action and it would start running again.

Link to comment

Hmmm.... I missed that one to be honest - Thanks!


That said, I just tried it, and strangely it doesn't seem to work... even when I press the "stop" button to stop the dynamic VIs, the state still returns "running" - what am I missing?! 


Attached is an example of how I'm trying to do things, including the new idea of checking the execution state.


Comments more than welcome!


The other strange thing is that I was trying something similar the other day using not a refnum comparator. In that example, I was thinking more about the underlying hardware control "engines" for this application, and having a persistent engine vi for (for example) motion control, which was effectively a QSM, and then a set of API vis to call that, the initialise VI used the refnum idea to see if the refnum it had in a shift reg was valid, if not, it dynamically called the engine VI so that other VIs could then send messages via the queue. That worked fine, and I could see that the engine VI was exiting when I sent an "exit" to the queue and running when ran the intialise vi. The difference here is the use of the sub panel, I wonder if that somehow makes the system think its still running?


Any thoughts as I say, most welcome!



module play.zip

Link to comment

Okay this makes a little more sense.  Typically when I design an application like this, I don't allow my VI in the subpanel to stop itself.  I only have the parent VI (the one with the subpanel) insert/remove/or stop the VI.  You obviously need some mechanism to tell the parent VI that the child VI has stopped if you are going to allow your child VI to stop running like this.  There are many ways to do this, the easiest is probably a functional global with an array of references and an array of booleans or enums keeping track of the state of the dynamically loaded VIs.  Then your parent VI can read this global data and know to insert a new VI or use the existing reference.  Other things that could work are queues, notifiers, user events, and probably many others.

  • Like 1
Link to comment

Thanks for that - I'm not sure at this point if I will need to allow the child VI to stop itself in the end application. In all honesty, I think probably not except that I may want to be able to run the children as standalone VIs as well, in which case I'll need to be able to close them cleanly.


Is there a way to find out whether a VI has been called dynamically? e.g. could is there a property I could query inside a VI to see if it was launched dynamically from by another VI? I guess a simple way would be to have a connector pane boolean for static/dynamic and wire the relevant constant into the connector pane in the start async call so the VI knows if it was run standalone.... if it's run standalone, I can display a stop button, if not, I can hide it....


Still seems strange that the vi running state doesn't get changed even when the VI isn't running any more...


Thanks again!

Link to comment

Thanks for the link, feels a bit kludgy to me, I think I will just aim to not allow the VIs to be stopped from within the panel! 


Is it considered good practice to remove a VI from a subpanel before putting something else in? It seems you don't need to, but would be good know the best way!





Link to comment
Is it considered good practice to remove a VI from a subpanel before putting something else in? It seems you don't need to, but would be good know the best way!

I don't think it's necessary to remove a VI before inserting another.  In my subpanel applications I rarely use the Remove VI function and I've never seen any memory issues which is the only thing I would be concerned with.  With the new properties in 2012 you can even get a reference to the VI that is in the subpanel (Inserted VI Property), this is only useful if you have a VI inserted so you may want to keep the current VI inserted until a new one is selected to be inserted.

Link to comment

Join the conversation

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

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.