Jump to content

Where to put settings modules in my DQMH program?

Recommended Posts

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.


Link to comment

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

Link to comment

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.


Link to comment

@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. 

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.

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.