Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1608 (from Emergency Stop)

David: I'm guessing you want to override Handle Last Ack Core.vi to ignore 1608 when sent to you from a nested actor.

0 Kudos
Message 11 of 25
(2,411 Views)

I want to get rid of error 1608 entirely, along with the use of error 43 to stop the actor, and to add a Boolean output labeled "Stop" to Do.vi. I realize that breaks compatibility in what is now  a vi.lib function, so the odds of it happening are only slightly higher than <insert election season joke here>, so I guess I'll settle for ignoring 1608 when sent from a nested actor.

0 Kudos
Message 12 of 25
(2,411 Views)

When you want to prevent a nested actor from processing messages in the queue because of some condition in the owning actor (an error, a state change, etc.). The enqueued messages can be handled  using Drop Msg Core.vi, and the nested actor can be re-launched using its prior state from Last Ack Msg.lvclass.

0 Kudos
Message 13 of 25
(2,411 Views)

I think what the poster would like is the following solution. Edit the Do.vi from the Actor Framework Message.lvclass to handle the error like below..

Do.vi.png

In my example it shows a 1 button dialog window which looks like this:

Do.vi Message.png

If you edited the original Do.vi from the Actor Framework the only thing left to do is implement 'Call Parent Method' after every function inside every Do.vi, like depicted below:

Do.vi  function.png

I hope you found this post usefull.

0 Kudos
Message 14 of 25
(2,411 Views)

There's no need to edit the Message:Do.vi. Just create a subVI that does what you're doing to the error and invoke that subVI in the Do.vis that you want it included in. Even better... there's no need to route the Actor through that subVI at all.

The only reason that you would modify Message:Do.vi is if you were ALSO enabling the setting "Must Call Parent", which would break all the Do.vi implementations unless they called up to your modification function. That's not something I would do for the AF generally, but if you're copying the AF off and making your own library from it, you might want to do that.

0 Kudos
Message 15 of 25
(2,411 Views)

But I do want a standardized action to be taken after an error occurs. If I create a SubVI then every actor would get a dependency to that subVI. However if I modify the common Do.vi the dependency already excists, so nothing really changes only every Do.vi function can choose to have 'Error Handling' or not.

Even more so if I modify the Do.vi to send the received Error to an actual Error Handler Actor, I have the beginnings of a solid Error Handling.

0 Kudos
Message 16 of 25
(2,411 Views)

In my application, any error is fatal, so I simply override Handle Error in all my actors. Each actor's Handle Error uses the AF "Send Error Report" message to its caller (if it's not Error 43). The error then bubbles up to my top level actor (application controller) whose Handle Error calls the General Error Handler dialog and logs it to a file. The "Stop Actor" boolean indicator is set to TRUE by default in Handle Error so my application exits after the user acknowledges the dialog.

0 Kudos
Message 17 of 25
(2,411 Views)

BillMe wrote:

In my application, any error is fatal, so I simply override Handle Error in all my actors. Each actor's Handle Error uses the AF "Send Error Report" message to its caller (if it's not Error 43). The error then bubbles up to my top level actor (application controller) whose Handle Error calls the General Error Handler dialog and logs it to a file. The default behaviour once the user acknowledges the dialog is to send a Stop message to all nested actors and exit the application.

Why not just use the error reporting built in to Last Ack?

When an actor stops, it embeds its final error value in the Last Ack message, which is sent to its caller.  When the caller handles Last Ack, it puts that error value on its own error wire, which will make it stop, passing on a Last Ack to its caller, etc.  Your top level error handling remains unchanged (log and report error).

0 Kudos
Message 18 of 25
(2,411 Views)

I think I used Handle Error because many of my actors have worker threads in their override of Actor Core. They call "Send Error Report" if they encounter an error.

I guess I need to revisit what I'm doing to see if I'm overcomplicating the issue.

0 Kudos
Message 19 of 25
(2,411 Views)

BillMe wrote:

I think I used Handle Error because many of my actors have worker threads in their override of Actor Core. They call "Send Error Report" if they encounter an error.

OK.  So the worker thread (aka helper loop) uses Send Error Report to put an error on its own actor queue.  That will trigger a stop without any change to that actor's Handle Error.

0 Kudos
Message 20 of 25
(2,411 Views)