Best way to maintain automatic configuration of QtPlasmaC?

Hi all. I'm in the process of implementing a fiber laser system using LinuxCNC/QtPlasmaC. In the past I've done other machine controller conversions for mills, lathes, routers, etc. In those cases I try to keep the configuration in a state where I can use pncconf to still make changes to the machine. In some cases this has required me to make entries in custom.hal or a shell script using text manipulation tools like "sed" to fix up or customize pncconf-generated configurations.

QtPlasmaC seems amazing so far, and I was greatly encouraged by the change in configuration style in the change from PlasmaC to QtPlasmaC that makes it much more feasible to keep using pncconf to make configuration changes indefinitely.

However, as I get into fine-tuning my configuration I am running into some challenges automating the complete configuration of my machine after generating the configuration with pncconf. Some simple things are easy enough to fix with sed, but for instance I want to enable ohmic probing by default in the configuration. It seems like the configuration entries for this (and even the category for the configuration entries) do not exist in the .prefs file until the configuration is started for the first time. I could write a script to fix this, but it would be fairly convoluted. Right now there are probably half a configuration changes I'd like to automate. There might be hal pins for some of that, but it seems counter-intuitive and probably non-obvious to someone trying to debug a problem to have a configuration file entry that is overridden by a hal entry.

Any suggestions on how to automate the creation of a consistent machine configuration following pncconf (re)generating the config?

Thanks!

Scott

On the first startup of QtPlasmac it will only write .prefs file variables that do not exist, so if you add any variables prior to the first startup it will not overwrite the value of that variable.

There might be hal pins for some of that, but it seems counter-intuitive and probably non-obvious to someone trying to debug a problem to have a configuration file entry that is overridden by a hal entry

I am not quite sure what you mean.
 

Thanks! With respect to using the hal pins versus config file for configuration, I might not be understanding the possibilities correctly. It seems like the best way would be to have the ohmic probe enabled on startup is to set the following in the prefs file

or I was thinking in theory I could set a value in something like a custom.hal to

but to be clear I think that would be a fairly bad idea because in general people would be expecting the value to be set in the prefs file. Hopefully that clarifies what I was getting at.

I'll plan to try and automate adding the missing configuration sections and values via shell script. The main complication with doing so is that I like to keep my config fixup files "idempotent" so that I can run them multiple times without breaking things, and that means I'm pushing bash text manipulation a bit far. So python might be a better choice. If you've got any advice on that front please let me know.

Thanks!

Scott

I ended up getting this working by using the same code for managing prefs file values that is used in QtPlasmaC, but extracted to a simple script that can be run right after pncconf generation. Here's a starting point that I'll be adding values to as needed in case anyone else wants to do the same thing:

Then on the Debian Buster LinuxCNC image at least you can just run it via "python3 <script>"

As Phillip mentioned, other (default) values are filled in on the first start.