Can't programatically Abort or find Asynchronous Call 0x80

[Jon Kokott]

Un-abortable from VI Server: Start Asynchronous Call Prepare to call and forget 0x80 

 

I'm trying to abort call and forget VIs that don't get shutdown properly.

 

I'm launching using 0x80 (call and forget)

 

 

Problem is, I can't seem to find them in memory using VI server.

 

 

If I "trick" labview and just start opening a VI by name, and put in the correctly (guessed) clone name

 

i.e. dameon.vi:3

 

and it just so happens to be the right name I can find it.

 

Why isn't it appearing in all VI's in memory?

 

Is there any way to find clones of a VI through server?

 

Stranger still:

 

the name of the VI when i hover over the abort button is something like dameon.vi:Hostdaemon:ProxyCaller.234908238:3

 

wtf?  how can I abort call and forget VIs problematically?

 

Lastly, I'm aware of Abort.vi which I forget who programmed.  I got it off lavag at some point, see attached.

 

~Jon

Oh yeah, even if I get the right clone name from VI server through my educated guess, I still cant abort it problematically with the abort method.

 

Showing the front panel with an invoke node does work however (wtf? why?)

 

I can then hit the abort button on the front panel of the daemon, and it does stop.

 

~Jon

Abort_LV82_v100.zipFetching info...

[Jon Kokott]

I believe that the actor framework shows this same behavior, does anyone have a way of aborting actor framework (actors) when you forget to send the stop message?

~Jon

[Dan DeFriese]

Hey Jon,

 

There is a little task manager tool that was discussed a while back. Maybe it can help you.

 

http://lavag.org/topic/14921-labview-task-manager/page-2

 

~Dan

[Jon Kokott]

Thanks Dan, this will do the job.

 

~Jon

[Fab]

I know this is an old thread. 

But does anyone know what can cause an Asynchronous launched VI to stay running even though the entire code is done?

 

I ended up just switching back for that particular VI to using Run VI method and that worked.

 

Thanks,

Fab

[Rolf Kalbermatter]

  On 2/5/2015 at 9:57 PM, Fab said:

I know this is an old thread. 

But does anyone know what can cause an Asynchronous launched VI to stay running even though the entire code is done?

 

I ended up just switching back for that particular VI to using Run VI method and that worked.

 

Thanks,

Fab

 

A wild guess but do you call any VIs in there that call into a DLL?

[Fab]

  On 2/10/2015 at 3:22 PM, rolfk said:

A wild guess but do you call any VIs in there that call into a DLL?

 

Nope, this is a VI that one of my customers has been using in a project that calls other similar VIs asynchronously. This is the only VI to have that strange behavior.

 

I tried desperate measures like calling the Abort VI method at the end of the code, and it would still continue to run after executing that last node. The only way to stop it was to press the abort control on the tools bar.  

 

Once we replaced the call and forget code with the Run VI method, it did stop and I was able to remove the abort method.

[Phillip Brooks]

Maybe the customer VI contains multiple event structures and becomes somehow deadlocked?

[Fab]

  On 2/11/2015 at 11:39 AM, Phillip Brooks said:

Maybe the customer VI contains multiple event structures and becomes somehow deadlocked?

 

See the thing is that if I turn highlight execution both the Event handler loop on top and the Message Handler loop on the bottom finish executing, the queues get destroyed, the events unregistered and destroyed, the whole code executes, gets to the very last node (in the extreme case the VI Server Abort VI method I added), seems to execute and then the running arrow never turns off. 

 

I am just pushing this to the list of "we will never know". It is definitely not the code, because just changing the launching with start asynchronous call to using the old Run VI method just works. The VI stops right after it executes its last node. And I was able to remove the abort. 

 

I will the customer if I can share the VI. I was just curious if anyone else had seen that weird behavior. 

[odoylerules]

  On 2/12/2015 at 12:06 AM, Fab said:

See the thing is that if I turn highlight execution both the Event handler loop on top and the Message Handler loop on the bottom finish executing, the queues get destroyed, the events unregistered and destroyed, the whole code executes, gets to the very last node (in the extreme case the VI Server Abort VI method I added), seems to execute and then the running arrow never turns off. 

 

I am just pushing this to the list of "we will never know". It is definitely not the code, because just changing the launching with start asynchronous call to using the old Run VI method just works. The VI stops right after it executes its last node. And I was able to remove the abort. 

 

I will the customer if I can share the VI. I was just curious if anyone else had seen that weird behavior. 

 

 

I have seen this before as well and i couldn't track it down.  There seems to be some strange issues that arise with the "Start Async Call" function sometimes.  There is a thread on the actor framework board related to opening a vi reference twice and it causing issues with the async call.  I'm not sure if this could be related to that at all.  All i know is that there are some low level bugs that seem to pop up every once in awhile with it and they seem to come and go will not explanation :/ 

 

https://decibel.ni.com/content/message/91608#91608

[Mellroth]

  On 2/5/2015 at 9:57 PM, Fab said:

I know this is an old thread. 

But does anyone know what can cause an Asynchronous launched VI to stay running even though the entire code is done?

 

I ended up just switching back for that particular VI to using Run VI method and that worked.

 

Thanks,

Fab

 

I'm not sure it applies to your problem, but using a Strictly typed Static VI reference as an input the the Open VI reference has been a big problem for me leaving all kind of processes running in the background.

The workaround has been to replace the Strict VI reference with a strict-constant, and use a non-strict reference to get the VI name/path.

 

This workaround also applies to Actor Framework since I believe it uses the same design as the OP.

 

/J