Integrating AF & LVOOP with hardware

[WavePacket]

---

@Taggart wrote:

Under the advanced subpallete look for Send Message and Wait for Response.vi

---

Ok, so I looked for that and ran into a weird issue. I am able to see Send Message and Wait for Response.vi in my advanced subpallete.

From this forum thread I believe my message is supposed to inherit from "reply message" 

^When I download the github referenced, I see that "RequestStatus Msg.lvlclass" inherits from LabVIEW reply message. See attached.

Now the weird bit. When I create my own actor framework and create a message with a freshly created method of an actor, I do not see reply message. See attached.

What am I missing?

[WavePacket]

---

@BertMcMahan wrote:

I'd say use an actor when you need a separate QMH for some task. If you're just reading a simple value from something, just use a regular actor. At its core, the AF is just a QMH, so if you don't need message handling or separate loops then just use a "regular" object.

For example, my DAQmx actor needed to constantly monitor data across three different types of inputs. It made sense to use an actor here, as something needed to repeatedly call DAQmx Read when data was available. I had to use a loop anyway. If I just need to, say, read a volt meter, then there's no need to maintain a separate state machine. I just initialize the object at the beginning of my test, then ask it for the current voltage when I need it.

Remember that Actors are not "super objects"; they're more like "super message handlers".

---

Yeah, Ok. That makes sense. 👍

[WavePacket]

---

@Taggart wrote:

---

@BertMcMahan wrote:

I'd say use an actor when you need a separate QMH for some task. If you're just reading a simple value from something, just use a regular actor. At its core, the AF is just a QMH, so if you don't need message handling or separate loops then just use a "regular" object.

For example, my DAQmx actor needed to constantly monitor data across three different types of inputs. It made sense to use an actor here, as something needed to repeatedly call DAQmx Read when data was available. I had to use a loop anyway. If I just need to, say, read a volt meter, then there's no need to maintain a separate state machine. I just initialize the object at the beginning of my test, then ask it for the current voltage when I need it.

Remember that Actors are not "super objects"; they're more like "super message handlers".

---

This.

And it's easy to turn any object into an Actor if you later need asynchronous behavior.

But please use composition instead of inheritance (ie instead of your class inheriting from actor, make a seperate actor that "owns" a copy of your class in its private data, and create messages that delegate each method). You'll thank me later.

---

Yeah, makes sense. Composition (and interfaces) seem to make maintaining the inheritance tree much easier.

[Taggart]

You have to add a class to your project in order for it to show up in that inheritance window. My guess it that the Reply message is not part of your project. Find it on disk, add it to your project and it should show up there.

[AristosQueue (NI)]

---

@BertMcMahan wrote:

1- Interfaces are new but they are the recommended way to go for HAL's. 

---

Allen and I are in the middle of updating the Actor Framework customer education course to discuss interfaces. NI will conduct alpha tests of the course in September with a few customers, then we'll revise, with the plan to go live for all customers some time before the end of the year. Definitely, we (Allen and I) agree with Bert's comment here. After building a couple of these systems with LV2020, we can definitively say that interfaces remove the two nastiest barriers to doing AF development: a) the difficulties testing nested actors in isolation and b) the heavy amount of boiler plate code needed to do separation of concerns between reusable nested actors and their callers.

[AristosQueue (NI)]

---

@WavePacket wrote
I do not see reply message. See attached.

What am I missing?

---

Reply Msg class is not a member of the Actor Framework library. It is not a required piece of the Actor Framework, so unless you use Reply Msgs, they aren't in your project, so they aren't in memory, so they don't show up in the Class Properties dialog as potential ancestors. You just need to open the Reply Msg.lvclass from disk (no need to formally add it to your project) and then it will be available for you to pick as a parent class for your new messages. After that, loading your class will load its parent class, so you won't need to do that in the future.

[WavePacket]

---

@AristosQueue (NI) wrote:

---

@BertMcMahan wrote:

1- Interfaces are new but they are the recommended way to go for HAL's. 

---

...Definitely, we (Allen and I) agree with Bert's comment here. After building a couple of these systems with LV2020, we can definitively say that interfaces remove the two nastiest barriers to doing AF development: a) the difficulties testing nested actors in isolation and b) the heavy amount of boiler plate code needed to do separation of concerns between reusable nested actors and their callers.

---

I have seen this youtube video (link), is that an example of interfaces simplifying the separation of concerns? 

(Also, I'll admit my ignorance about not yet knowing the difference between a "message" and an "abstract message" in AF.)

[BertMcMahan · Accepted solution]

So before Interfaces were a thing, you had to use abstract messages, which are a type of message. Generally speaking a message is an object containing some internal data that calls a specific Do.vi, within which is the method that you want to execute when that message is received. The Actor Core will receive a generic Message and execute the specific Do.vi associated with the caller's Actor. Specific classes will override Do.vi with their own version, which executes whichever code you specify.

Abstract messages are an abstract class of Message.vi that child actors use to decouple them from the main actor.

Coupling from parent to child is common because a parent always knows what child class it launches. A parent therefore knows which messages it can send to its children. This relationship can go the other way, but shouldn't. Child classes need to send data upstream to a parent class, but ideally you don't want the child to know anything about the parent. That way the child can be called by any actor, not just a specific one.

Abstract messages and Interfaces decouple the parent and child actors. Abstract messages do it by having the parent provide a message to send to the child when the child launches. A child will basically say, "Hey I have an abstract message here that I send out whenever I have new data". The caller can then generate a message that inherits from that message (called a Concrete message) that supplies the correct Do.vi for when the caller actor receives a message. That way, the child actor provides a "template" that the parent can interpret. The child therefore doesn't know anything about the parent other than the fact that the parent can receive a message with this particular content. Generally, the parent would provide the concrete message class when it launches the child. The child would interact with the concrete message as if it were an abstract one, and LVOOP handles the rest. Fortunately, you don't need to really learn all of this anymore though.

With Interfaces you no longer need an abstract class. You simply use a common interface. I believe there are some AF Interface examples in LV that I'd recommend. It's kind of something you need to play around with before it really 'clicks' (at least in my experience).

[Taggart]

That's a pretty good explanation of a rather complex topic.

[WavePacket]

Hi Guys,

I just wanted to say thanks. You all provide helpful responses to get me on my feet with Actor framework. I think I have what I need to pursue a few programs with it now.

Thanks,

-WavePacket