SAVE_CONFIG section 'probe' option 'z_offset' conflicts with included value

[kharrisma]

Hopefully this is a simple fix!  I'm running "calibrate_probe," and it goes well until come time to save the value to "printer.cfg."  Every time I enter "save_config," I get this error mesage:

"SAVE_CONFIG section 'probe' option 'z_offset' conflicts with included value"

Klipper won't boot properly if there's *no* value in "z_offset," but once I enter a figure, it boots fine, but I get that error when trying to fine-tune my z-offset.  I've tried using 0.1, 0.0, and even -0.1, and it doesn't like any of them, with respect to "save_config."  I didn't even have a {probe} section, just a "safe_z_home" section.  It probed pretty close and prints, but after adding linear rails to the Y axis, (AND moving the Y axis extrusion forward by 30mm to compensate for the -Y of the nozzle created by replacing the toolhead with a stealthburner), I've got first layer issues and would like to tighten down the Z offset.  I'm including my printer.cfg file.  I've looked at the klippy.log, and there IS an error there, but it's just the same one I get in the console, plus a bunch of gobbledegook following it.  Happy to post it as well if anyone thinks it's necessary.  Thanks in advance!

config-20250529-123915.zip logs-20250529-124008.zip

[NikosSprocket]

At your [probe] section comment, just put a # in front of "z_offset:-0.1", and give it another try to "calibrate_probe".

[kharrisma]

Hi Nikos,

Did as suggested, commented out "z_offset" parameter and did a 'save/restart.'  No issues.  Fired up "probe_calibrate," and went through the process until adjusted to my satisfaction.  Hit Accept and "probe-calibrate" closed, suggesting that "save_config" be run.  Did so, and got the same error: "SAVE_CONFIG section 'probe' option 'z_offset' conflicts with included value"  No change, issue remains.

[NikosSprocket]

Sorry; this is strange.

Also, I was looking at your "SAVE_CONFIG" section at the bottom of your printer.cfg, and it is missing some blocks, like the "probe" and "heater_bed". Below is the top part of mine; cut off the different bed_mesh configurations. It almost seems klipper cannot write on printer.cfg file.

Also, check the other *.cfg files that do not have any "z_offset" 

It almost seems klipper cannot write to the printer.cfg file.

Can you login to your Pi and try the following:

cd ~/printer_data/config/

ls -la

You should see something like:

.............

-rw-r--r--  1 pi pi 21812 Apr 24 05:26 printer.cfg

-rw-r--r--  1 pi pi 21812 Apr 24 05:26 nitehawk-sb.cfg

-rw-r--r--  1 pi pi 21812 Apr 24 05:26 tacho_macros.cfg

-rw-r--r--  1 pi pi 21812 Apr 24 05:26 stealthburner_led_effects_barf.cfg

..............

Do you have "pi" or some other owner/group?

Do you see "-rw-r--r--" ?

 

 

 

#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
#*# [heater_bed]
#*# control = pid
#*# pid_kp = 37.378
#*# pid_ki = 1.187
#*# pid_kd = 294.351
#*#
#*# [probe]
#*# z_offset = -0.695
#*#
#*# [bed_mesh Cold]
#*# version = 1
#*# points =
#*#     0.002500, 0.006250, 0.008750, 0.005000, 0.001250
#*#     0.002500, 0.017500, 0.015000, 0.007500, 0.002500
#*#     -0.003750, 0.008750, 0.000000, -0.002500, -0.013750
#*#     0.016250, 0.030000, 0.021250, 0.012500, -0.005000
#*#     -0.030000, 0.028750, 0.020000, 0.011250, -0.005000
#*# x_count = 5
#*# y_count = 5
#*# mesh_x_pps = 2
#*# mesh_y_pps = 2
#*# algo = lagrange
#*# tension = 0.2
#*# min_x = 40.0
#*# max_x = 260.0
#*# min_y = 40.0
#*# max_y = 260.0
#*#

...........................................................

[NikosSprocket]

I forgot all about the same message appeared to my latest upgrade with CAN networking some time ago.

The following showed today when I was PID the replacement hotend:

SAVE_CONFIG section 'extruder' option 'control' conflicts with included value

In my case, Klipper could not "write" the PID information because the Extruder section is not in the printer.cfg, as expected, but in the EBB configuration file bigtreetech-ebb-canbus-v1_2.cfg; which is "included" in the printer.cfg:

[include mainsail.cfg]

[include bigtreetech-ebb-canbus-v1_2.cfg]

Therefore, I manually entered the new values to the correct file and location. The PID process displays the results at the end of the session:

PID parameters: pid_Kp=15.508 pid_Ki=0.744 pid_Kd=80.841
The SAVE_CONFIG command will update the printer config file
with these parameters and restart the printer.

On the bigtreetech-ebb-canbus-v1_2.cfg file added the new valuesfrom above:

control: pid
pid_Kp: 15.508 
pid_Ki: 0.744
pid_Kd: 80.841

I hope this helps.

[3DCoded]

I think @NikosSprocket's suggestion is the most likely one. The Klipper knowledge base also recommends it.

 

https://klipper.discourse.group/t/save-config-section-bltouch-option-z-offset-conflicts-with-included-value/6640?u=3dcoded

[kharrisma]

Thanks, Nikos!  That would explain why Klipper's unhappy: my [probe] configuration, where the updated information needs to go, isn't in the printer.cfg file, it's in the nitehawk.cfg file instead.  So I just note the new z-offset value and manually enter it into the [probe] parameters in the nitehawk file, and should be good. 

In the nearly 30 years I worked on electric forklifts, one thing I learned fairly early on was *stick to the basics.*  If a machine was acting strangely, jumping straight into the control electronics usually ended up being a bad idea, where checking to see if the battery had water in it or was leaking voltage through the case and into the frame of the truck was usually a much better idea and produced positive results a lot faster!  Klipper basics: Klipper can write ONLY to printer.cfg, not to any [include *.cfg] file.  Lesson learned!

Since the probe runs through the nitehawk toolhead board, does the [probe] configuration *need* to be in nitehawk.cfg, or can I safely move it to printer.cfg, with future z-offset adjustments in mind?  No idea if the probe output is just a passive "pass-through' the nitehawk, or if the output has to be processed by the nitehawk mcu so moving [probe] to printer.cfg would cause the probe to not work.  Anyone know this for sure, or is it time to roll up the sleeves and start tinkering?

[kharrisma]

@3DCoded:  I'm embarassed to admit that I did read that discord post, but I blew past it because I totally forgot that the [probe] section was now in an [include...] file, exactly as Sineos described.  Wouldn't be the first time he's figured into the solution with an issue I've had!  Much appreciated!

[NikosSprocket]

You are very welcome!