Actor Framework settings dialog

[chrisempson]

Hi, I'm writing a LabVIEW application using the Actor Framework. This is the first time that I have used the framework and I need some advice regarding application architecture. My apologies if this is a basic question!

 

How is a settings dialog box best implemented? In the past in non-Actor Framework applications I have loaded the configuration from a functional global variable, displayed the settings dialog, then written the updated settings back to the functional global. I'm not sure this would work correctly (or optimally) within the context of the Actor Framework, though. 

 

My application uses the template generated by Create Project -> Actor Framework. The top-level Actor manages the user interface. Two child Actors control separate pieces of hardware. The top-level actor must read a saved configuration from an INI file when the application starts, and save the final configuration back to the INI file on exit.

 

Instinctively I think it would be best for each child actor to maintain its own settings, as a cluster in its class private data. Ideally I don't want to have to keep a separate instance of the two clusters of settings in the top-level Actor's private data in order to populate a settings dialog; this duplication seems unnecessary.

 

The only way I can think of to make this work is as follows.

 

At application start

1. Top-level Actor reads settings from INI file.

2. Send messages to both child actors with the new settings, and tell them to apply those settings to their private data.

3. Each child Actor should respond to acknowledge that the private data has been updated.

 

To update the settings using a dialog box

1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

2. Wait for both child Actors to reply.

3. Display the dialog box.

4. If the user clicked 'Ok' and not 'Cancel', send messages to both actors with the new settings, and tell them to apply those settings to their private data.

5. Each child Actor should respond to acknowledge that the private data has been updated.

 

On exit

1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

2. Wait for both child Actors to reply.

3. The top-level Actor writes the settings to the INI file.

 

This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do. I wouldn't know where in the block diagram to implement this scheme, either.

 

Can anyone offer me any advice? There must be a fairly standard way of doing this that I'm missing!

 

Thanks in advance,

Chris

 

---

Dr. Chris Empson

Robot Screening and Instrumentation Specialist

School of Chemistry

University of Leeds

UK

 

CLD

[hooovahh]

I don't use the Actor Framework, but do use an actor design (multiple parallel loops that are asynchronous and have dedicated tasks with messaging between).  The design you describe sounds like it would work but here is a design I use.

 

There is a configuration actor (module) that handles all the File I/O parts.  It has a window just like LabVIEW's Tools >> Options dialog, where there is a listbox of settings, and a subpanel that a VI gets loaded into.  The control values are what are saved and loaded into a single INI file.  Each page in the config is a separate section in the INI.  The page VIs are running, but they don't have to be, they can literally be just a set of controls but some times you want feedback so they run, and listen for the global quit message all actors get and stop if they see it.  I also setup a slow polling so if the reference is invalid they pages stop too.  This way hitting CTRL+. will stop them too, even though they are also asynchronous.

 

On startup of the program, before any actors are started, a VI is called that loads the INI file and puts all the application settings into a global.  Where they can be read but not written.  Each actor during its init will read from the global the settings they want.  Then when the user opens the config actor, makes a change, and then presses OK or Apply, the control values are all read, then re-written to the INI, and re-written to the global.  Then a single message goes out to all actors telling them there are new settings that were applied.  This is a 1-to-N message where there is no waiting on responses.  In this message is data telling each actor which pages of the config were changed.  This way each actor can look at the pages and determine if the data changed, is applicable to them.  If I changed a COM port for a power supply, then the power supply actor now needs to cleanup and re-init with the new settings, but the DMM actor doesn't need to do anything.

 

So in my setup one actor handles all File I/O, with the only exception is a single VI that is called before all actors start which does the initial read.  Config is done in pages, which are just a collection of VIs and controls.  This makes adding new settings easy, just add a new control, then read from the global which is a variant.  This way when I add a new setting there is no type defs or controls that need updating, and no new code to write, just add the control to the page VIs, and now that setting is in the INI and global for the rest of the application to read.  There is a chance for some runtime errors because of this, but these types of errors you see once in development, then make it the correct type, and never see again.  You aren't changing the type of the data mid application.  If I have a string data type that is Project Name, I'm not going to change that from a string, so once all the places that I'm reading Project Name are set to string you won't really see any errors again.

 

In your design you mentioned each actor being responsible for their own settings, but I have a few settings that aren't specific to one actor.  Under the Advanced page of my config I have a hardware simulation mode.  If this is on each actor knows to pretend it is talking to hardware and return random, or semi-random data.  I may also have multiple pages for each actor.  I have a sequence engine, and it may have multiple sequences that could be in multiple pages, or a single page with a drop down of which sequence to edit.  My point is I can have as many settings or as few, which can be shared between actors.

 

A downside of this design comes when you want to just run a single actor without having to run the configuration actor.  I realize my design adds some coupling that is generally not desired.  So I had some extra code to detect if the configuration actor isn't running, and to use predefined defaults for that actor, if it's not.

[chrisempson]

Thanks so much for your detailed reply, hooovahh. Your architecture makes a lot of sense, and removes the problem of having to wait for replies to messages. Doing a 1 to N message cast is a much better scheme in a distributed, asynchronous system.

 

Your point about configuration data that is shared between Actors is a good one. I was planning on adding a hardware simulation option that all of the Actors would need to know about.

 

I take your point about this architecture adding some undesired coupling, but that isn't a significant problem to me.

 

Thanks again!

[ShaunR]

