From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor Framework Suggestions

After working with the Actor Framework, I have found a few changes I would like to suggest.

1: Instead of the case structures to handle errors from the Message:Do.vi, I would change that to an Error Handler VI with an overridable Error Handler Core.

This would allow the Child Actors a chance to catch and handle errors, and add an extra level of error handling, if desired. The Error Handler VI would still handle the error 43 for stopping the Actor. In my case, this would allow me to add in my Error Logging VI at the Actor level.

Additionaly, we use error 9999 as a place holder error during developement meaning that the particular functionality has not been implemented yet. I would rather handle this error with a popup message and log it, rather then shutdown the program.

2: Add an Initialize Message.

This message would be sent by Launch Actor.vi and have an overridable Initialize Core. This would be similar to the Stop Message. This message would allow the Child Actors to perform any initalization routines on startup without the creating actor needing to explicitly send the message or the Child Actor overriding the Actor Core.vi just to include initialization. I feel this would improve readability and understanding of the code.

3: Much like the Self-Addressed Message's "Address Message.vi", add a VI to create a Batch Message without needing to send it.

This may be a special use case, but I have found a case where creating a batch message for sending later would have removed the need for creating a special message to perform the same functionality. In my case, I have an Action Menu that consists of Buttons, each button can perform an Action, the Action, in some cases, is a Self-Addressed Message that is created when the Menu was created. When the Button is pressed the Action is performed and in a few cases the Batch Message would have been usefull. Also I would suggest including this for consistancy and completeness, with respect to the Self-Addressed Message.

I don't think performing the changes I am suggesting would break any backward compatability and feel that they would improve the Actor Framework. Feel free to tear my ideas apart and give your own suggestions, it's possible I'm failing to understand some aspects.

If anyone has a better idea on how to perform the above actions, I would love hear it.

Message was edited by: rpodsim Fixed spelling and description of error handler

Ryan Podsim, CLA
0 Kudos
Message 1 of 5
(5,273 Views)

I'll address two of these:

2.  In the current model, you do initialization in two ways.  First, you can call any of the actor's methods prior to calling Launch Actor.vi.  Second, you can call any VIs you'd like in an override of Actor Core.vi, just prior to calling Actor Core's parent node.  Either (or both) of these options are appropriate for setting up an actor's initial state.  Why would you need a separate initialization message?

If you do need one for some reason, it is certainly appropriate to create an intermediate child of Actor that adds an Initialize method and the corresponding message. Any children of that intermediate child could then receive Initialize messages, and can customize initialization with override methods.

(BTW, I usually implement error handling for my actors in just such an intermediate child.)

3.  That's an interesting idea; we may look into that.  You are certainly free to make a modified version of the Batch Message class in the mean time.

0 Kudos
Message 2 of 5
(3,512 Views)

We'll have a version 3 of the framework not too many weeks in the future. It will incorporate a lot of feedback we got from NI Week. We'll look at your changes at that point.

Re #1, we are changing the error handling mechanisms. Still trying to decide exactly how we want to do this. The problem is trying to make sure that the framework stays in charge of framework-level errors (such as the message queue being destroyed somehow or out of memory) while giving the children control over the errors of executing their particular work.

Thanks for the feedback!

0 Kudos
Message 3 of 5
(3,512 Views)

I'm not sure if this is "The Official Actor Framework Suggestions Thread" or not but I do have a suggestion...

Can someone put together a simple demo? The feedback cooler has too much going on for me to digest. A simple demo would be helpful. Maybe just a numeric indicator with an increment and decrement button?

=====================
LabVIEW 2012


0 Kudos
Message 4 of 5
(3,512 Views)

Here is the NI Week 2011 Demo:

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

It's very simple.  We have plans for more examples.

0 Kudos
Message 5 of 5
(3,512 Views)