Jump to content

Recommended Posts

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


Link to comment

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!

Link to comment

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 by ShaunR
Link to comment

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.

Link to comment

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. :P

Link to comment

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.  

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.