So in my setup one actor handles all File I/O, with the only exception is a single VI that is called before all actors start which does the initial read.  Config is done in pages, which are just a collection of VIs and controls.  This makes adding new settings easy, just add a new control, then read from the global which is a variant.  This way when I add a new setting there is no type defs or controls that need updating, and no new code to write, just add the control to the page VIs, and now that setting is in the INI and global for the rest of the application to read.  There is a chance for some runtime errors because of this, but these types of errors you see once in development, then make it the correct type, and never see again.  You aren't changing the type of the data mid application.  If I have a string data type that is Project Name, I'm not going to change that from a string, so once all the places that I'm reading Project Name are set to string you won't really see any errors again.

 

In your design you mentioned each actor being responsible for their own settings, but I have a few settings that aren't specific to one actor.  Under the Advanced page of my config I have a hardware simulation mode.  If this is on each actor knows to pretend it is talking to hardware and return random, or semi-random data.  I may also have multiple pages for each actor.  I have a sequence engine, and it may have multiple sequences that could be in multiple pages, or a single page with a drop down of which sequence to edit.  My point is I can have as many settings or as few, which can be shared between actors.

 

A downside of this design comes when you want to just run a single actor without having to run the configuration actor.  I realize my design adds some coupling that is generally not desired.  So I had some extra code to detect if the configuration actor isn't running, and to use predefined defaults for that actor, if it's not.

 

I think if you move to a DB, it will supply the decoupling and still give you all the same capabilities.

 

A while ago I added a "Settings" library to the SQLite API which, I think, does exactly what you're describing - almost direct replacement. You just place the VI on the diagram and you can load and save the FP controls to the DB. It also gives you "Restore to Default" and has a "query" function so you can return as many or as few parameters as you like (see the Panel Settings Example). I was also thinking about adding the "Update" event broadcast similar to your system since for Data-aware xcontrols it would be a very nice feature to have them all update on a change and would only be a couple of minutes to add.

Edited April 11, 2016 by ShaunR

[hooovahh]

Yeah I thought about a database, and did look into using your SQLite library, but honestly it works, it's human readable, and I haven't had any real problems so I didn't see much of a need to change it yet.  I was using the OpenG INI stuff and with very large data structures it was a bit slow so I moved to MGI at some point and haven't had any issues since.

 

I think the coupling between actors would still be there even if I went to a database.  The coupling I was referring to could be minimized with several techniques, but the actual format of the file isn't going to change this, other design decisions could.  Like if each actor was responsible for doing their own configuration control, but as I said my design didn't go this way, not that this could work.

 

Oh and my setup did have a cancel option, which just wouldn't send out the 1-to-N message that a setting was changed, and it would re-read the config file, and re-write the controls in the pages.  One other thing I forgot to mention is some times pages of the config, would rely on other pages of the config.  So say I had a page that had a Show Advanced Settings checkbox.  If this was on you wanted all the other pages to show the advanced settings if there were any.  So when I sent out this 1-to-N message to the actors telling them a config was updated, I would also have that message go to each of the pages, so that they could then re-read from the global the settings from all the other pages, so they could show or hide the advanced settings based on the last applied settings.  I used this same message to the pages if you canceled too, because a cancel may revert to some state where the UI in the page needs to be updated.  I've thought about cleaning this up and posting it, but since it isn't an NI Actor, it uses a decent amount of the reuse library which would need to be made generic or released.

[ShaunR]

Yeah I thought about a database, and did look into using your SQLite library, but honestly it works, it's human readable, and I haven't had any real problems so I didn't see much of a need to change it yet.  I was using the OpenG INI stuff and with very large data structures it was a bit slow so I moved to MGI at some point and haven't had any issues since.

 

I think the coupling between actors would still be there even if I went to a database.  The coupling I was referring to could be minimized with several techniques, but the actual format of the file isn't going to change this, other design decisions could.  Like if each actor was responsible for doing their own configuration control, but as I said my design didn't go this way, not that this could work.

 

Oh and my setup did have a cancel option, which just wouldn't send out the 1-to-N message that a setting was changed, and it would re-read the config file, and re-write the controls in the pages.  One other thing I forgot to mention is some times pages of the config, would rely on other pages of the config.  So say I had a page that had a Show Advanced Settings checkbox.  If this was on you wanted all the other pages to show the advanced settings if there were any.  So when I sent out this 1-to-N message to the actors telling them a config was updated, I would also have that message go to each of the pages, so that they could then re-read from the global the settings from all the other pages, so they could show or hide the advanced settings based on the last applied settings.  I used this same message to the pages if you canceled too, because a cancel may revert to some state where the UI in the page needs to be updated.  I've thought about cleaning this up and posting it, but since it isn't an NI Actor, it uses a decent amount of the reuse library which would need to be made generic or released.

 

Yes. the "advanced" or dependent configuration is not easily catered for by just blindly loading and saving FP controls.It would be a mistake to try and add logic to a generic API to cater for application specific dependencies.

 

I chose to have the basic load/save behaviour which is fine 8 times out of 10 and then use a query to update specific controls so it is a two step update for corner cases. It is very simple but does require a little bit of thought about naming your controls. The current query function only interrogates label names as a partial match so adding "Avanced_" to a control, for example, means you can achieve that behaviour. A slightly more complicated query would be nice across dialogues and in my personal version the default query string can be overriden but since I never get any feedback as to features people want or bug reports to drive another release; I haven't implemented it as yet.

[drjdpowell]

In case the OP wasn’t aware, there is an Actor Framework group on NI where there are more AF users who might respond.

 

 

This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do.

 

 

Waiting on things that are reliably quick is often the best thing to do, IMO, as it is often simpler.