Actor Framework Discussions

Showing results for 
Search instead for 
Did you mean: 

AF: Simple (Serial) Communication Example

Go to solution

Hi all,


I am trying to get my head into AF, but I am struggling to transfer my current application into AF. I am basically trying to build a simple logger, that can connect/disconnect to a COM Port, send and read data, display the log on the front panel and write it into a file.

In principle its the same functions as in the "Continuous Measurement and Logging" sample project, but in AF.


My main problem is the serial communication, where I don't know what would be best practice. I would do a actor with a QMH in it?


Does anyone have a similar program and likes to create example project from it?


Best regards and many thanks



0 Kudos
Message 1 of 6

@LabviewBow wrote:



My main problem is the serial communication, where I don't know what would be best practice. I would do a actor with a QMH in it?




Hi Jochen,

can you elaborate a bit on this. Just to avoid misunderstandings

An Actor is in fact something QMH. 


Best Regards


Programming languages don't create bad code, programmers create bad code....
Message 2 of 6
Accepted by topic author LabviewBow

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.

Message 3 of 6

Thank you both for the answer. Somehow it helped me to fix the missing link in my understanding!

0 Kudos
Message 4 of 6

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, 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.

0 Kudos
Message 5 of 6

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:


Might be worth a look if you're wanting more details on what BertMcMahan mentioned regarding the lifetimes.

Message 6 of 6