Klipper doesn't auto write the config after Save_config...

[Pradit]

Whenever I test something like Z_endstop_calibrate or anything which after the end it mentioned to save_config.

And we can expect the auto config in our printer.cfg at the bottom.

However, this stop happen to me.

I got the PID auto config but that's it. 

After I did 1st PID and it never write anything for me again.

Anything to do with my klipper_firmware_dirty?

Please help thanks.

 

[smirk]

A question might be do you see any errors after issuing a "SAVE_CONFIG" command, either in the console screen (you're using Octopi, so not 100% sure what that will show) or  in the klipper log file ~/klipper_logs/klippy.log ?

When you do a "SAVE_CONFIG" there will be a line in the klippy.log file that looks like:

SAVE_CONFIG to '/home/pi/klipper_config/printer.cfg' (backup in '/home/pi/klipper_config/printer-20221224_213245.cfg')

That's an example from a working command, after that line there is a bunch of stuff about restarting klipper and it writes out a copy of the new config file into the log file.

If there was some horrible reason why the SAVE_CONFIG command was not actually saving the config I would expect to see it in the log. For example,I have deliberately changed the ownership of my config files to prevent the SAVE_CONFIG file from working. Along with an error in the console window, I also got the following error in the klippy.log file:

SAVE_CONFIG to '/home/pi/klipper_config/printer.cfg' (backup in '/home/pi/klipper_config/printer-20221224_213717.cfg')
Unable to write config file during SAVE_CONFIG
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/configfile.py", line 409, in cmd_SAVE_CONFIG
    f = open(temp_name, 'w')
IOError: [Errno 13] Permission denied: '/home/pi/klipper_config/printer_autosave.cfg'
Unable to write config file during SAVE_CONFIG

Now, this is just an example, but I would start by looking in the log file for clues.

If you log into your PI and then use the "tail" command with the "-f" parameter it will just list (or follow) the contents of the log file onto the screen (i.e. tail -f ~/klipper_logs/klippy.log ). For example:

pi@spiderpi:~ $ tail -f ~/klipper_logs/klippy.log
webhooks: registering remote method 'reboot_machine' for connection id: 1971065480
webhooks: registering remote method 'pause_job_queue' for connection id: 1971065480
webhooks: registering remote method 'start_job_queue' for connection id: 1971065480

You can then issue your "SAVE_CONFIG" command from the console window (in OctoPi) and see instantly what's getting written to the log file. To get out of the tail command just press Control+C

 

 

 

[smirk]

5 hours ago, Pradit said:

Anything to do with my klipper_firmware_dirty?

Sorry should have added, I doubt it will be the klipper firmware (or klipper software running the PI), writing a file is pretty basic OS level functionality. Most common issues are things like file permissions and the like.

[Pradit]

18 hours ago, smirk said:

A question might be do you see any errors after issuing a "SAVE_CONFIG" command, either in the console screen (you're using Octopi, so not 100% sure what that will show) or  in the klipper log file ~/klipper_logs/klippy.log ?

When you do a "SAVE_CONFIG" there will be a line in the klippy.log file that looks like:

SAVE_CONFIG to '/home/pi/klipper_config/printer.cfg' (backup in '/home/pi/klipper_config/printer-20221224_213245.cfg')

That's an example from a working command, after that line there is a bunch of stuff about restarting klipper and it writes out a copy of the new config file into the log file.

If there was some horrible reason why the SAVE_CONFIG command was not actually saving the config I would expect to see it in the log. For example,I have deliberately changed the ownership of my config files to prevent the SAVE_CONFIG file from working. Along with an error in the console window, I also got the following error in the klippy.log file:

SAVE_CONFIG to '/home/pi/klipper_config/printer.cfg' (backup in '/home/pi/klipper_config/printer-20221224_213717.cfg')
Unable to write config file during SAVE_CONFIG
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/configfile.py", line 409, in cmd_SAVE_CONFIG
    f = open(temp_name, 'w')
IOError: [Errno 13] Permission denied: '/home/pi/klipper_config/printer_autosave.cfg'
Unable to write config file during SAVE_CONFIG

Now, this is just an example, but I would start by looking in the log file for clues.

If you log into your PI and then use the "tail" command with the "-f" parameter it will just list (or follow) the contents of the log file onto the screen (i.e. tail -f ~/klipper_logs/klippy.log ). For example:

pi@spiderpi:~ $ tail -f ~/klipper_logs/klippy.log
webhooks: registering remote method 'reboot_machine' for connection id: 1971065480
webhooks: registering remote method 'pause_job_queue' for connection id: 1971065480
webhooks: registering remote method 'start_job_queue' for connection id: 1971065480

You can then issue your "SAVE_CONFIG" command from the console window (in OctoPi) and see instantly what's getting written to the log file. To get out of the tail command just press Control+C

 

 

stepper_z: position_endstop: -0.418
The SAVE_CONFIG command will update the printer config file
with the above and restart the printer.
save_config: set [stepper_z] position_endstop = -0.418

.....

SAVE_CONFIG to '/home/pi/printer.cfg' (backup in '/home/pi/printer-20221225_225500.cfg')
Stats 6330.8: gcodein=12076  mcu: mcu_awake=0.008 mcu_task_avg=0.000004 mcu_task_stddev=0.000002 bytes_write=518887 bytes_read=514344 bytes_retransmit=0 bytes_invalid=0 send_seq=23222 receive_seq=23221 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=180001134 can0: mcu_awake=0.003 mcu_task_avg=0.000011 mcu_task_stddev=0.000011 bytes_write=90409 bytes_read=215259 bytes_retransmit=0 bytes_invalid=0 send_seq=6231 receive_seq=6231 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=8 stalled_bytes=0 freq=63999645 adj=63999198 Raspberrypi: temp=41.9 MCU: temp=32.9 CANBOARD: temp=33.5 heater_bed: target=0 temp=39.4 pwm=0.000 sysload=0.25 cputime=343.985 memavail=601280 print_time=6353.119 buffer_time=0.948 print_stall=0 extruder: target=0 temp=39.4 pwm=0.000
Stats 6331.8: gcodein=12076  mcu: mcu_awake=0.008 mcu_task_avg=0.000004 mcu_task_stddev=0.000002 bytes_write=518921 bytes_read=514498 bytes_retransmit=0 bytes_invalid=0 send_seq=23225 receive_seq=23225 retransmit_seq=0 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=180001134 can0: mcu_awake=0.003 mcu_task_avg=0.000011 mcu_task_stddev=0.000011 bytes_write=90423 bytes_read=215391 bytes_retransmit=0 bytes_invalid=0 send_seq=6232 receive_seq=6232 retransmit_seq=0 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=63999647 adj=63999181 Raspberrypi: temp=41.9 MCU: temp=32.9 CANBOARD: temp=33.4 heater_bed: target=0 temp=39.5 pwm=0.000 sysload=0.25 cputime=344.006 memavail=601280 print_time=6353.119 buffer_time=0.000 print_stall=0 extruder: target=0 temp=39.3 pwm=0.000
Restarting printer
Start printer at Sun Dec 25 22:55:02 2022 (1671983702.3 6332.9)
===== Config file =====
[mcu can0]
canbus_uuid = 31401ccdca9b

Still no update the auto generate value on printer.cfg file.

[smirk]

5 hours ago, Pradit said:

/home/pi/printer.cfg

That's rather interesting. that's not the standard place for the config file. The message does indicate that it saved the file.

 

If you log into the PI then you will probably find a bunch of "printer-CCYYMMDD-HHMSS.cfg" type files in the PI user's home directory (i.e. /home/pi), but I imagine you will also have a directory called /home/pi/klipper_config/ which is the regular configuration directory in that you might also have the printer.cfg file.

 

My hunch is your version of klipper is looking at a different version of the printer.cfg file from the one you happen to be editing (via the web interface?).

There's two ways to check. Logged into the PI, you can search the process list (using grep) to pull up the process for the Klipper daemon. For example, if you use the command 'ps -ef | grep klippy' it will bring up the klipper daemon:

pi@spiderpi:~ $ ps -ef | grep klippy
pi         692     1  5 Dec24 ?        01:24:20 /home/pi/klippy-env/bin/python /home/pi/klipper/klippy/klippy.py /home/pi/klipper_config/printer.cfg -l /home/pi/klipper_logs/klippy.log -a /tmp/klippy_uds
pi        8566 30140  0 22:04 pts/0    00:00:00 grep --color=auto klippy
pi@spiderpi:~ $ 

So the parameter immediately after the "klippy.py" command is the config file it is using. On my machine this is the file "/home/pi/klipper_config/printer.cfg".

The other way of checking which configuration file Klipper is using is by looking at the service definition file i.e. "/etc/systemd/system/klipper.service" in that file you are looking for a line starting with "Environment=KLIPPER_CONFIG" and that will tell you which config file Klipper is using by default. For example, a sample from one of my machines:

#Systemd Klipper Service

[Unit]
Description=Starts Klipper and provides klippy Unix Domain Socket API
Documentation=https://www.klipper3d.org/
After=network.target
Before=moonraker.service
Wants=udev.target

[Install]
Alias=klippy
WantedBy=multi-user.target


[Service]
Environment=KLIPPER_CONFIG=/home/pi/klipper_config/printer.cfg
Environment=KLIPPER_LOG=/home/pi/klipper_logs/klippy.log
Environment=KLIPPER_SOCKET=/tmp/klippy_uds

 

 

[smirk]

I was just thinking about this more (too stuffed full of  turkey to think straight) but your point about it all going wrong after doing the z_enstop calibration is perhaps a bit of a red herring.

There was a relatively recent Kllipper/Moonraker update that basically screwed lots of things up (I think it was a finnicky update that if it went wrong left your machine in an odd state). The changes to Moonraker were (in part) where it stored a lot of it's settings.

Moonraker/Klipper now store things in a new directory, e.g. /home/pi/printer_data/, inside that directory is a bunch of sub directories for things like logs and config, etc. To "simpfly" the update, those directories tend to be symlinks to the original directories.

Where I'm going with this.....before the update Klipper (Moonraker) absoluely looked to the directory "/home/pi/klipper_config/" for all configurations,however, after the update Klipper/Moonraker look to the directory "/home/pi/printer_data/config/" for all configurtions. In most installations (i.e. ones which have been upgraded over time) that /home/pi/printer_data/config/ is really a symlink to the already existing directory "/home/pi/klipper_config/".

It does not change my hunch that Klipper is running against one config file and the web interface is editing another set of config files, but might answer why it's gone Pete Tong.

[Pradit]

This is strange.

I tried again. After Save_config I went directly to cat printer.config in home/pi/ directory.

 

<---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
#*# [extruder]
#*# control = pid
#*# pid_kp = 22.542
#*# pid_ki = 2.147
#*# pid_kd = 59.174
#*#
#*# [heater_bed]
#*# control = pid
#*# pid_kp = 43.398
#*# pid_ki = 1.507
#*# pid_kd = 312.469
#*#
#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	  -0.096875, -0.027500, -0.020000, -0.030000, -0.068750
#*# 	  -0.060000, 0.038750, 0.009375, -0.035625, -0.084375
#*# 	  -0.040625, -0.013125, 0.000000, -0.035000, -0.065625
#*# 	  -0.054375, -0.033750, -0.081250, -0.085000, -0.084375
#*# 	  0.015625, -0.020625, 0.035000, -0.002500, -0.022500
#*# tension = 0.2
#*# min_x = 40.0
#*# algo = bicubic
#*# y_count = 5
#*# mesh_y_pps = 2
#*# min_y = 40.0
#*# x_count = 5
#*# max_y = 310.0
#*# mesh_x_pps = 2
#*# max_x = 310.0
#*#
#*# [stepper_z]
#*# position_endstop = -0.438

But if I open my web UI from octoprint it wasn't there.

 

[Pradit]

6 minutes ago, Pradit said:

This is strange.

I tried again. After Save_config I went directly to cat printer.config in home/pi/ directory.

<---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
#*# [extruder]
#*# control = pid
#*# pid_kp = 22.542
#*# pid_ki = 2.147
#*# pid_kd = 59.174
#*#
#*# [heater_bed]
#*# control = pid
#*# pid_kp = 43.398
#*# pid_ki = 1.507
#*# pid_kd = 312.469
#*#
#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	  -0.096875, -0.027500, -0.020000, -0.030000, -0.068750
#*# 	  -0.060000, 0.038750, 0.009375, -0.035625, -0.084375
#*# 	  -0.040625, -0.013125, 0.000000, -0.035000, -0.065625
#*# 	  -0.054375, -0.033750, -0.081250, -0.085000, -0.084375
#*# 	  0.015625, -0.020625, 0.035000, -0.002500, -0.022500
#*# tension = 0.2
#*# min_x = 40.0
#*# algo = bicubic
#*# y_count = 5
#*# mesh_y_pps = 2
#*# min_y = 40.0
#*# x_count = 5
#*# max_y = 310.0
#*# mesh_x_pps = 2
#*# max_x = 310.0
#*#
#*# [stepper_z]
#*# position_endstop = -0.438

 

But if I open my web UI from octoprint it wasn't there.

 

So I found it has another cfg file in .octoprint/

#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
#*# [extruder]
#*# control = pid
#*# pid_kp = 22.542
#*# pid_ki = 2.147
#*# pid_kd = 59.174
#*#
#*# [heater_bed]
#*# control = pid
#*# pid_kp = 43.398
#*# pid_ki = 1.507
#*# pid_kd = 312.469
pi@octopi:~/.octoprint/data/klipper/configs $ ls
printer.cfg

 

Any idea how to fix this?

[smirk]

The flippant response is "don't use Octoprint"

I'll need to have a think about that. I haven't used Octoprint for a while so cannot remember how it decides where to store it's configurations.

The real trouble that you have is somehow you've ended up with the config (the one you're editing, I presume) stored in  the home directory of the PI user as opposed to being stored in a proper sub-directory below the home directory. If both sets of configs had been in  sub-directories the bodge would be to simply replace the directory (with the config you're not interested in) with a symlink to the subdirectory with the desired config. However, since you're using your home directory and everything else will be a sub-directory off that you cannot take the symlink approach otherwise you'll create a circular reference (which Linux will not allow). Equally you cannot symlink the config files themselves - well you can symlink files but the moment you modify & save it the config file it will destroy the symlinking.

I'll need to stand up a copy of Octoprint and see how we can get Octoprint and Klipper agreeing on where the config actually is.

On a plus, the mystery of why it's happening has been solved, just need to figure out how to stop it

[Pradit]

In the web editor ui which i uses to config printer.cfg that store in .octoprint subdirectory has a button called Reload from file.

 

I pressed it then it reloaded the printed.cfg from my home directory.

Those autogenerated config now appeared.

 

I think ive got to do it manually everytime then. It has the button there for a reason.

 

[smirk]

1 hour ago, Pradit said:

I think ive got to do it manually everytime then. It has the button there for a reason.

I think you are possibly right.

Sounds like it is really a result of poor integration between Klipper and Octoprint. In mainsail, the web interface is directly working on the actual printer.cfg file (or whatever file you choose to edit), so if you make changes from Klipper itself they are immediately visible via the web interface. Also in Mainsail, you have the option of not just saving your edits but also doing a "Save  & Restart" which causes Klipper to reload the config files.

Sounds like Octoprint (web UI) does not work operate directly on the master/real config files, so if you make changes outwith the webUI (e.g. a PIDTune in Klipper) you have to klick that RELOAD button to "let Octoprint know about the changes".  I cannot figure out how changes made in the WebUI are reflected back into the actual (real) config files used by KLIPPER.

If I'm right in my suspicions, it is really working between two copies of the config files and requires manual intervention to keep them in sync (in effect), that just sounds like a recipe for absolute disaster (you've already experienced some of the issues). I  might set up an Octoprint/Klipper instance. I am intrigued that it could be so bad/dangerous - Octoprint is pretty good normally.

[Pradit]

But it was updated for me the 1st time with pid.

After long tuning and testing i dont know what i did along the way...

[smirk]

I don't think it will be anything that you have done, as such,  I really wouldn't expect anything tuning wise could have knocked it out. I think it would be more likely to be a software update (or conifiguraiton change directly to Octoprint) that will have knocked things out.