How many actors?

[Noriker]

Hi, I have an elementary question and hope someone can help.

How many actors should I create?

Suppose I have 10 identical physic devices, say generators, do I create 10 child actors inherent from a parent actor, or create one actor, generate 10 objects? Generators have the same spec, same sensors, and same control, but produce different output controlled by algorithm.

Thanks

[Oli_Wachno]

---

@Noriker wrote:

Hi, I have an elementary question and hope someone can help.

How many actors should I create?

Suppose I have 10 identical physic devices, say generators, do I create 10 child actors inherent from a parent actor, or create one actor, generate 10 objects? Generators have the same spec, same sensors, and same control, but produce different output controlled by algorithm.

Thanks

---

You create one Actor Class with properties and methods for the generator. In your program, you create x objects of that Actor class

Don't mistake classes for objects and vice versa.

The class is the definition from which you create objects from.

[Noriker]

---

@Oli_Wachno wrote:

---

@Noriker wrote:

Hi, I have an elementary question and hope someone can help.

How many actors should I create?

Suppose I have 10 identical physic devices, say generators, do I create 10 child actors inherent from a parent actor, or create one actor, generate 10 objects? Generators have the same spec, same sensors, and same control, but produce different output controlled by algorithm.

Thanks

---

You create one Actor Class with properties and methods for the generator. In your program, you create x objects of that Actor class

Don't mistake classes for objects and vice versa.

The class is the definition from which you create objects from.

---

Thanks very much for your clarification. OK, now I have X objects for X devices, how do I give each device an ID and send message to a specific device? 

We have a state machine that controls the device in a subvi at the moment. To control X device, we just copy the subvi X times. To convert this to Actor Framework, I need to convert the state machine to Actor? How to do it? Can you suggest relevant  documentation to read if it takes to long to explain please? Thanks.

[Oli_Wachno]

---

@Noriker wrote:

---

Thanks very much for your clarification. OK, now I have X objects for X devices, how do I give each device an ID and send message to a specific device? 

We have a state machine that controls the device in a subvi at the moment. To control X device, we just copy the subvi X times. To convert this to Actor Framework, I need to convert the state machine to Actor? How to do it? Can you suggest relevant  documentation to read if it takes to long to explain please? Thanks.

---

No offence intended: by the way you are asking questions, I take it you have only very little OO knowledge, the same seems to hold true for AF.

If you intend to use your current work for learning AF without real pressure, go ahead. If you need stable code in a working application soon, good luck.

Having said this: why don't you give the DQMH a go? You can have asynchronous modules running independently as well. Without having to learn OO.

[Noriker]

Thank you for stating the obvious. If I were not new, I would had not need to ask questions. You have no obligation to answer any questions, but I do hope someone else might in the "community". Everyone has to start somewhere.

As to if we should use AF, it's entirely up to us if you kindly agree!

---

@Oli_Wachno wrote:

---

@Noriker wrote:

---

Thanks very much for your clarification. OK, now I have X objects for X devices, how do I give each device an ID and send message to a specific device? 

We have a state machine that controls the device in a subvi at the moment. To control X device, we just copy the subvi X times. To convert this to Actor Framework, I need to convert the state machine to Actor? How to do it? Can you suggest relevant  documentation to read if it takes to long to explain please? Thanks.

---

No offence intended: by the way you are asking questions, I take it you have only very little OO knowledge, the same seems to hold true for AF.

If you intend to use your current work for learning AF without real pressure, go ahead. If you need stable code in a working application soon, good luck.

Having said this: why don't you give the DQMH a go? You can have asynchronous modules running independently as well. Without having to learn OO.

---

[Oli_Wachno]

Slow down.

Just wanted to focus on problems which usually come up when jumping into AF with little background knowledge.

There is usually a toplevel VI (maybe also an Actor) that start an Actor for each device required. The TopLevel starting the Actors knows the enqueuers of all Actors, thus it can den them messages.

Functionality (subVIs) have to be implemented as a part of the Actors' message handling code.

You may want to give the examples and documents in this group a go. As a good starting point for learning.

The while community is happy to help as well as point out pitfalls and issues to newbies.

Humility is key to good programming

[justACS]

---

@Noriker wrote:

---

---

Thanks very much for your clarification. OK, now I have X objects for X devices, how do I give each device an ID and send message to a specific device? 

---

Actors are LabVIEW classes, and you manipulate them as such.  You can use write accessors to pass data to the actor prior to launch, for example.

