LabVIEW
Example on accessing data from an Actor object
@majoris wrote:
Yeah the Actor Framework answer is always message queues. Caller and Callee's get them for free. But if you have some other part of your program that needs to request data from an Actor you'll need to create a queues for that purpose.
I would recommend against using queues that talk between actors, as it breaks the "Actor" paradigm.
I haven't done TONS of programming with AF, but so far I have never needed queues that reach across Actors. Queue's *within* actors are great (for helper loops), but not *between* actors.
OP, what exactly are you trying to do? Part of the problem with AF is that much of the discussion is very generic and can be hard to put into practice without a solid example. In general, if you have a child Actor that is generating some data, you want to send it to the parent actor using an Actor message. For example, a DAQ actor can take data from the DAQ device, do filtering or preprocessing or scaling or whatever, then send the result to the next level actor that "does stuff" with the data.
One of the harder things to get your head around with Actors is that the whole idea is that one actor does not tell another actor what to do. It can *request* it does something, but the other actor decides what to do on its own. Actors should NOT be treated like subVI's, where one Actor calls another Actor to do something. An Actor is its own, fully contained QMH. While you can certainly have trivial Actors that just do something once then sends some data back, you'd generally be better suited by just using a subVI that can actually return some data.
For example: say you want to add two numbers together, then square that data, and add a third to it. An Actor is a poor choice for this, but a subVI would be fine. The Actor is asynchronous by nature, and this operation is one where you want something synchronous, and it does ONE thing, ONE time. If you want to change the actual operation with certain overrides, make the subVI an object or a polymorphic VI.
If you want to continually collect data, and send it back to a processor for evaluation or logging or whatever, an Actor is a good choice. You can think of it as a "producer" loop that you can drop into another Actor whenever you need one- just use the built in Actor messaging protocols, don't try to build your own around it.
I won't say there's never a use to communicate across Actors using something other than their main message queue, but I can say it's unlikely that you'd need one until you're doing something very "out there".
Ah, yes you're definitely close 🙂 I think we can get you through this. The initial learning curve trying to teach yourself AF is steep, but once it clicks, it's fairly smooth sailing from there!
So, the thing to remember is that messages are handled by the actor to whom they are sent. So, a parent actor can only receive messages meant for that particular actor (or a parent class of that actor). If you could give us an idea of what you're trying to do specifically, I can be more specific.
To get the ball rolling, you can start by having a message made in the parent actor that can act upon data received. When you make the message for that actor, you will get a "Send message" VI created for you (assuming you're using the built-in AF message creation tools, or the **wonderful** MGI Improved Message Maker, available for free!). In your child actor, call the "Get caller enqueuer" VI to get the enqueuer reference for the caller actor, and wire that to the "Send message" VI for that specific message. This will send the message to the parent VI.
Hope that helps get you started. The real benefit comes a bit after you've started to understand all of this, as you can start making abstract messages that can be used by arbitrary actors in the future. In other words, you won't have to hardcode in the specific message to send into the child- you can program in an abstract actor that will be overridden by the parent in the future.
I think a small part of your problem is just how you're visualizing Actors. The AF isn't a different way to handle OOP- it's a QMH implemented with OOP. You don't pick between AF or OOP- you use both together.
"Realtor" is a good possibility for an Actor. "Neighborhood" is likely a poor choice for an Actor, but a good choice for an Object. "House" could go either way. An Actor should ideally "do" things. A "Realtor" can receive messages (like "Sell a house" or "Buy a house"), but I'm having trouble deciding what a Neighborhood might "do". A "House" might "do" things, but still, I'm not sure what message you'd send to a house. A Heater, sure, but maybe not House.
Additionally, I don't think you'd want House to inherit from Neighborhood. A House is not a type of Neighborhood. A Neighborhood *has* Houses, so you could have an array of Houses be a member of Neighborhood. Additional members could be "Swimming pool" or "HOA" or something.
You say you'd use a one-time queue to access data stored in a QMH that's an instantiation of a House. Can I ask why you'd want House to be a QMH, not just an Object? I can guess why you'd want to do such things but it would help to be explicit.
If you DO need House to be an Actor, not just a regular Object, you would likely implement a "Request Color" message as an Abstract Message in the House Actor. A Message associated with Realtor would be "Request Color" that inherits from the one in House Actor. Messages CAN include their own queue reference, so you could send a Message that says "Hey, please send your color to this Enqueuer." The point of Abstract messages is that the layout of the message can be defined by the Child actor's Abstract message, but the specific message can be sent to the child actor by the caller actor, along with the enqueuer on which to send the message.
This is getting a bit hairy to type out but let me know if that makes sense. You're close for sure.
