Run VI method in runtime engine 2011

[JoVMo]

Is this method still valid in the runtime engine 2011?

Following this post for LV8.6

http://zone.ni.com/reference/en-XX/help/371361E-01/lvprop/vi_run_vi/

After I build my VI with the execution builder, the run VI method doesn't work anymore with the runtime 2011..?

[JoVMo]

Code Snippet provided...

[JÞB]

I would be suspicious of the file path global. the vi location will be different in the exe - and, did you remember to include this dynamically called vi in the build?

[JoVMo]

I did not include the dynamically called vi's in the build.

But the vi insertion in the subpanel works. Because I see the frontpanel of the called vi displayed.

[JoVMo]

I build it with the vi included. Still doesn't work.

[SteveChandler]

Try wiring the error out of the load subpanel to the error in of the run method. Wire the error out of the run method to the shift register. Errors get swallowed in the runtime environment (I think) and your display error vi might give you a clue. Also you are only showing the "load" case. What's in the other cases? Can you attach the VI?

[JoVMo]

Steve,

Ooops, indeed, I forgot to wire the error handler on this method. I get some error now when aborting the running vi (I think).

See attachment.

[JoVMo]

I already removed the abort vi method. Because closing the vi reference is removing the vi out of memory(I think)?

But when I want to run the vi a second time, it's not in a state compatible with the operation. Is this because the vi is still in running state? How can I move it to closing state?

[SteveChandler]

On my phone so I cannot look. There is a property for the vi called execution.state or similar. Wire that to a case structure and only call the run method if it is not running.

[JÞB]

I would 100% avoid calling the abort vi method and instead find an elegant way to cause the subvi to exit.  Write a stop control value, use an AE to trigger a stop Evel a naked Global would be better than abort vi method.

And since the sub-vi is responsible for disposing of its own reference (Autodispose of ref =T) and the vi does that disposal as it exits, Stopping it by the "slamming into the tree" abort method may have unintended consequences leaving its reference in memory and the vi in a state incompatable with running.