Actor Framework Discussions
Integrating AF & LVOOP with hardware
Solved!
@WavePacket wrote:
Such long quotes now, but this conversation has been a marathon (in a good way).
Just curious -- in your example, why is Assembler class a "LabVIEW class?" Is there a reason that it couldn't be a state of a state machine, or an override of pre launch init of a root actor (just to name two examples for no particular reason)? This "Assembler code" isn't meant to be reusable, so I'd flop forward mostly from a position of ignorance that it doesn't necessarily need to be a class.
It doesn't have to be a class per se, but it should be separate from the rest of the stuff. Even though the Assembler code isn't reusable, the stuff it assembles IS reusable. Thus your "Main actor" would become reusable (if that's a benefit to you).
@cbutcher wrote:
I have been in the past (but have yet to really follow through to completion, so take with a mountain of salt) tempted to do the following (I think that LabVIEW's Options panel is perhaps similar either in principle or both principle and execution):
- Create a "Configuration Panel", which contains a ListBox and a Subpanel (or similar)
- Have each configurable thing send a message (possibly AF Message if the Config Panel is an Actor) with its name, and a VI reference
- Have the Panel (in the Do.vi called subVI, or equivalent) add the name to the listbox, and add the reference to a Map
- If you click on the name in the Listbox, look up the name in the Map and get the VI Reference, then insert in the subpanel (optionally, make this a class or something rather than a VI reference, and provide "Insert into Subpanel" and "Remove from Subpanel", perhaps also "Resize" or similar to allow more complicated behaviour defined by the configurable thing
- Use the contents of the VI (provided by the configurable thing) to control the settings of said thing. This is a bit more tricky, since you need a way to update the running "thing" according to new settings. Having the VI know an Actor Enqueuer (or similar message system, Queue, Channel, etc) is one way, send the new settings to the Enqueuer and have the thing (now an Actor) update itself.
That's basically what I've been thinking, with the exception of needing additional "selector" intermediate classes. For the classic "DAQ card or multimeter for measuring voltage" example- I'd imagine you'd want "Voltage input" as your column entry, then once you click that you can pick "DAQ card" or "Multimeter", then once you pick THAT you get the child-provided settings menu.
That's why I was picturing the whole thing as being somewhat recursive; after you click an option to the left, a sub-selector could come up. I don't think I'd want a whole dedicated "DAQ or Multimeter Selector" class to populate a submenu, as "select between these few options" is such a common need that I'd want to make that code reusable.
The CEF has some such functionality:
where you can right click on individual headings and add one or more sub-items. I bet you could make a reusable "Group" that just has a Ring control that gets populated at run-time with the available choices, but again building all of that up sounds like a lot of work, and I haven't ever had the time nor budget to make it happen.
@WavePacket wrote:
@Dmitry wrote:
Option 2: Assembler class is tasked with loading all configuration data...
Just curious -- in your example, why is Assembler class a "LabVIEW class?" Is there a reason that it couldn't be a state of a state machine, or an override of pre launch init of a root actor (just to name two examples for no particular reason)?
No, it does not have to be a 'class', but I find that packaging its functionality as a LabVIEW Class makes a lot of sense :
- It creates & configures all application actors/objects and needs a place to keep data structures used for application tear-down - which becomes Assembler class private data
- There are only 5 public methods - executed one after another (see diagram below). Init and BringUp methods typically create lots of RefNums - which are guaranteed to stay in memory for Assembler object lifespan. The latter is the same as the application lifespan - so no more refnums getting invalid because a top level VI that created them stopped executing
- I have a reuse code library with an Assembler class implementing common functionality that may be reused by many applications. So creating a Child Assembler Class for a specific application is a natural way to go
@BertMcMahan wrote:
Ah, so you're saying you have one Assembler class that creates the Main Actor, populating its sub-classes with XY Stage and Scanner. Thus, the Assembler class doesn't do a whole lot of things, but it decouples all of the other things. Basically it just runs once, right?
Correct. It does not do much and runs only once. But when it stops - all objects are properly destroyed, resources released and updates to configuration saved to persistent data storage (INI files/Database /you name it):
Above is part of the Application Main VI - which also serves as a splash screen for the app. Main Actor is started inside the Assembler.Run method. After Main Actor stops - application proceeds to the TearDown step and then closes/destroys all application-wide subsystems in Done (message broker, global log, etc.)
@BertMcMahan wrote:
For lots of my programs, "have the user edit a JSON file" won't work- they'd need a GUI, which itself would be called within the Main Actor. The GUI could then update all of the config settings and pass a Config object to the Main actor, who can implement methods to adjust config on the fly rather than having to be fully restarted. This is a method I've used in the past, but I don't love it since the GUI tends to be unweildy, having to know ALL settings for ALL of my different options.
I've used the Assembler class for implementing three different configuration-handling scenarios:
- Application configuration does not need to be viewed/updated while application is running (your 'user edit a JSON file' case). Not a common one and the easiest to implement: Assembler object loads configuration, and configures/injects all objects. Nothing to save on application shutdown - so your main actor can choose to call destructors (Done methods) for all its subsystems since Done is, normally, a dynamic dispatch method.
- Application configuration needs to be viewed/updated while application is running, but it is OK to save all updates on application shutdown. This covers ~80% of applications I've developed so far. Requires more work as :
- I need to program a GUI method for each concrete class supporting configuration update
- Main actor needs to return its subsystem objects back to Assembler TearDown method. The latter gets a subsystem configuration cluster via accessor method, destroys subsystem object and saves all updates to persistent configuration storage. If you choose to do that in the main actor - it gets statically coupled to subsystem classes via subsystem configuration typedefs, compromising its reusability
- Application configuration updates need to be saved/reloaded while the application is running. This is a hard requirement for applications running 24/7. It is also the most expensive to implement without statically coupling your main actor to all its subsystems. I do this by creating a separate Configuration Handling Class. Might be an actor or a 'normal' object. Configuration Handler code is application-specific, but one can 'recycle' Configuration Handlers from another project to save on development effort. I think that Configuration Handler details are beyond the scope of this thread, but you can read about the design pattern and get example sample code (LV2015) here.
