Actor Framework Discussions
AF query
Solved!
@StevenHowell wrote:
I thought I was following the Single Responsibility Principle by having the DAQ actor just read the data from the instrument and then it hands off the raw data to the totalizer which has one responsibility, then the totalizer hands its data off to the averager which has one responsibility and so on.
You're close- IMHO, your actor has two responsibilities. First is the DAQ task, and second is launching the second actor. You could theoretically consider those to be part of the same task (i.e., "make a measurement") but I would argue it's best to break them up into more discrete, independent tasks (i.e., "make a measurement", "smooth the data", etc).
@StevenHowell wrote:
My confusion lies in this:
If the "controller" launches the DAQ, Averager, Totalizer, Datalogger, etc etc. wont the controller have to know the nested actors it launched queues to be able to send them messages? You would have to write the queue of each nested actor into the memory of the controller so that it can send messages "down the tree".
Each actor should only know the enqueuer of its caller and the enqueuers of any actors it launched directly.
If actor A launches B, and B launches C, then A shouldn't know about C.
If actor A launched B, then from A's point of view, B should do everything that A needs it to. Maybe B launches more actors to accomplish that- but it's irrelevant to A. Maybe B has dynamic dispatch versions that accomplish similar goals, but from A's point of view they're all interacting the same (Liskov Substitution Principle, IIRC).
In other words, A shouldn't need to send messages "down the tree", just to its individual branches. Perhaps B will forward that message on down the tree, but that's B's decision to make, not A's.
@StevenHowell wrote:
In my mind that makes the controller depend on all the other nested actors to be able to provide scaled averaged data. Am I missing something?
Yes- generally speaking, when an actor launches another actor, it will know what that actor is, and what messages it can receive. Thus, if Controller launches DAQ, Totaler, and Averager, it will need to retain those enqueuers so it can "do stuff" with them.
One other option is to create a "task specific" measurement actor that only handles the dispatching of other actors. A hypothetical scenario: say you're measuring a voltage, and you have two devices you need to use. One of them is a noisy, low-cost device that transmits data in separate bytes, needing "totaling" and averaging. The other is a fancy multimeter, whose data you can trust implicitly. You can build a HAL to have one override actor that launches DAQ, Totaler, and Averager, and another override actor that just reads the multimeter directly. Thus, Controller just handles the data you send it, rather than having to do a bunch of processing on the data.
In your case it might simplify it to have your business logic actor launch "Measure", which then launches DAQ, Totaler, and Averager. DAQ sends raw data to its caller (Measure), which sends it to Totaler, which sends processed data to its caller (Measure again), which sends processed data to Averager, which sends messages to its caller (yep, Measure again) who finally sends the averaged data upstream to "Controller" (aka Business logic).
One thing I'll note, clearly your code works fine as it is, and therefore it's not "wrong" to do it that way. It's just likely to not be particularly scalable, and since your DAQ actor can only ever send Totaled and Averaged data then you can't use it for non-Totaled or non-Averaged data. This may be fine in your case, but I'd recommend splitting it up because I believe it'll be easier to debug. Just my opinion though which is worth precisely what you paid for it 😉
That wouldn't be too bad to code yourself; you could add a map of [string-enqueuer] to the Actor's private data, then make a new Launch Nested Actor that would insert the nested actor into that map. That way you'd only have to add that code once.
Generally though I do like the hardcoded naming that the current system forces you to use. If I had to look up enqueuers with a String match, then there's a chance one of my methods might have a typo that wouldn't be noticed until runtime. This way, as long as I click the right element in "Unbundle" (or in an accessor) then I know I have the right enqueuer.
I tried to search and didn't find anything, but if you're doing that operation a lot I bet you could make a quickdrop plugin to automate some of that.
@StevenHowell wrote:
On a side note, this application is currently running on a Windows PC, but as soon as I finish another project I am working on, I plan to integrate this application into the other and both will be running on a cRIO.
Do you see any potential issues there, resource constraints, etc?
If you're talking about using the Zyah AF Forwarding Utility on a cRIO, you should be fine. I know at least one other person using this on the cRIO and after we got some path issues sorted out, it works fine.
If you're talking in general about the Forwarding Utility, I would just give a word of warning and say that though it might be tempting to use it to forward Msgs all around your system, most of the time there are good reasons not to do that. If you haven't already, read the blog and make sure you understand when and when not forwarding of Msgs might be most appropriate.
