Error 1608 (from Emergency Stop)

[David_Staab]

Well who sent it? Who processed it? Where's the call chain?

And more importantly, why are we throwing errors whenever an Emergency Stop is sent? If an error caused me to send an e-stop to the recipient, then I can report that error in my Last Ack msg. The e-stop shouldn't throw an error to its recipient just because it executed....that prevents developers from ever using an e-stop in normal operation.

[justACS]

You're right; the call chain (or at least the name of the actor) should be present.  I'll have to let Stephen explain why he chose to add the error message.  For now, I will note that you can filter it out in an override of Handle Error.

[AristosQueue (NI)]

No point in generating the call chain. It would always be the same:

Actor:Actor.vi -> Stop Msg:Do.vi

The 1608 is just the stop signal. No one asked for stop to carry additional info, and, indeed, I avoided string allocations where I could in the basic framework because of comments from RT programmers.

[David_Staab]

For what it's worth, I'm asking. The current message is almost as unhelpful for debugging as Error 1, adn any RT-unsafe code can be put in a Conditional Disable structure and set to compile on non-RT targets only.

But why throw the error at all? There are fathomable situations where a "stop right now" is appropriate but not driven by an error condition that needs to spread virally throughout the application. (More like bacterially, since any error code "mutates" when it travels from the originator of the E-stop to the recipient.) Indeed, an appropriate handling response to an error in one actor might be to immediately kill its contained actors before they try to process any more messages, grab their Last Acks, and relaunch them.

Now I have to check for and filter a new error code in every actor that I might need to stop immediately.

[AristosQueue (NI)]

Why are you looking for who called EStop in the receiver of the message? This strikes me as generally a bad idea -- EStop should mean the same thing regardless of who sent it (internal, from caller or from callees). I would expect you to have differences of behavior in the sender of the message based on EStop, but not in the receiver. What use case are you running into where you want to make different decisions in the receiver?

> But why throw the error at all?

Because error is the only output from Do.vi. Otherwise you would add a "Stop?" output to every Do.vi, which every other message would be obliged to return "No" on. It does not spread uncontrollably. It spreads as far as you allow it to spread in Handle Error.vi, and, yes, the default is for EStop to spread out because that is what mostly is wanted -- to stop an entire subsystem and only repress that at the junction points, which is likely one actor in the tree.

[David_Staab]

AristosQueue wrote:

Why are you looking for who called EStop in the receiver of the message?

Because error 1608 was thrown to my launcher VI, and I don't know why. Maybe that's due to not implementing some part of the framework that I don't yet understand.

Because error is the only output from Do.vi. Otherwise you would add a "Stop?" output to every Do.vi, which every other message would be obliged to return "No" on.

Do.vi is already obliged to return "No Error" on the "Error" output you've added to it, but that didn't hold you back. Why overload the meaning of "Error" with "Stop?" Just add a separate output (a distinct channel of information) and let it default to FALSE if not wired by overrides. Overloading the error cluster with non-error information is not helpful to developers.

It does not spread uncontrollably. It spreads as far as you allow it to spread in Handle Error.vi, and, yes, the default is for EStop to spread out because that is what mostly is wanted -- to stop an entire subsystem and only repress that at the junction points, which is likely one actor in the tree.

I want the opposite to be the default. Now I have to add a Handle Error override to every actor in my design so I can filter this error that I never use in the first place. Of course, if the information for a Stop were carried in a separate output from Do.vi, you could have your cake and I could eat it too.

[komorbela]

Hi David,

I see your problem and have a less complicated solution than to change every actors:

- Create a "newActor" that has nothing but a Handle Error override, that does the filtering (or whatever you like).

- Programmatically search for all your actors and change their inheritance to "newActor".

I know it is not the easiest to search for the Actors programmatically, but this may give you a good starting point:

C:\Program Files (x86)\National Instruments\LabVIEW 2012\project\_Message Maker\_ui support\Find Classes in Project.vi

This VI in the message maker's source lists all the Actor class references of a project. After that you can filter out what you don't want to change (for example the "newActor" class ) and change the inheritance programmatically with this Property Node:

I have never done this, but have the feeling that it will work.

[David_Staab]

Yeah, I already have a couple of general-purpose base classes that modify or extend framework behavior for specific uses. Ignoring error 1608 might get added, but I first have to convince myself that I want to ignore it all the time and not just in actors that might be sent an EStop msg as part of normal operation.

[justACS]

AristosQueue wrote:

Why are you looking for who called EStop in the receiver of the message? This strikes me as generally a bad idea -- EStop should mean the same thing regardless of who sent it (internal, from caller or from callees). I would expect you to have differences of behavior in the sender of the message based on EStop, but not in the receiver. What use case are you running into where you want to make different decisions in the receiver?

If a caller were to send an e-stop to an actor and, through some oversight, not generate an error message stating that it was sending an emergency stop, the only message you would get would be a 1608 from the stopped actor.  It would be helpful in that instance to know who stopped first, to facilitate backtracking to the first cause.

On the other hand, if the caller does its job and sends a message that it is triggering an e-stop, then the 1608 would be redundant.

[justACS]

David_Staab wrote:

Yeah, I already have a couple of general-purpose base classes that modify or extend framework behavior for specific uses. Ignoring error 1608 might get added, but I first have to convince myself that I want to ignore it all the time and not just in actors that might be sent an EStop msg as part of normal operation.

When would an emergency stop be part of normal operation?  It always seemed more like an "oh, crud" event to me.