10-08-2009 04:49 PM
Nickerbocker wrote:The issue has to do with the references to the VIs not being closed properly. The "Auto Dispose Ref" did not seem to be doing what I had thought it was doing and these references were left in memory limbo. That was why LabVIEW would not let me make modifications to the Re-Entrant.vi after running my code. So now the problem is, if I close the reference after openning it the VI doesn't run. I have made the following modification but dislike my method because I have to pass my array of references through each event in my event node. Probably be better with a queue or maybe there is an entirely different approach I should be doing all together.
I have done quite a bit of work with spawning reentrant VI instances, and I have not encounted the problem you are describing. The Auto Dispose Ref has always successfully terminated the references to the instances after they completed execution, allowing me to make edits to the VI offline. Can you perhaps post some steps that describe what causes the refs not to be disposed? I never do the work of manually tracking the refs and closing them like you show, and have never had problems with it.
Other notes:
10-08-2009 05:30 PM - edited 10-08-2009 05:31 PM
Hi Jarrod,
Thanks for your reply. I messed with it some more, and the issue was related to me not properly terminating the loops in the spawned window.
I disabled my Close Reference operation and fed the "VI Name" to the "Open VI Reference" instead of the Path as you have suggested. Works fine.
If I open a number of windows of my Reentrant VI, and haphazardly close the windows by clicking the "x" on the upper RHS, I run into the problem described. I can't edit the particular VI until I close LabVIEW and sometimes LabVIEW will hang with me having to close it in the Task Manager.
If I open a number of windows and then properly "stop" their loops and then close their window, everything works as you have described it should work.
So lesson learned, make sure I have some mechanism for closing the internal reference to the reentrant VI if the user clicks the "x" button (by using the Panel Closed? event or something along those lines).
10-08-2009 05:32 PM - edited 10-08-2009 05:34 PM
Oh, one other thing I just realized. In this case the calling VI does not have an instance of the Reentrant VI that it consumes directly as a SubVI. Therefore, it is not clear if the VI will be in memory when the user loads the code. I would think in this situation the "VI Path" would be more appropriate. What do you think?
Edit: Or, would creating a Static Reference (like I have) force it into memory so it would be available w/ just the VI Name anyway?
10-09-2009 01:54 AM
Exactly, with a static VI reference you force the VI the be in memory. From the help: "LabVIEW loads the referenced VI into memory when you load the top-level VI".
10-09-2009 08:45 AM
If all else fails, check out this very very useful utility for aborting VIs. It can even abort modal dialog VIs, which previously generally caused people to have to kill LabVIEW from Task Manager.
10-09-2009 11:40 AM
That Abort.vi seems really cool...but it doesn't "see" my Re-Entrant.vi instances 😞 .
10-09-2009 12:42 PM - edited 10-09-2009 12:44 PM
Hmmm... That's a shame. Thanks for pointing that out.
It's probably because it uses the Application>>Get All VIs in Memory function to list out all VIs, and then determines which of those are running top-level and can be aborted. The problem is that that function will tell you a reentrant VI is in memory, but doesn't list out which reentrant instances are actually spawned. So you'll see MyReentrantVI.vi in the list, but not MyReentrantVI.vi:1 or MyReentrantVI.vi:2 or whatever. So the dialog can't query these reentrant VI instances to see if they're running top-level and can be aborted.
I only know of a very limited workaround to this problem in LabVIEW, and I doubt it's something that should be used in a general-purpose dialog like this. I'll post my example VI below that allows you to browse all Top-Level VIs running. It's really rough, but might be helpful.
Saved in LV2009. Unzip this and put the VIs in the LabVIEW 2009/Project folder, so that they're available from the Tools menu. This automatically refreshes at a set rate and lists all the top-level VIs running in the current application context, including reentrant instances! For this to work, however, you need to guestimate how many instance might be lurking around so the dialog can look for them correctly. That's what the Reentrant Clone Limit does. For instance, if this limit is set to 3, but your VI is MyReentrantVI.vi:5, it won't be displayed. Alas...
Double click a VI or click the Show FP button to open its front panel, which might help you to abort or stop it.
10-12-2009 12:02 PM
Thanks Jarrod!
I'll take a look at your code. However, now that the problem has been identified I've worked around it by adding a handler that properly closes the spawned re-entrant VI instance in the event that the user clicks the "x" button which is working effectivly at not allowing the code to get "locked up."
Thanks for your help!
-Nic
04-02-2010 02:48 PM
Anyone with LV 8.6, could you please repost Jarod's example labeled "Top-level VI Browser.zip " from 9.x to 8.6 or earlier version because I'm having the same issues and would like to try out his suggestion
Thanks.
04-02-2010 02:50 PM
Have you figured out how to open popup to the same VI as multiple clones from another VI? If so, could you please post a complete example as version 8.6?
Thanks