Actor Framework- Sometimes I get lost...

[BYeske]

Hey!

I'm trying to learn the Actor Framework and I have been looking through the Fan Cooler Demo.   Unfortunately, sometimes I get lost.

I somewhat get the concept, and I can follow the framework to a certain extend.

I am looking for help answering specific questions.

Here is my first question:

Inside the Feedback Cooler Actor,  a Fan System Actor is launched.  Inside the Fan System Actor Core, two Fan Actor Cores are launched.  I am lost as to why the Fan actor Core doesnt have an override Actor Core.  and to what purpose the Fan Actor Core serves.

[Todd_Lesher]

I get lost, too. I started a simple project so I could try to understand. I made the actor-cores show themselves on run until I can stop them properly. I'm slowly adding a nested actor for LV2-global replacement; override actors for simulation, for control and for display; acquisition actors (for continuous background streaming and processing); command/event logger actors; thinking about how to incorporate James' actor monitor; adding aggregated/composited classes for things like the communications transport (serial vs GPIB vs DLL, and different versions of each of those - for when the command protocol changes). Attached is a bare-bones starting point.

[BYeske]

I would like to make this thread as another resource for Beginners using the Actor Framework.

Basically used to pull together links to relevant Code that has helped you to use the Actor Framework, or LVOOP in general.

One main resource that has helped me in my transition to LVOOP programming is the Messaging Framework by drjdpowell

http://lavag.org/topic/14600-self-addressed-stamped-envelopes/page-2?hl=messaging#entry91984

Also I have seen recently a new Actor Framework Example that AristosQueue (i think) has created, but I can't find it again.

Could someone post a link to this?

And this example looks interesting, I am indexing this to come back to it later:

Windows 8 Style UI demo  done using the Actor Framework

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

[David_Staab]

Todd_Lesher wrote:

I'm slowly adding a nested actor for LV2-global replacement,,.

You probably don't want to do that. LV2-globals (and Action Engines) are synchronous and guranteed to respond to requests for data. Actors are neither.

[Todd_Lesher]

True - I've changed my approach, sort of. Most of my LV2s maintain a queue. There are times a dequeue can timeout if data is read but not written (e.g., if a stream has stopped streaming). I keep the timeout check in the LV2 wrapper API VIs. However, I have been replacing wrapper VIs with an actor that keeps its own data object/queue. Small apps still benefit from the simplicity of LV2s, but I have lots of backwards-compatibility to maintain, and lots of inter-app code sharing which lends itself well to actors (so far).

[helcio]

Hi monzue,

I am beginner in the actor framework too, and I am struggling to understand the concepts and how I use it in my projects.

From what I understood, when the Feedback Evaporative Cooler Demo.vi runs, it launches the both Actor Core.vi in the classes Dual Fan.lvclass and Cooler Panel.lvclass, as you mentioned.

Yes, it is strange that Dual Fan.lvclass has its actor launched, but does not have an Actor Core.vi inside its class. When an actor does not have an Actor Core.vi method defined for it, it will use the Actor parent class' Actor Core.vi when the Launch Actor vi is executed. In contrast, if an Actor does have an Actor Core.vi method it will have this method executed in addition to the Actor Core.vi from its parent class.

I believe that Dual Fan.lvclass only needs to have executed the Actor.vi from its parent class (Timed Loop Controller.lvclass). The Dual Fan object only needs to to do what its parent already does: Send a message to itself in order to execute the abstract method Update.vi (which is overhidden depending on the type of object). If you wanted additional functionality for the Dual Fan object like, for example, you would have to create an Actor Core.vi for the this class, and it would execute this new functionallity defined in this Actor Core.vi in addition to the one contained in the parent class of its Actor Core.vi.

Lets wait to see what the others say about it....

[David_Staab]

helcio et. al. -

When I was new to AF and actor-oriented design, I struggled with lots of the same concepts. I ended up writing myself a short "how to program with AF" reference guide. I wrote it for myself and never really cleaned it up for others to read, so I hope you find it more helpful than confusing.

Design

Normal LV programming is a synchronous dataflow model. Only the upstream node (VI) can put data on a wire; only the downstream node (VI) can see the wire data. The downstream node executes with whatever data it is given -- either doing something useful or returning an error.

