Initializing Actors

[onnodb]

Over the past week or so, I've been going through the available documentation for the Actor Framework. I'm thrilled by the opportunities for improved design it brings to the table!

I'm now trying things out in a small test application, for controlling some real hardware. I was wondering if people around here would have some advice on a couple of practical issues?

Initialization

There seem to be multiple places to perform initialization of an Actor. Throughout the various examples (e.g., the Fan, and Angry Eagles), I've come across the following solutions:

• Initialize in Actor Core.vi, before calling the parent VI.
  
• Provide a Launch MyActor.vi method, which initializes and then launches the actor.
• Override Pre Launch Init.vi (not actually observed "in the wild", but it seemed to be made for this)

Would there be any pros/cons to these different methods? My first instinct was to use Pre Launch Init.vi, but that's more due to the likeness to a traditional constructor

Errors During Initialization

A connected question: how would one handle fatal errors during initialization? Say, I have an actor that talks to a piece of hardware. When launching the actor, we hit a snag during the initialization of the hardware. What do we do? I'd say we should prevent the Actor from actually launching, and return an error to the callee.

My first attempt was to override Pre Launch Init.vi, and put the error on its "error out" terminal. This indeed prevents the Actor from launching, but the error returned from Launch Actor.vi is not the original error, but a generic message "an error occurred during Pre Launch Init".

What's the best way to handle this?

Error Handling

And, one final related question: what error handling strategies do people here use in AF-driven applications? An "error handler" Actor? Error Messages passed to the Actor's callee?

Thanks a lot for your input!

[AristosQueue (NI) · Accepted solution]

> Would there be any pros/cons to these different methods?

You should use all three methods depending upon what exactly you're trying to do. 🙂

Method	Usage	Drawback
Launch MyActor.vi	Before an actor is launched, it is a plain by-value object. Your users may call the methods of the class to set properties of the actor. If you want to encourage that certain properties be set directly (as opposed to by sending messages after launch), creating a custom Launch MyActor.vi is a reasonable approach.	Users are not guaranteed to launch the actor using this VI, so it is an encouragement only, not a guarantee. You would need to be able to handle actors that were launched by direct call to Launch Actor.vi -- either handle the default settings or return an error. Pre-Launch Init.vi is a good place to assert these settings and return an error if necessary.
Pre Launch Init.vi	An actor is in the process of launching but -- and this is important -- *none* of the Actor Core.vis have started running yet. So if your class has child classes that do work in their Actor Core, you know that none of them have started running yet. That makes Pre Launch Init.vi a great place to assert any resources that you need are available, make sure that your variables are initialized, and, as mentioned in the row above, make sure that any must-be-set properties were written by the caller.	Nested actors cannot be launched inside Pre Launch Init.vi. Doing so will hang the framework. This is somewhat deliberate (because you know multiple actors cannot be launching at the same time, acquiring multiple hardware resources can be done without establishing a semaphore or other mutex lock), although I wish we had a better way of reporting the error instead of just hanging.
Actor Core.vi	Guaranteed to be hit no matter how actor is launched. Can launch nested actors without hanging.	Child actors have already spun up their Actor Core.vi parts, so any error in initialization means tearing those back down.

[AristosQueue (NI)]

onnodb wrote:

My first attempt was to override Pre Launch Init.vi, and put the error on its "error out" terminal. This indeed prevents the Actor from launching, but the error returned from Launch Actor.vi is not the original error, but a generic message "an error occurred during Pre Launch Init".

The error that you get back from Pre Launch Init has no mechanism to be communicated back in the current version of the Actor Framework. That is the right place to put the error information.

You could create a global VI or other data storage mechanism to be used to report this error back, or you could edit the Actor.vi to take in an additional communications refnum of Your Favorite Type (notifier, queue, DVR, user event... any of them would serve) and use that to get the error back to caller.

I hope to fix this in a future version of the framework. Haven't gotten around to it yet.

onnodb wrote:

Error Handling

And, one final related question: what error handling strategies do people here use in AF-driven applications? An "error handler" Actor? Error Messages passed to the Actor's callee?

You have the ability to override "Handle Error.vi". This is the VI that controls how your actor responds to errors coming from handling messages, including the LastAck message from nested actors. After that, the error handling strategies for Actor Framework are the same as they are for any LV application.

[Todd_Lesher]

The Error Handling presentation link didn't work for me, but search found it:

https://decibel.ni.com/content/docs/DOC-17379

[David_Staab]

AQ, this is a stellar breakdown of the initialization options. This kind of tutorial/training material is the primary requirement for  the adoption of the Actor Framework across the LV community.

(The secondary requirement is a collection of more efficient mechanisms in the dev environment for generating all the boilerplate code used in AF and any other LVOOP application.)

[Todd_Lesher]

As a side note, I'm having very good luck right-clicking an existing message class and "Saving As" another one.

Debugging is another issue - stepping into a Send Message doesn't help much. jgcode (I think) and some other folks were talking about scripted probes.

[David_Staab]

I introduced an Alliance Member to AF today, and within 30 minutes of digging into it he asked me if "there's an easier way to debug these things".

[onnodb]

AristosQueue wrote:

> Would there be any pros/cons to these different methods?

You should use all three methods depending upon what exactly you're trying to do. 🙂

Method	Usage	Drawback
...

Thanks so much, AQ, this is extremely helpful!

AristosQueue wrote:

The error that you get back from Pre Launch Init has no mechanism to be communicated back in the current version of the Actor Framework. That is the right place to put the error information.

...

I hope to fix this in a future version of the framework. Haven't gotten around to it yet.

OK, good to know. I'll find another solution for now, and will be looking forward to a future fix!

Thanks a lot for your fast and extensive reply!

[justACS]

ToddLesher wrote:

As a side note, I'm having very good luck right-clicking an existing message class and "Saving As" another one.

Debugging is another issue - stepping into a Send Message doesn't help much. jgcode (I think) and some other folks were talking about scripted probes.

Get the Message Maker tool.  You can use it to autogenerate most of your messages.

[justACS]

DavidStaab wrote:

I introduced an Alliance Member to AF today, and within 30 minutes of digging into it he asked me if "there's an easier way to debug these things".

The Desktop Execution Trace Toolkit is your friend.

And yes, ToddLesher, stepping into a Send Message is pretty useless.  But the problem is rarely in getting messages to the recipients, so you can go right to the corresponding method in the recipient and pick up the trail there.