This may have been asked before but I've not been able to find anything so far...
I'm starting to play with the Actor framework in LV2012 and have run into a dilemma. The system I'm setting up is a fairly common one consisting of test stand control, data acq, logging, control interface, and a "spectator" interface that displays live data for the user(s). To accomplish this, I have a top level actor that implements the control interface and logging which launches several nested actors that handle stand control and data acq across multiple front ends. While this works very well for data that comes purely from the measurement front ends, I'm having trouble cleanly integrating meta-data that is generated by the user.
Each message coming from an actor farther down the tree can be logged by the top level actor by maintaining the log file information in the class private data. However, any data generated on the UI of the Actor Core cannot be logged by using the class data in the Actor Core as there is no guarantee that the class data in the Core is the same as that in the message handler, correct? For instance, say my class data has a log file path and a group name for the TDMS write VI. If my user wants to add a note to that group, I could use the class data in the Actor Core to write the note as a property. No problem. But what if the active group is decided by a message coming from my front end? Then the group name in the parent actor core is different than the one in my Actor Core with the UI. The note would land in the wrong group. So far I have a couple ideas on how to make this work:
1.) Send relevant update messages from the Actor Core to the top level actor using self-to-self enqueuer so that the class data matches. This seems clumsy as it would require a lot of code duplication.
2.) Remove all actual functionality from the Actor Core. Any UI event would pass data via a message using the self-to-self enqueuer. This still seems clumsy, but at least would require less duplication (though the same amount of messages). It would require passing references to all feedback indicators into the class data.
3.) Consolidate all metadata generation in the Actor Core and create an additional actor which only logs data. Any message containing data for logging would be forwarded from the top level actor to the Logging actor. This would provide a consistent strategy for logging data produced by both the user and other actors, and therefore seems like the best idea.
Does anyone have thoughts on this one? I'm still pretty undecided as to how best to solve this little issue, and I'm sure others have encountered this before.
Thanks.
CLAD