The Actor Framework is intended to be an asynchronous dataflow model, with all the "pipes are secure" aspects of dataflow. Every Actor in an application has a "message handler" that it inherits from the framework. To send data to the Actor or call its public methods, you now have to send it messages. In AF, only the caller can enqueue messages, and only the actor can dequeue those messages to respond to them. [ed. There's a corner case for getting around this; I hope to post a new document about it this week.] The actor handles the messages by doing something useful or sending an error back to the caller. In general, think of messages as public methods on the Actor class. (Indeed, Msg:Do.vi can only call public and protected methods on the Actor, so this is a more literal interpretation than you might suspect.)

In addition to asynchronicity, Actor-Oriented Design requires that actors be able to ignore, drop, or delay received messages. If message amount to calling methods on the Actor class, then that class must be designed with few constraints imposed by its caller. The caller can't assume methods will return information immediately (asynchronicity), that methods will execute when "called" -- they might be cached or ignored, depending on the Actor class's current behavioral state, or that the class will "know" a method has been called. (The framework includes a "Drop Msg.vi" for handling messages that never make it to their recipient Actor.)

Finally, Actors are multi-instanceable, meaning that several copies of an Actor object can be created and "launched". This means you should design your Actor classes with stateless methods: methods can't have uninitialized shift registers or feedback nodes, and methods should normally be reentrant. Any information preserved between executions of a method must be stored in the class private data. If you don't meet this design goal, one copy of your Actor will work fine and two or more copies will behave erratically or crash entirely.

Development

Take a non-actor LV class. Implement all of its methods. This is a pure by-value class that is as fully testable as any other. Now change it to inherit from Actor.lvclass. Now, because it inherits messaging functionality from its ancestor, it is "launchable" and messageable by other Actors. Actors can call its methods by sending it messages (which you also have to define) and letting those messages call the methods directly. Has its testability changed? No. All of those methods are still just as testable.

Create actors that wrap existing classes and delegate message methods to those classes rather than creating new functionality in the actor from scratch. This lets you code and test the functionality without the overhead and complexities of dynamically launching VIs in LabVIEW. [ed. My work since writing this has shown that there are situations where you simply can't avoid developing and testing in the framework directly. Woe to you if you find yourself in one of these situations.]

If you need to add an asynchronous loop to the class, e.g. an event handler or an async data processor add it as a normal method and call that method from an override of Actor Core.vi. The normal method is testable in a static environment, and it becomes dynamic when called from the AC.vi override. The Feedback Evaporative Cooler Demo does this to create a visible Front Panel UI, but depending on the design it may limit you from testing the UI outside the framework...this can lead to some very complex test scenarios.

Debugging

There is a single location to check for the correct functioning of your actor, and there is a second single location to check for the correct sending of messages.

An actor will execute all the messages it receives. You need only check that actor to ensure that it is correct for any equence of message it receives: that it does something useful or returns an error when the message is meaningless. There is only one entity outside the actor that is capable of sending messages to the actor: the caller. That means the caller is what needs to be checked for correct messaging of the actor.

If the caller chooses to share the actor's queue with a third party, that third party now needs to be chcked as well, but there is nothing compelling the caller to share that queue and no way for third-parties to get access to the queue otherwise. We don't have access to Actors by name or any arbitrary listener/observer pattern built into the framework. [ed. I have a broadcasting extension to the framework, but the caller still has to share the broadcasting actor's message queue with other actors so they can register for broadcast messages...more on that later.]

[AristosQueue (NI)]

helcio's post is correct in its explanation for why Dual Fan does not need an Actor Core.vi implementation of its own.

[SJ_Buddy]

Hello,

I am an AF novice too. I would like to find out how "Simulated Evaporative Cooler" class is launched. I cannot find where I can switch to call real "HW Evaporative Cooler" class.

Could you help to explain to me.

Best Regards,

[mike-o-tronic]

Hi Buddy,

just take a look into the "Load App.vi" and "Actor Core.vi" of the "Air Cooler application.lvclass". This is, where the config file is read and where the appropriate class is loaded.