VI Mehod : ABORT VI

[LAVA 1.0 Content]

Hello there...I have a question to ask........ Looks silly but i dont know whats happening here....I have an application which pings to a linux based hardware and it is supposed to get some response when its pinged. If the response is not recived within some 10 seconds i am killing this vi (which is attached ) so that the main application will call this vi once again.I have used the method "ABORT VI" to kill the vi itself.(The reason why i am killing it because the "System exec" hangs or enters to "dead lock" most of the time) But when this method executes it throws an error as "Error 1000 occurred at Invoke Node in test.vi->xxxx.vi->ZZZZZZ.viPossible reason(s):LabVIEW: The VI is not in a state compatible with this operation.Method Name: Abort VI"Now i dont understand why it isnt state compatible.....? Can someone analise the same and let me know whats happening in this vi.PS: The reason why i am killing it because the "System Exec" hangs or enters to "dead lock" most of the timeOne more thing.. If u run this vi alone it will run without any problem. call this vi as subvi and then u can see the problem..May be even you can remove the "system exec: vi and rplace with a "Wait (ms)" with the "milliseconds to wait" value as anything more tha 11000 (11 seconds)

[gb119]

QUOTE([email=)

guruthilak@yahoo.com[/email]' date='Feb 15 2008, 12:59 PM' post='41737']

Hello there...I have a question to ask........ Looks silly but i dont know whats happening here....I have an application which pings to a linux based hardware and it is supposed to get some response when its pinged. If the response is not recived within some 10 seconds i am killing this vi (which is attached ) so that the main application will call this vi once again.I have used the method "ABORT VI" to kill the vi itself.(The reason why i am killing it because the "System exec" hangs or enters to "dead lock" most of the time) But when this method executes it throws an error as "Error 1000 occurred at Invoke Node in test.vi->xxxx.vi->ZZZZZZ.viPossible reason(s):LabVIEW: The VI is not in a state compatible with this operation.Method Name: Abort VI"Now i dont understand why it isnt state compatible.....? Can someone analise the same and let me know whats happening in this vi.PS: The reason why i am killing it because the "System Exec" hangs or enters to "dead lock" most of the timeOne more thing.. If u run this vi alone it will run without any problem. call this vi as subvi and then u can see the problem..May be even you can remove the "system exec: vi and rplace with a "Wait (ms)" with the "milliseconds to wait" value as anything more tha 11000 (11 seconds)

Do you really want to abort the vi - that is equivalent to stopping the entire call chain of vis ? Which, incidently is your problem: you can't Abort a sub-vi because Abort stops the entire call chain from the top-level vi downwards. It sounds like you want to do a premature return from the sub-vi call which is harder...

Do you absolutely have to use an ICMP ping packet - i.e. is this just a way of checking whether your remote hardware is on the network. if so, does it have any TCP ports open that you could attempt to open a connection to (and then close without sending any data). If so, then you can write a vi which attemps a TCP open to the correct port with a timeout set and then use the error from this to determine whether the remote machine is there to talk to. If it is, you just do a TCP close right away and other than generating some log messages it shouldn't do too much harm.

[LAVA 1.0 Content]

QUOTE(Gavin Burnell @ Feb 15 2008, 08:15 AM)

Do you really want to abort the vi - that is equivalent to stopping the entire call chain of vis ? Which, incidently is your problem: you can't Abort a sub-vi because Abort stops the entire call chain from the top-level vi downwards. It sounds like you want to do a premature return from the sub-vi call which is harder...

Do you absolutely have to use an ICMP ping packet - i.e. is this just a way of checking whether your remote hardware is on the network. if so, does it have any TCP ports open that you could attempt to open a connection to (and then close without sending any data). If so, then you can write a vi which attemps a TCP open to the correct port with a timeout set and then use the error from this to determine whether the remote machine is there to talk to. If it is, you just do a TCP close right away and other than generating some log messages it shouldn't do too much harm.

I dont have to do any operation with the H/W....Its absolutly fine...I just need to a way to perform a self kill.

[LAVA 1.0 Content]

QUOTE(guruthilak@yahoo.com @ Feb 15 2008, 08:28 AM)

I dont have to do any operation with the H/W....Its absolutly fine...I just need to a way to perform a self kill.

Ditto Gavins comments.

Have you tried specifying a time out value for the ping?

Generally the "abort VI" is not elegent since if the VI you are aborting is waiting on an I/O, the resource associated with that I/O must be cleaned-up. In Windows this could mandate killing the task.

So...

Does the timeout help?

Ben

[Aristos Queue]

QUOTE(Gavin Burnell @ Feb 15 2008, 07:15 AM)

Do you really want to abort the vi - that is equivalent to stopping the entire call chain of vis ? Which, incidently is your problem: you can't Abort a sub-vi because Abort stops the entire call chain from the top-level vi downwards. It sounds like you want to do a premature return from the sub-vi call which is harder...

Instead of using a subVI, open a VI reference to that VI and use the "Run VI" method. This starts the VI running as if it were a separate top-level VI. (Don't use Call By Ref -- that's the same as a subVI node as far as being part of the caller's hierarchy.) Since it is running as a separate top-level VI, you can call Abort VI on it.

[LAVA 1.0 Content]

QUOTE(Aristos Queue @ Feb 15 2008, 02:14 PM)

Instead of using a subVI, open a VI reference to that VI and use the "Run VI" method. This starts the VI running as if it were a separate top-level VI. (Don't use Call By Ref -- that's the same as a subVI node as far as being part of the caller's hierarchy.) Since it is running as a separate top-level VI, you can call Abort VI on it.

That is true right up till you get to doing an I/O. THe VI will be aborted BUT it may hang the LV session (at least that is what happened the last time I tried it, about a month ago under LV 8.2.1)

Ben

[Aristos Queue]

QUOTE(neB @ Feb 15 2008, 02:29 PM)

That is true right up till you get to doing an I/O. THe VI will be aborted BUT it may hang the LV session (at least that is what happened the last time I tried it, about a month ago under LV 8.2.1)

Aborting any VI is always dangerous if you're working with hardware. If you don't clean up after yourself, you have problems.

That's why I try never to use hardware. :-)

[i2dx]

QUOTE(Aristos Queue @ Feb 15 2008, 10:29 PM)

That's why I try never to use hardware. :-)

this explains a LOT

[Yair]

QUOTE(Aristos Queue @ Feb 15 2008, 11:29 PM)

That's why I try never to use hardware. :-)

And you probably do all the programming in your head, right?

"10001110100101101010110101100011010101011101010101000101010100010101010101010101101101011101010

0110101010101101010001010101110101010101011010101110101010101000101010101010101010111110101010110101

10101101110101010001010101100101010"

[LAVA 1.0 Content]

QUOTE(Aristos Queue @ Feb 15 2008, 02:14 PM)

Instead of using a subVI, open a VI reference to that VI and use the "Run VI" method. This starts the VI running as if it were a separate top-level VI. (Don't use Call By Ref -- that's the same as a subVI node as far as being part of the caller's hierarchy.) Since it is running as a separate top-level VI, you can call Abort VI on it.

This looks to be a better idea... Let me try it out. I have couple of spare H/W so i can take a risk....

[LAVA 1.0 Content]

QUOTE(guruthilak@yahoo.com @ Feb 18 2008, 12:02 AM)

This looks to be a better idea... Let me try it out. I have couple of spare H/W so i can take a risk....

OK.... Now i ma able to "Abort" a vi by calling it on a seperate thread as toplevel (or something similar) see the attachement

I have 2 quesstions to ask

1) Which is better? "Abort vi" method or the "stop" function under "Function palette->application control"? (I ma using ABort vi method currently)

2) when the vi is aborting, i can see a small pop up window (looks like the window property of this vi is "Model") which says "Resetting "vi name" " .. Now how can i remove this.. Somettime this pop stays and does not go at all making me to kill Labiew from the "windows task manager"

Any suggestions???????

[gb119]

QUOTE([email=)

guruthilak@yahoo.com[/email]' date='Feb 19 2008, 05:03 AM' post='41813']

I have 2 quesstions to ask

1) Which is better? "Abort vi" method or the "stop" function under "Function palette->application control"? (I ma using ABort vi method currently)

Not sure if it makes a huge difference, I'd go with the Stop primive since I'm sure that the Abort method is functionally the same as hitting the stop button on the toolbar which is definitely ugly...

QUOTE([email=)

guruthilak@yahoo.com

[/email]

' date='Feb 19 2008, 05:03 AM' post='41813']

2) when the vi is aborting, i can see a small pop up window (looks like the window property of this vi is "Model") which says "Resetting "vi name" " .. Now how can i remove this.. Somettime this pop stays and does not go at all making me to kill Labiew from the "windows task manager"

QUOTE(neB @ Feb 15 2008, 08:29 PM)

That is true right up till you get to doing an I/O. THe VI will be aborted BUT it may hang the

LV

session (at least that is what happened the last time I tried it, about a month ago under

LV

8.2.1)

This is why neB warned you about aborting a vi in the middle of an I/O operation (like using the system-exec). That 'resetting...' message is LabVIEW trying to clean up resources after you killed it mid-operation. You really want to be doing this by coding the operation (a 'ping' I think you said) directly in LabVIEW with suitable timeouts for the network functions. That way you get to catch a timeout error and can close connections and cleanup etc. Plus you don't have to start extra top-level vis using vi-server calls which means the code is simpler to understand and maintain...

[crelf]

QUOTE(guruthilak@yahoo.com @ Feb 19 2008, 12:03 AM)

Which is better? "Abort vi" method or the "stop" function under "Function palette->application control"? (I ma using ABort vi method currently)

Depends on how you use it - "abort VI" is called outside the VI in question, so you're forcing an abnormal end, whereas "stop" can be called in the VI, which is fine.

[Kevin P]

I used to use the "Run VI" method as my primary way to launch background code, and my older efforts would occasionally rely on the "Abort VI" method to kill one that was found to be still running at a time it shouldn't be.

As I've re-used and refactored some of that stuff, I've started using other architectures for my background code. There is still usually a "Run VI" up at the top that launches it, but the code itself is more of a queued state machine. Internally, it has its own rules for state transitions, but it can additionally be sent action messages asynchronously from the foreground code. One of those is a preemptive "Shutdown" message which will shutdown cleanly.

Each background process is accompanied by a statically-linked "Action Engine" which provides actions for "init", "shutdown", and whatever else is needed. If the foreground code calls it with a "shutdown" action, the action engine can verify successful shutdown before returning.

Recap: "Abort VI" can have ugly side effects. Sometimes background code needs to be halted gracefully, but immediately. Thus it needs to be structured such that it is continually looking for such requests. Using queues is helpful because they have the nice property of allowing you to forcibly budge and put your message at the front of the line. This can be important if you need to perform a pre-emptive but graceful shutdown.

Caveat: I still find aspects of my implementation to be cumbersome. I suspect there are some more elegant approaches, and I'd like to hear about them.

-Kevin P.

[LAVA 1.0 Content]

QUOTE(Kevin P @ Feb 19 2008, 10:23 AM)

I used to use the "Run VI" method as my primary way to launch background code, and my older efforts would occasionally rely on the "Abort VI" method to kill one that was found to be still running at a time it shouldn't be.

As I've re-used and refactored some of that stuff, I've started using other architectures for my background code. There is still usually a "Run VI" up at the top that launches it, but the code itself is more of a queued state machine. Internally, it has its own rules for state transitions, but it can additionally be sent action messages asynchronously from the foreground code. One of those is a preemptive "Shutdown" message which will shutdown cleanly.

Each background process is accompanied by a statically-linked "Action Engine" which provides actions for "init", "shutdown", and whatever else is needed. If the foreground code calls it with a "shutdown" action, the action engine can verify successful shutdown before returning.

Recap: "Abort VI" can have ugly side effects. Sometimes background code needs to be halted gracefully, but immediately. Thus it needs to be structured such that it is continually looking for such requests. Using queues is helpful because they have the nice property of allowing you to forcibly budge and put your message at the front of the line. This can be important if you need to perform a pre-emptive but graceful shutdown.

Caveat: I still find aspects of my implementation to be cumbersome. I suspect there are some more elegant approaches, and I'd like to hear about them.

-Kevin P.

Thanks a lot guys.... Let me ask the testers to test it...... if the problem persists lets c what could be done....

[Aristos Queue]

QUOTE(crelf @ Feb 19 2008, 08:41 AM)

Depends on how you use it - "abort VI" is called outside the VI in question, so you're forcing an abnormal end, whereas "stop" can be called in the VI, which is fine.

Huh? They do the same thing. Just one is external and one is internal. Both of them stop all execution paths in the VI and its hierarchy. Now, admittedly, doing the Stop inside the VI means that you're more in control of knowing what execution is being stopped, as opposed to the Abort, which has no idea what point the execution has reached. But they're both stops of execution of this VI hierarchy.

[crelf]

QUOTE(Aristos Queue @ Feb 19 2008, 02:07 PM)

...doing the Stop inside the VI means that you're more in control of knowing what execution is being stopped, as opposed to the Abort, which has no idea what point the execution has reached.

That was my point - I should have made it more explicitly than I did.