If you're staring at the error save_config section extruder option control conflicts with included value, you've likely just run a PID tune and are wondering why Klipper is refusing to cooperate. It's one of those classic 3D printing hurdles where everything seems to be going fine until you hit "save," and suddenly the firmware starts complaining about its own configuration files. Don't worry, you haven't broken anything major; your printer is just confused about which instructions it's supposed to follow.
This usually happens when you're trying to use the SAVE_CONFIG command—most commonly after calibrating your heater or probe—and Klipper realizes that the value it wants to save is already defined somewhere else, typically in a file that's being pulled in via an [include] statement. It's Klipper's way of preventing a logic loop where it doesn't know which setting takes priority.
What's actually happening under the hood?
To understand why this error pops up, we have to look at how Klipper handles its settings. Most of us start with a single printer.cfg file, but as we get more advanced, we start breaking things out into separate files like extruder.cfg, macros.cfg, or steppers.cfg. We use the [include] command to keep our main config clean.
When you run a command like PID_CALIBRATE and then type SAVE_CONFIG, Klipper tries to take those newly calculated numbers and write them permanently into your printer.cfg. Specifically, it creates or updates a special block at the very bottom of the file, wrapped in those "DO NOT EDIT" warning comments.
The conflict arises because Klipper is programmed to automatically comment out the old values in your main printer.cfg to make room for the new ones in the save_config block. However, if your control: pid or other extruder settings are hidden away in an included file, Klipper isn't allowed to reach into that separate file and comment them out. It sees the setting in the included file, tries to write the new setting in the main file, realizes there will be two conflicting "control" options active at the same time, and throws the error to keep your printer from doing something weird.
Hunting down the double definitions
The first thing you need to do is play detective. Open up your printer.cfg and look at your [extruder] section. If you see lines for control, pid_kp, pid_ki, and pid_kd, but you're still getting the error, it's a sign that these same lines exist somewhere else.
Check your [include] lines at the top of your config. If you have something like [include extruder.cfg], go open that file. You'll probably find the control: pid setting right there. Because Klipper reads everything together as one giant configuration, it sees the version in your included file and the version it's trying to save at the bottom of printer.cfg as a direct fight for dominance.
It's a bit of a headache because we want our configs organized, but Klipper's automatic saving mechanism really prefers it when the values it needs to overwrite are right there in the main file where it can "see" and "disable" them properly.
How to fix the conflict for good
There are a few ways to handle this, depending on how you like to organize your files. The most straightforward fix is to move your PID settings out of the included file and into the main printer.cfg.
If you have an extruder.cfg that contains your entire [extruder] section, you can try leaving the basic stuff like pin and sensor_type in the included file, but move the control and pid_ lines to the main file. But honestly, Klipper can be picky about split sections. A better way is to comment out the PID lines in your included file entirely.
Once you've commented out (put a # in front of) the control, pid_kp, pid_ki, and pid_kd lines in your included file, go back to your main printer.cfg. If there's already a [save_config] block at the bottom, you might want to manually delete the old extruder-related lines there just to give yourself a clean slate. Then, restart Klipper, run your PID_CALIBRATE again, and hit SAVE_CONFIG. This time, Klipper should see that there aren't any active "control" values elsewhere, and it'll happily write the new ones to the bottom of your main file.
The "Manual" alternative
If you're someone who hates the messy save_config block at the bottom of your files—and let's be real, many of us do—you can skip the SAVE_CONFIG command entirely. When the PID tune finishes, Klipper will output the new values in the console. You can just copy those numbers, open your extruder.cfg (or wherever you keep your settings), and paste them in manually.
If you go this route, you don't have to worry about the save_config section extruder option control conflicts with included value error ever again because you aren't asking the firmware to automate the process. You're the boss. Just remember that every time you tune your heater, you'll have to do this manual copy-paste dance.
Why organization matters here
It might feel like Klipper is being overly sensitive, but this strictness is actually a safety feature. Imagine if you had two different PID tunes active at the same time. The heater logic would get incredibly jumpy, potentially leading to thermal runaway or at least some very ugly print layers.
When you're building a complex config with lots of includes, it's a good habit to decide early on what stays in the "static" included files and what stays in the "dynamic" main file. Things that never change—like which pin the heater is plugged into—are great for included files. Things that you calibrate often—like PID tunes, bed meshes, and Z-offsets—are usually better off living in the main printer.cfg where the SAVE_CONFIG command can manage them without tripping over its own feet.
Common mistakes to watch for
Sometimes, even after you think you've fixed it, the error persists. This usually happens because there's a sneaky duplicate somewhere. Maybe you have [include macros.cfg] but for some reason, you pasted a backup of your extruder settings at the bottom of that macro file weeks ago and forgot about it.
Using a text editor with a "Find in Files" feature (like VS Code or the built-in editor in Mainsail/Fluidd) is a lifesaver here. Search for the word control across all your configuration files. If it shows up in more than one active spot, you've found your culprit.
Another thing to check is the [save_config] block itself. If you've been manually editing your files and accidentally deleted the #*# markers that Klipper uses to identify its territory, the firmware might get confused. It needs those markers to know which part of the file it's allowed to overwrite. If they're messed up, Klipper might think those values are "user-defined" and refuse to touch them, leading to—you guessed it—a conflict.
Wrapping it up
Dealing with the save_config section extruder option control conflicts with included value error is really just a rite of passage for Klipper users. It's a sign that you're moving away from basic setups and into the world of modular, organized configurations. Once you understand that Klipper just wants a clear, undisputed place to store its data, fixing the issue becomes a simple matter of tidying up your files.
Keep your calibrated values in one place, make sure your included files aren't fighting for control, and you'll be back to printing in no time. It's all part of the learning curve, and honestly, once you get your head around how the [save_config] block interacts with your includes, the rest of Klipper's logic starts to make a lot more sense.