A little dynamically-called subVI challenge for you :)

[crelf]

Hi All,

I've got a little issue that's got me scratching my head at the moment (I hope it's something minor I've missed) - I've got a main VI that calls a subVI dymaically (strict), and let's assume that the subVI runs forever (it doesn't, but let's assume that it does). I'd like button on the UI of the main VI to be able to abort the dynamically-called subVI. "Easy!" I hear you say - I've got a reference to the subVI (the same one I used to load it dynmically), and I tried to method>abort it, but I get a "not in a state compatible with this operation" error. The subVI's state is "Running" (as the attached VIs show), but I can't abort it. Has anyone got any ideas on how I could trash the VI and carry on?

This is the TopLevel VI:

http://forums.lavag.org/index.php?act=attach&type=post&id=5632

...and here's the infinitely-running subVI:

http://forums.lavag.org/index.php?act=attach&type=post&id=5633

.

[Jim Kring]

Aborting Dynamically_Called_SubVI.vi would abort the entire call, and therefore TopLevel_RunMe.vi. If you want to abort this called VI, then you need to do it, one of two ways...

1) Use a shared messaging mechanism to ask the subVI to stop doing whatever it's doing. This can be a User Event, Queue message, Notifier, etc.

2) Use the VI Run method to invoke the subVI -- this will allow you to use the VI Abort method, since the "subVI" will be running top-level.

[crelf]

QUOTE(Jim Kring @ Apr 26 2007, 07:06 AM)

Aborting Dynamically_Called_SubVI.vi would abort the entire call, and therefore TopLevel_RunMe.vi. If you want to abort this called VI, then you need to do it, one of two ways...

Thanks Jim - you've confirmed what I'd thought was going on. If I was designing it myself, I'd definately impliment the first option, but it's a lot of reverse engineering of the existing code: there's about 100 VIs that are called as plug-ins, and not all of them are easily modified (yeah, yeah, I inherited the code ). I think the easiest thing I'm going to be able to do is the VI Run method - at least then I can encapsulate the FP-control-node-value-set/run-VI/FP-indicator-node-value-read all in one VI and not distrub the dynamically-called VIs...

[ragglefrock]

QUOTE(crelf @ Apr 25 2007, 06:50 PM)

Thanks Jim - you've confirmed what I'd thought was going on. If I was designing it myself, I'd definately impliment the first option, but it's a lot of reverse engineering of the existing code: there's about 100 VIs that are called as plug-ins, and not all of them are easily modified (yeah, yeah, I inherited the code ). I think the easiest thing I'm going to be able to do is the VI Run method - at least then I can encapsulate the FP-control-node-value-set/run-VI/FP-indicator-node-value-read all in one VI and not distrub the dynamically-called VIs...

Note that Jim's method won't work if you have Wait Until Done set to True on the run call. That establishes the same caller hierarchy and produces the same error when trying to abort the dynamic VI. If you need these plugins to return data to you and still be able to abort them, you'll probably still need to dig into them to establish some event-driven communication back to the caller.

[Jim Kring]

QUOTE(ragglefrock @ Apr 25 2007, 09:34 PM)

Note that Jim's method won't work if you have Wait Until Done set to True on the run call. That establishes the same caller hierarchy and produces the same error when trying to abort the dynamic VI. If you need these plugins to return data to you and still be able to abort them, you'll probably still need to dig into them to establish some event-driven communication back to the caller.

Thanks for mentioning the Wait Until Done flag. I just (incorrectly) assumed that it was obvious that I meant to set this flag to FALSE (that's how the called VI gets into a "running top-level" state). Regardless, you can still detect whether the called VI is running and read return data, even if you set Wait Until Done to FALSE -- simply monitor the VI's execution state and when it becomes idle read the indicator values on the front panel.

[i2dx]

I use an occurence AND a global Variable in my dynamic called *SubVIs*:

http://forums.lavag.org/index.php?act=attach&type=post&id=5640

The occurence stops the SubVI in *normal* operation and I use it, as long as my Main VI is running.

The GV is set to false at the start of my main VI and is set to true, when my main VI stops. Ok, that might sound a little bit paranoid to you, but the GV ensures, that each Module is killed after the stop of my main vi, because it remains TRUE as longe as there are any callers. Even if I miss an occurence by acciendt, I can be sure, all Modules are closed when my SW stops.

[crelf]

THanks so much everyone for your great ideas - this is what I came up with. Disclaimer: I know it's not the best route, but as I said, I inherieted this code, so it's a work-around that gets me out of a tight spot.

Open a reference to the dynamically-called SubVI (herein: "SubVI")

Set the SubVI's control values

Run the SubVI (not waiting for it to finish, as Jim suggested)

Monitor the SubVI's execution state and the TopLevel VI's abort button

If the SubVI's execution state indicates that it's finished, continue

If the TopLevel VI's abort button is pressed, kill the SubVI with the "Abort VI" method

If the SubVI finshed normally, get it's indicator values

Else, ignore it's indicator values

Below is the source code on how I did it - there's a handful of things in there that might look a little odd, including where I get the control values to copy into the SubVI, but that's due to the obscure setup I'm working on. To watch it working, open both the Top Level VI and the SubVI: if you run the Top Level and don't do anything, the SubVI runs for 5 seconds and exits graciously, but if you abort it, it will stop.

http://forums.lavag.org/index.php?act=attach&type=post&id=5647

[Jim Kring]

Hey, Chris, I should have mentioned this, but I did some work on this design pattern a while back and posted an example to the OpenG forums. I call it the Asynchronous Call By Reference.

Cheers,