Jump to content

Can't programatically Abort or find Asynchronous Call 0x80


Recommended Posts

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)

 

post-17025-0-33575000-1365027343_thumb.p

 

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

 

post-17025-0-56824700-1365027527.png

 

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

Link to post
Share on other sites
  • 2 weeks later...
  • 1 year later...

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

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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. 

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Benoit
      Hello all,
      Is there any of you ever be able to push more than 30 VI in the exported VI list of VI server?
      I think I found a bug that is there since at least LabVIEW 2011.
      WAIT... don't answer the easy one... "export all VI"... if you were about to answer that, that means you are not developing a safe application.
      Thanks for any help.
       
      Benoit
    • By ensegre
      I thought there was an easy, built in, VI server way of doing the following, but I haven't found one. Am I missing something trivial?
      So I have one application instance, spawning clones of a certain VI. I would like to get an array of the VI refs of all of these clones. I thought I could via some property like  Application:All VIs in memory, but I haven't found any suitable. All VIs in memory gets only the base VI names.
      Missing that, I resort to register all my clones in a FGV as they startup, , and consult the FGV at will. Is there a more linear way?
      RegisterMovieWriters.vi
      I also note that I have to associate each VI ref with its clone name in the FGV, otherwise plain refs to different clones match as equal in lookups.
    • By John Lokanis
      I am running into an issue where my VI Server connection goes stale after a few hours.  Looking for a fast way to detect this and recover.
      Currently here is what I am doing:
      On first call, open the application reference and then open the VI reference.  Cache both of these.  Use the VI reference to call the remote VI. On subsequent calls, test the cached references to verify they are still valid and then call the remote VI. What appears to be happening is the references still appear to be valid in the caller but the connection is broken so the remote call fails.  Then I detect this and reopen the app and VI refs and can again call the remote VI.
      The issues are:
      The failing remote call takes a long time to timeout and I do not see how to control this timeout. The test of the refs does not actually test to see of the network connection is still good. The result is it takes a long time to recover and this is upsetting the user since it appears the system is locked up.
      What I need is a way to control the timeout of the 'call by reference' node or a way to quickly test the references to verify the network connection is still good before I attempt the remote call.
      Any ideas?
      thanks,
      -John
    • By Manudelavega
      Hi,
      I am trying to abort a timed loop in order to quickly stop the VI that contains it without having to wait for the next iteration to wake up the loop. The example that ships with LabVIEW works fine, but when I do what appears to be the same thing, the loop itself returns error -816: "Timed structure aborted or attempted to execute another iteration of the following aborted Timed Loop.", and the Wakeup Reason left data node is "Normal". When I run the example, there is no error and the Wakeup Reason is "Aborted".
      Does anybody know what could be different in my code? It's a complicated VI with a lot of code inside the loop, but I believe all that code is unrelated...
      One difference with the example is that the Abort function is in the same VI as the loop in the example, whereas in my case it's inside a separate VI, but that should still work, right?
      Thanks for your help!
    • By Benoit
      Hi all,
      I almost never ask for help in LabVIEW... but for this one, I have no idea where to find a solution to my problem. I'm trying to exchange data between two executable. The way I was using in the past was VI server. But it seems that there is something in LabVIEW 2011 that is not working the same way than it was working with LabVIEW 8.6. I created in my project 3 VI. One publisher, one suscriber and one GET-SET variable that will be used to exchange data between my 2 .exe.
       
      What ever I'm trying to do, I cannot figure it ou how to read the data from the Get-Set. Even having the list of VI available in memory is not working. How can I access this VI by VI Server with an address at the input of the application reference?
       
      I'm preaty sure it has something to do with security... but what....
       
      Thanks for your help.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.