When to use Actors

[50616d656c61]

Hi, 

I just have a theoretical question about actors. I've just started to learn the framework but I'm not sure how I make the decision to make the classes as an actor. So that is my question: If I have a project, how do I make the decision what should be an actor and what doesn't have to be an actor? 

As an example, I've found a program, coffee shop, where they use both actors and support classes which are not actors.

Grateful for some help.

[wrkcrw00]

I use both actor classes and non-actor classes. Consider actors when you have a process that needs doing and will need to exchange messages with other processes to do it's thing. Non actor classes are great for encapsulating data and actions (methods) you might perform on that data. For example, I use a configuration object (with several inheritance levels) that is not an actor to pass config data to an actor. Wrapping up the config data in a class makes for a clean way to pass the data around and perform some simple checks and balances on the data contained within before the actor gets it and starts it's process. 

I also use non-actor classes to define sensor parameters like scaling. Sensor data needs to be scaled and many of the sensors have different types of scaling (linear, poly, log...etc). I can use a class to contain both the scaling coefficients and a method to scale the data. I actually have a scaling actor as well, whose responsibility is to receive data and process the scaling...but it's the non-actor objects that it calls to do each calc. 

It's an open ended question, but hopefully these examples give you an idea of how you can use actor vs non-actor classes.

[p4keal]

At start of a complex project it may be not clear at a glance which classes should become an actor. In doubt I would inherit from Actor.lvclass (create new classes with help of actor wizard). You can treat actors like passive LVOOP objects till You activate them via Launch Root or Nested Actor.vi. Of course You get some memory overhead due to internal data of the actor class, you can see the details in “What is the in-memory layout of a class?” section from http://www.ni.com/white-paper/3574/en/

If at the end You decide to let objects of a class passive, you can change the parent class to Object.lvclass.

I use passive actors among other things for settings dialogues. They are stored in a root actor, till user has to change settings. In this case the actor becomes active and his Actor core.vi visible.  When user closes the dialog, root actor catches the last state of the actor in Handle Last Ack.vi and actualizes the passive object in his class cluster.

Another scenario may be the migration from a LVOOP project to an AF based project. One can change the inheritance of a class to be an actor but the original project should work without problem.

[50616d656c61]

Thank you both for your replies, I think I got an idea how it can be. So I've started to write my code, so will see if it works. Thank you again!

[felipe.foz]

Hi,

A simple but interesting question. Where would you store these non-actor classes data? You prefer to use a helper loop in Actor Core or a simple Global Variable?

Regards.,

[wrkcrw00]

It depends. Most of the times, when I have these non-actor classes that are used in actor classes, I simply store the object in the actor class private data. It's the principle of composition. A class can extend it's functionality by having another class as part of it's data and that classes specific implementation is defined at runtime. 

In a similar fashion, a helper loop in an actor core can hold a non-actor object instantiation and just use shift registers to carry the object. It allows you to operate on the class in the helper loop but no where else. So, you have to be careful with this. One example I have is with an instrument that uses Modbus to communicate. The instrument is regularly turned off, but the SW is not, so I have a feature that constantly tries to connect to the instrument. I have all this buried inside of a helper loop in actor core because of the constant reconnect attempts (doing this by launching the actor, checking connection, and closing, then repeating can be problematic). The modbus connection is a class in itself but is not actor based (in fact is the Modbus library downloadable from ni.com) and is stored entirely inside actor core.

[wrkcrw00]

I rarely use fgv's, and I would avoid putting a class in one because you never know who is going to access the global and where from. At least when it's in an actor core, you know that only that instance of that actor can act on it. 

[felipe.foz]

Thank you for the quick response.

You actually confirmed what I expected. I will probably take into account when developing new actors. My first thought was a helper loop but then I thought about the private data but never seen anyone using to store data itself, but using classes as transport data (messages).

Thanks for the tip.

[felipe.foz]

---

@wrkcrw00 wrote:

I rarely use fgv's, and I would avoid putting a class in one because you never know who is going to access the global and where from. At least when it's in an actor core, you know that only that instance of that actor can act on it. 

---

I know exactly what you mean. I used to save these data in FGV's and the code can become a real mess, besides very unpredictable.