Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Load App - Pre-Launch Actor Activities

I am developing my first full blown AF application with several actors to control both UI and intrumentation drivers. One of the things I am considering is using a Configuration class to store information about the machine. My question is where is the most appropriate place to execute the configuration reader?

I typically - pre-AF days - would have an initialization case in the main app UI which would execute an ini file reader before the rest of the application started. To me, it seems to make sense to place this ini reader in the Load App.vi and wire the configuration class into the Controller private data before Launching the actor. Is this good practice?

The basic structure of the application is as follows:

SystemDiagram.png

There are several DI/DO points that are addressed so this is a very simplified diagram. In other languages, for example, the DIs are handled as one task and there are "helper" classes which reference the input by index or bit mask of the line data. This method is where I plan to go as well and I think that the AF is a good fit for this.

Thanks for the input.


Drew

0 Kudos
Message 1 of 7
(7,346 Views)

I have a configuration class that I can add to the class attributes of another class.  I had an issue where I needed some of the information from the config file before actor core, so I ended up reading the config from file in Pre-Launch Init.vi.  Make sure that if you do this you are aware that if there is an error that Handle Error.vi will not execute.  Handle Last Ack.vi of the actor that launched the actor that failed will get called.  That is where you will need to handle any problems with launching the actor.

If you want the actor itself to deal with an error in reading the config then you will need to make that read a method for the actor (or something up the hierarchy) and use Handle Error.vi in case of problems.

There is a good article on Pre-Launch Init and other actor vis and what to put in them that has been referenced in several threads.

Good luck.

Casey

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

0 Kudos
Message 2 of 7
(3,639 Views)

My question is maybe beyond the scope of this discussion. But anyway: What happens if two or more actors want to read config data from INI file at the same moment?

Regards, Ljubo.

0 Kudos
Message 3 of 7
(3,639 Views)

That depends on the API your are using but if this is the LabVIEW Configuration File VI's they read and parse the contens of the INI file when you open it. This is loaded in a single element queue trough which you access the keys.

Karsten

0 Kudos
Message 4 of 7
(3,639 Views)

Right. In this instance, I am loading the ini file data into the private data of a configuration class which is owned by the controller which will send the information to each driver/sub-system as that system is being initialized. That way only one process can access the file and it manages who gets the data.

Drew

0 Kudos
Message 5 of 7
(3,639 Views)

Ljubo wrote:

My question is maybe beyond the scope of this discussion. But anyway: What happens if two or more actors want to read config data from INI file at the same moment?

Regards, Ljubo.

As long as both actors are reading a totally disjoint set of keys, there's no problem with this. I recommend using the section headings feature of config files where the section headings are the names of your actor classes (or something similarly guaranteed to be unique) to guarantee that your token names don't collide. The two actors will simply serialize their reading of the file.

0 Kudos
Message 6 of 7
(3,639 Views)

AristosQueue wrote:

As long as both actors are reading a totally disjoint set of keys, there's no problem with this.

To clarify: When two actors are trying to read and write the same key, then the config file often becomes a backdoor communications channel between the two actors. If it is a setting that can only be set at launch and never changed after startup, then having multiple actors read the config file directly is fine and saves you some communications cost. But if it is a setting that can change while the app is running, you're better off designing one actor to read the setting and then disemniate it out to the others who need it. That way it is clear who is in charge of the setting.

0 Kudos
Message 7 of 7
(3,639 Views)