shared clone subVI reserved for running when parent VI is aborted

[NI_PSi]

Hi ghighuphu,

did the CTRL+M shortcut do the trick?

Best regards,

Peter

[Yamaeda]

Kill 'em all attached!

/Y

[altenbach]

---

@Yamaeda wrote:

Kill 'em all attached!

---

In my case, ctrl+m does not work and the abort button is greyed out. Would your utility work in this case?

[JÞB]

---

@altenbach wrote:

---

@Yamaeda wrote:

Kill 'em all attached!

---

In my case, ctrl+m does not work and the abort button is greyed out. Would your utility work in this case?

---

The util calls the Abort VI Method on Exported VIs.  I doubt it would touch a clone.

[altenbach]

Mine is not a clone. The subVI is not reentrant

[ghighuphu]

As altenbach worte, no, it doesn't. I'll try the "Kill 'em all" program soon.

---

@NI_PSi wrote:

Hi ghighuphu,

did the CTRL+M shortcut do the trick?

Best regards,

Peter

---

[ghighuphu]

---

@altenbach wrote:

---

@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?

---

Thanks for confirming! I'am so glad you've seen it, too! It is really hard to give a minimal example for me. It is not a consistent behaviour.

I've seen this with LV2010, LV2013 and now with LV2014, too.

[ghighuphu]

---

@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.

---

I have to abort sometimes due to debugging. But as mentioned in other post in the thread (altenbach), it is not solely related to aborting the VI. It happens on a normal run, too, when all the VIs are exited and ended correctly.

[ghighuphu]

---

@ghighuphu wrote:

As altenbach worte, no, it doesn't. I'll try the "Kill 'em all" program soon.

---

KillEmAll.vi does not stop the running VIs (described above, with the "double running arrow", see screenshot) (or subVIs).

It lists 71 subVIs for me, all with "running" status. No other status appears. What do you think: Is there any chance that some of these subVIs are misbehaving and could be corrected or is this a general "call by reference" problem with non-linear fitting? What else could I check for these 71 subVIs?