Actor Framework Discussions
AF: Simple (Serial) Communication Example
Solved!
Oli is correct in that an Actor is something like a QMH itself, but you can also have a second QMH in Actor Core. This is called a "helper loop" which can run asynchronously from the main Actor, and is a great way to do things like serial communication. You will want the helper loop to *only* be accessible from its Actor, via a Queue/User event/etc, typically placed in the actor's private data. The Actor can receive a message do "do something" and it can communicate this need to its helper loop to "do the thing".
For example, if you're sending serial data, you COULD put it in a message, where the serial communication happens in the main Actor Core loop. If it's a short, small message with few delays, that's a perfectly fine way to do it. Just know that, since it blocks, new messages will queue up and not get handled until the serial part unblocks. Another way to do it would be to have a dedicated Serial helper loop, where the message simply sends a command to the helper loop.
For my DAQmx reading actors, I typically have a helper loop that's running the DAQ sampling stuff, as I don't want it doing anything but servicing the DAQ. When it gets new data, it can send it as a message to the Actor Core, which can then broadcast it to whoever else needs it.
One more thing I forgot to mention last week. My first DAQmx actor tried to stay alive for the entire duration of my program, starting out in an "idle" state, then able to connect to a DAQ device as-needed, then disconnect when not needed. It was a pretty messy state diagram, when I realized- if there's no DAQ action taking place, why do I need a DAQ actor to be alive? I changed the whole thing around. Now, it attempts to get access to the DAQ card during Pre-launch Init.vi, and if it can't, then the actor launch fails. If it can, it immediately starts doing whatever it was I needed it to do. When I don't need DAQ access anymore, I simply stop the actor. When I need it again, I relaunch the actor.
This may or may not make sense for your specific use case, but it wasn't obvious to me at first. In short, I changed the thought from "launch an actor to be used and reused for the life of my program" into "launch the actor when it's needed for as long as it's needed, then close it again". It *drastically* reduced overall complexity, including error handling and updating settings (for example, changing which serial port you're listening to- it's much simpler to just set it at the beginning, then relaunch if/when you need to change the port).
Hope that helps.
Allen Smith gave a presentation in which he discussed "ephemeral Actors" at NI Week in 2018 - the slides and video can be found on the Centre of Excellence website here: https://learn.ni.com/center-of-excellence/resources/1148/af-efficient-actor-framework-development-st...
Might be worth a look if you're wanting more details on what BertMcMahan mentioned regarding the lifetimes.
