LabVIEW
Actor Framework resources
I recommend you to check the following resources:
Actor Framework Documents - NI Community
Actor Framework - LabVIEW Wiki
The State of the Art for Actor Framework
Actor Framework Basics: Part 1 - the Basics | Moore Good Ideas - LabVIEW Consulting Services
If you have the option to attend the official training: Actor-Oriented Design in LabVIEW Course Overview - NI It was very helpful for me to attend this course.
I've been using AF for a while now and I really like it. The freebie training is OK, but you really have to just start using it to "get" it. If you can take a real course it'll help a ton.
A few things that I wish I'd understood better out of the gate that might help- apologies for a wall of text.
1- There isn't a ton of overhead, but don't use it if you're doing something simple.
2- One main drawback is that it makes your project MUCH harder to "follow" since all of the code is spread throughout multiple libraries. There is a decent amount of boilerplate code.
2b- Reducing coupling to low- or zero-coupling helps. Clear delineations of responsibilities helps keep things straight. Remember the Single Responsibility Principle.
3- Actors don't replace Objects and they don't replace Queues- they replace entire QMH's. Use an Actor when you need a standalone, asynchronous QMH. Synchronous tasks are doable with Actors, but you have to go out of your way to do it. Try to architect all Actors such that they work entirely asynchronously. If you need things to happen synchronously, consider using regular ol' Objects.
4- The MGI Panel Toolkit helps a TON with UI handling. I use this for 100% of my UI-based Actors.
5- One big benefit is that Actors are trivial to launch and close. If you don't need an Actor to be around, kill it and re-launch it when you need it again. Keeping an Actor idle is usually more work than making it ephemeral.
An example: I needed a DAQ Actor to read data continuously while an experiment ran. Prior to Actors, I'd make a separate QMH coupled to the main VI using a queue. This VI would get launched once at startup and would start or stop acquisition as needed. It would maintain internal states like Idle, Starting up, Acquiring, Error, etc.
With an Actor, handling "I want to start up, but need to return an error if I can't get the resource" was a pain. My main VI needed a state for "Initializing DAQ" where it waited until init was successful, synched states between the two... man, that was a pain. It hit me that it wasn't required.
Instead, I assume if the DAQ actor is running, it's acquiring data. It gets resources in Pre-launch Init, which will notify the caller immediately if it can't get the resource. It then begins acquiring data and sending it to the caller. When I'm done, I send Stop and kill the actor.
That eliminated ALL states from the DAQ actor and all DAQ-related init states in the caller. It turned out to be FAR less code to just stop and start the actor ephemerally. It was a new thought pattern but it's been really helpful.
I unfortunately don't have the time to carefully review your docs, but I can say this- do you need/want your MARK-10 interface to be asynchronous from your GUI? Does it need to handle stuff on its own, while your GUI/other workers "do stuff"? If so, yes, make it an Actor. If not, make it an Object.
Be careful with stuff like databases, too. While it certainly CAN be an Actor, it may not need to be. Usually, applications like this will write to a database, wait for it to complete, and move on. If that's your use case then it doesn't need to be an Actor, just a regular Object. If there are long delays and you don't want to wait for writes to complete, then sure throw an Actor at it (if you'd like... it doesn't have to be! Helper Loops within Actor Core are always a great option.)
If you need to, say, periodically read the database and make some decisions asynchronously from the rest of your code, then an Actor is a great way to do it.
Regarding one of your lines "each process could talk to each other, if needed"- be careful here. You really want to keep all communications "in the tree". So a given Actor should talk to who called it and anything it called, and that's it. If you find yourself needing to talk between two Actors, reconsider it as that way leads to madness race conditions.
So, if your need is "I want to read a value from a force sensor every so often" then I would recommend NOT making an Actor for this. If your system is an automated tester, where you send a command to "move down 3 inches and record force the whole time" then that could be an Actor, but consider that once you make something an Actor, you can no longer (easily) wait on it to complete. Your child Actor will tell Main what its status is, and Main will need to remember that and act appropriately. So, Main will need a state like "Waiting on move to complete", and you have to start maintaining a bunch of states of the instrument, and updating that state when the child notifies the parent.
Asking an Actor for information should not be done synchronously unless you have a very good reason to do so. Your program goes from "read the status of this Object" to "Send a message to request the current status of the child- I don't know when it comes back, but I need to remember that I asked, and that I haven't heard back yet." That's a decent amount of boilerplate code.
One thing to consider- instead of making an Actor that "runs the gage" that you instruct from another Actor, make the experiment the Actor. Interfacing to the gage can happen entirely inside that other Actor. Main sends it a request "Run experiment XYZ" and the experiment Actor then handles all synchronization using helper loops (queues, user events, whatever) and notifies Main when it's done with the experiment.