When you launch an actor (with Launch Root Actor or Launch Nested Actor), you get back an enqueuer object.  This is a wrapper for the messaging system used in Actor Framework.  An actor's enqueuer is unique, so it also serves as an ID (it's the only guaranteed unique ID available to you, in fact).

When you create a message for an actor, the message class includes a Send VI, that takes the enqueuer as an input.  Send configures the message's data and sends it to the actor.

---

We have a state machine that controls the device in a subvi at the moment. To control X device, we just copy the subvi X times. To convert this to Actor Framework, I need to convert the state machine to Actor? How to do it? Can you suggest relevant  documentation to read if it takes to long to explain please? Thanks.

---

Actors are queued message handlers (sometimes incorrectly called "state machines"), so they map really well to traditional queued message handlers.  Actors have a method called Actor Core.vi that is a QMH.  The actor's private data takes the role of the private data cluster (the cluster on the shift register), and its methods replace the individual cases in the QMH case structure.  (Most actors have additional utility methods as well.)

You can translate any QMH into an actor by moving its private data cluster into the private data of the new actor class, and moving all the code in its case structure into methods, with one method per case.  You don't need a "default" method.  You then make message classes for each of those methods, using right-click menus in your project.  This will give you a reasonable first cut for the new actor, though you will likely find, as you start connecting your actors together, that some functionality will move around between your actors.

Actors send messages to each other using their queues.  AF encourages a tree hierarchy, where actors naturally talk to the actors they created (their callers) and actors they create (their nested actors).  This strongly influences your overall system design, as the peer-to-peer communication you see in most QMH systems is discouraged.  (That sort of direct topology doesn't scale well past a handful of actors.)  Getting a good actor tree design is pretty important to your long-term success.  (This is also true for QMHs, but, since they lack the rigor of AF, you can go a long way in a bad direction before you realize it.)

This material is all covered in Actor-Oriented Design in LabVIEW, the AF course.  You mentioned in another thread that it isn't being offered regionally.  AOD in LV is not in the standard rotation, so that doesn't surprise me, but you can reach out to your sales engineers and request that it be offered, and I will PM you with some other options.

[Taggart]

I think you may be missing Oli's point. He's trying to be helfpul.

What you are proposing is like trying to learn how to swim by jumping off the high dive into the deep end of the pool, when all you've been doing so far to work up to it is wading up to your knees in the baby pool...  He's trying to point out that there are a few intermediate steps you can take (ie. DQMH and maybe learning some basic OOP) that will make progressing to the AF a little easier...

You can certainly jump off the high dive if you'd like.  People have done it and survived... then again quite a few have done it and drowned...

If you've got plenty of time to throw at your project then going to the AF may be the way to go, but if there's any pressure to get it done soon, you would be better off investigating other avenues.  

As to your original question:  I would have one generator class that inherits from actor.lvclass  The generator class would have methods to set the output, and give it an ID and whatever else you want that is common to all generators.  If you have 10 generators, then you would launch 10 generator actors. As far as sending messages to a specific generator, every time you launch a generator actor you get back an enqueur specific to that actor.  Hold onto that and use that to send commands to that specific generator.

And as per Allen's class - I definitely recommend it.  Talk to him and NI and see if you can work something out.  Get your local sales rep involved.  If you can get enough people together they will generally put on any class you ask them for.  It's a much better plan than waiting for it to be offered locally.

[Noriker]

Many thanks Allen for the simple and clear explanation.

AQ has suggested you could help us on the bases as a consultant. I feel I need to gather some background knowledge before asking you "intelligent" questions. The transition from traditional LV to AF is hard and confusing. I know I'm having trouble getting my head around. I have received your message regarding the AOD course. I'll discuss it with my manager. Many thanks for your help.

[SachaE]

Hi Noriker,

  I'm one of the Systems Engineers based out of the UK office. Having looked at the thread here, I can see there's some confusion and whilst everyone is jumping in to help, it might not be at the right level without a full context of the end goals.

If you'd like, you can call into the UK office on 01635 523545 and ask for me (Sacha) and I can see how we can help with the project and engaging with Allen etc if you want to go down the consultancy type route or we can setup a time for a skype call to show some of the major points to get you that initial leg up or answer specific questions.

I've emailed our course coordinator about when we could run the AOD and the OOP in LV courses (to incorrectly use their names...) and unfortunately he's ooo until Monday, but we can see what we can cover before then if that helps. Sometimes access to just the course material can be a huge benefit, although with courses like AOD which really examine why particular techniques are useful and where to and when to not employ them benefits from an instructor.

Thanks

Sacha