I thought I was going crazy because both my printer.cfg and macro.cfg “lost” the changes that I had made and were working well for several weeks. It happened again today. macro.cfg has a change date of 10/29/2024 when I am positive that I updated it manually on 01/25/25. I’ll take a stab at what may be happening but I would love confirmation or the correct explanation!
I got in too deep with changes to the printer configuration in OrcaSlicer and decided to start over from a different user’s config files. I didn’t like that either so I started over with a different user’s configs. Is it possible that switching the printer profile (or creating a new one) resets the printer and macro config files? The other possibility that I can think of is that a backup script has gone rogue and is restoring the default configuration at random.
No, I for sure didn’t do a reset but I guess I’m just crazy after all. I compared the current macro.cfg that has a change date of 10/29/2024 to a backup from 01/24/25 and they are exactly the same. I am using WinSCP to access the file so I guess there’s something wacky with the change bits and it is picking up the created on date instead of changed on. There are definitely changes between the current printer.cfg and 2 different backup versions, with the current one being closest to default, so I guess there’s something going on there. Maybe this is the printer’s way of telling me to go to mainline Klipper.
A possibility may be that you turned off the machine too quickly after editing. The OS doesn’t usually get shut down correctly, but Sovol executes a periodic “sync” to write anything not stored to flash yet back.
Hard to say because I don’t quite understand how changes which have been applied on jan25 could have been running allright for several weeks.
To be on the safe side, you may, after modifying the configuration, execute a manual shutdown, rather than simply switching off power:
execute, as root: halt
Anything not yet written should, after that, have found its way into flash storage.
The changes I made on the 25th were very small, the bigger ones came several weeks ago so that’s why I noticed that something wasn’t right in the configuration. I think you’ve diagnosed the problem because I did have to do an emergency stop (filament was wrapped around the nozzle and when it tried to go home the gantry started dancing). Thanks for the ‘halt’ tip!
Comparing the two files you can do on the printer, after logging in using secure shell: There is a utility called “diff” installed, and you could call it like this:
diff -u file1 file2
where file1 and file2 are path and file name of the two files you want to compare.
you are not going crazy. there is some code in the Sovol klipper that will write certain “defaults” back to the printer.cfg.
I installed CoPrint a couple of weeks ago, and whatever monitor code is running will overwrite the USB ID for the MCU. It must be coded to use the first mcu it can communicate with… which in my case ends up being the KCM instead of the SV08 MCU. I have a commented line in my printer.cfg with the USB ID for my SV08 MCU and every few days when I power on the printer I will have to edit my printer.cfg back to the correct setting. This solution was suggested to me by CoPrint support, as their in-house SV08 does the same thing.
As the file system on which directories under /home reside is ext4, extended attributes are available. This not widely known feature allows you, among other, to set a file immutable. That’s sort of a write protection on steroids. When doing so, nothing will be able to overwrite, modify, erase, move/erase the file, regardless of privileges (that is, also super user can’t). Only after that immutable flag has been reset again, will it be possible to modify the such protected file again.
Setting and resetting that immutable flag is simple:
chattr +i file (set, i.e. protect file)
chattr -i file (reset, allow normal writes again)
file in your case would probably be /home/sovol/printer_data/config/printer.cfg. Only superuser can set and reset this flag. That is, after logging in (using secure shell), you’d want to become root by executing sudo sh before you can chattr.
To show the extended flags, use lsattr.