shared clone subVI reserved for running when parent VI is aborted

[ghighuphu]

Dear users,

I have a couple of shared clone re-entrant VIs. It happens regurarly that when debugging the project, the shared clone subVIs are stuck in running mode (or similar). below is a picture of the panel and properties of one such subVI. I cannot stop it any way. I can close it and open it at another place or from the project tree and it is still running and not editable. I have to close the project to be able to edit that subVI.

Is this behaviour awaited, please?

If I open that subVI before I would run its parent VI, the subVI is editable. After I run the parent VI once, the subVI is locked and I cannot edit it.

p.s. On another place http://forums.ni.com/t5/LabVIEW/subvi-waiting-to-run-objective-function/m-p/2625171 I've learned that such VIs are reserved by the caller. But in my example above, the parent VI stopped or aborted and finished. So, why would it reserve other subVIs?

Cheers,

[crossrulz]

You can't edit clones.  So I'm a little confused at your problem.  Can you post a small example and steps to reproduce what you are seeing?

[ghighuphu]

Thank you for your note. There is no "(clone)" string visible in the title of the window. If I open the subVI before the parent Vi runs, the subVI is editable. If I open the subVI after the parent run, the subVI is reserved for run.

[Sam_Sharp]

Are you calling them asynchronously or are they dropped on the block diagram? If it's the former then it might be that the VI hasn't shut down because of aborting the caller instead or telling the child clones to exit.

If you press Ctrl+M, does it switch to edit mode on the VI? I'm not sure of the exact reason behind it, but when you have clones open of a VI, the main instance of it gets reserved for editing. When all of the clones shut down, you need to unreserve the main instance by putting the VI back into edit mode.

[Yamaeda]

Shared VI's can be edited by pressing CTRL+M to change to modify mode, in which case you're changing the base vi. 

/Y

[JÞB]

Re-reading : When Parent VI is Aborted.

Yeah- aborting a vi to stop it can have serious reprocussions.  Sometimes you have to do it when you realize the bug you wrote caused a lock-up or infinite loop.

Better practice: Don't write bugs!  -  serioulsy though, the behaviour is expected and painful for the developer.  You do need to finish cleaning up what the execution left laying around when you abort.  sometimes that means closing the project, closing LabVIEW, or even rebooting.

[altenbach]

---

@ghighuphu wrote:

If I open that subVI before I would run its parent VI, the subVI is editable. After I run the parent VI once, the subVI is locked and I cannot edit it.

---

Yes, this is definitely a bug and I've seen it before many times (especially when calling by reference node such as with nonlinear fitting: the model subVI remains reserved even if the toplevel VI is stopped and there is no way to edit it without e.g. restarting LabVIEW).

I have reported this is the past. What version of LabVIEW are you using?

[Yamaeda]

---

@JÞB wrote:

Re-reading : When Parent VI is Aborted.

Yeah- aborting a vi to stop it can have serious reprocussions.  Sometimes you have to do it when you realize the bug you wrote caused a lock-up or infinite loop.

Better practice: Don't write bugs!  -  serioulsy though, the behaviour is expected and painful for the developer.  You do need to finish cleaning up what the execution left laying around when you abort.  sometimes that means closing the project, closing LabVIEW, or even rebooting.

---

I've written a little utility vi that aborts all running vi's in memory, it can unlock such things, atleast sometimes. The seminar "Innovative UI design" on NI week sported a similar vi that's called "Kill 'em all" with a pretty metallica cover, so i've renamed and added that picture to mine also. 🙂

/Y

[Yamaeda]

Double post.

[JÞB]

---

@Yamaeda wrote:

---

@JÞB wrote:

Re-reading : When Parent VI is Aborted.

Yeah- aborting a vi to stop it can have serious reprocussions.  Sometimes you have to do it when you realize the bug you wrote caused a lock-up or infinite loop.

Better practice: Don't write bugs!  -  serioulsy though, the behaviour is expected and painful for the developer.  You do need to finish cleaning up what the execution left laying around when you abort.  sometimes that means closing the project, closing LabVIEW, or even rebooting.

---

I've written a little utility vi that aborts all running vi's in memory, it can unlock such things, atleast sometimes. The seminar "Innovative UI design" on NI week sported a similar vi that's called "Kill 'em all" with a pretty metallica cover, so i've renamed and added that picture to mine also. 🙂

/Y

---

You forgot the link or attachment