Where to put settings modules in my DQMH program?

[Nokaroa]

Hello all,

I'm copying this question from my post on the ni forums because this seems like a more appropriate place for it.

I am somewhat new to DQMH and for my first project I've decided to make my testbed software compatible with future projects so I am making it as modular as I can. Modules contained within include Camera, Stage (which is a cloneable abstraction layer for a Zaber stage. Cloneable as to allow multiple axes in the future), Test, and a Model module. Eventually once I make the UI I'll have a whole MVC architecture going on and I'll make that good and nice. Camera, Stage, and Test each have their own settings which are required, and I have made a Camera Settings and a Stage Settings (cloneable) module as well (haven't gotten to test yet). These are required for reading the ini files containing the VISA sessions, baud rates, microstep sizes, IMAQdx settings, etc.

 

Without the data from the ini files, there's really nothing for the hardware modules to use, so I would like to have the gathering of settings information in the init message case. From what I can see, I have two options as to how to lay out the program. My initial thought is to have the modules for settings launched by each individual hardware module.

 

 or I can have settings be given to the hardware modules by main. This avoids having a bunch of layers, and sticks with the philosophy of having everything sent through the controlling module.

I'm really not sure what the smart way to do this is. Especially with the cloneable stage module where each clone will need to be given a single clone of the settings module. 

 

Additionally, I'm not sure how much work the init message should be doing in terms of loading these ini files. Good design philosophy tells me that it makes the module more atomic to have a separate config case, but realistically, there should be no reason for a stage module to change which hardware stage it's connected to, so I don't really want to include a configuration in the API when it can all be done at module startup.

 

[drjdpowell]

Why are you making Setting modules at all, rather than just having the other modules just read the INI file directly?   This seems very over complicated.

[Nokaroa]

I'm following the example from the DQMH Sample CML template where the settings was an external module. It seems like a nice approach in the sense that it's a standalone front panel allowing the users to click a "settings" button and modify settings that will need to be saved to file. But if that's not a standard approach, I definitely don't need to have it

[Antoine Chalons]

It can make sense to have a dedicated module for settings.

We have a single Toml file for our app, lots of dqmh modules pretty independent from each other.

Each one has a section, if the file is modified, the 'settings module' will detect it and send a 'config changed' broadcast with the list of modified sections, then each module will act only if relevant section is in the list.

So we can simply edit the file and modifications - if valid - will be applied.

 

[Nokaroa]

@Antoine Chalons Makes sense. Is your settings module constantly scanning for file changes? How does that work? 

Since asking the question, I've eliminated the independent settings modules. I still have a "settings.ini" config file plus individual settings files for the various modules that need different ini files. 

[Antoine Chalons]

the app does not constantly scan the file for changes, we ruled it out quite early.

the app can receive request & commands via tcp, one of the command is 'reload config file'