JKI State Machine Objects
JKI SMO vs Actor Framework
Choosing a framework depends a lot on the problem you are trying to solve. The answer is likely to be in shades of grey. Personally, I use AF for some projects but I was very involved in the development of SMO because I wanted to get around some of the complexities of designing a large application that comes from using AF. Today, I would recommend anyone to give SMO a spin to solve the same kind of problems one solves with AF... but I am totally biased 🙂
If you just want to find an easy way to spawn asynchronous processes, send commands to these processes and/or be notified when their state changes, JKI SMO has a much easier learning curve than Actor Framework. If you are looking for a solution that is supported by NI and you already have a good experience with OOP, then AF might be a good choice for you.
Whichever framework you choose, your processes will receive instructions (messages) and consume them in the order that they are enqueued. JKI-SMO uses events for communication with the process whereas AF uses queues.
Unless you plan on doing actor substitution (for unit testing or creating message redirections in a networked architecture or for creating a message abstraction layer), I would choose SMO for this type of tasks.
I'm not sure what you mean by "two state machines that switch". If you mean that each state machine can change state independently, then yes, those are two actors. If you mean that you have two states and you want a different execution sequence for each states (e.g. "Idle" and "Running"), then you only have a single actor composed of two states, each of which is a different sequence of atomic tasks (state machine).
I hope the terminology is not too confusing. As a matter of fact, the "JKI State Machine" is a type of "Queued Message Handler" (QMH for short), not a strict state machine in the widely accepted sense of it. You can make a state machine out of a QMH (if you never enqueue states in between already queued states, which can change the behavior of subsequent state, and therefore would not qualify for being called a "state machine" anymore).
Just to dissipate any confusion about State Machine Objects and Actors:
SMO is a classic "JKI State Machine" running as an actor (with which you communicate via messages). If you have two actors, you would launch two SMOs, each with its own state machine running in the "Process.vi" method.
Actor Framework and SMO are both "actor-model" architecture, although different implementations of that model. Both frameworks have initialization methods, an asynchronous process, a shutdown procedure and a way to launch sub-actors. With Actor Framework, you would have your state machine as an override of "Actor.vi", whereas in SMO you would have your state machine be an override of "Process.vi".
You've put your finger directly where it hurts 😉
AF is well documented and supported by NI. You can call them on your SSP and you will get support from their application engineers. There are multiple tutorials and even a class you can take.
SMO is not fully documented. There is a very succinct intro here. There is also an Editor that helps with getting started, but that's the extend of it at this point in time. You can install the editor from VI Package Manager.
Of course, SMO is much simpler than AF for beginners (which is not an excuse for lack of basic tutorials), but you can leverage a lot from the documentation on the JKI State Machine (not Objects) as the core is the same.
I agree!
I actually wanted to wait for the next iteration on the SMO Editor to do that. I know that Jim made significant improvements to the speed of the Editor a few months ago, but there are simple workflows with events that are not to my liking. Once that exists, I totally agree that a few YouTube tutorials are much better than standard doc. (I recognize that it is one of those "let's-not-let-perfect-be-the-enemy-of-getting-it-done" kind of situation.)
