I have a 50mb klippy.log file currently, its a pita to upload to discord with troubleshooting.
Whenever people run into issues its normally something that only is needed to be seen in the most recent SBC restart. Having the log file restarted on each SBC wakeup would not take 50mb and be annoying (:

Using the new sensorless feature I noticed that the Y axis of my K3 is homed twice, likely because homing_positive_dir is False and the distance moved is negative.

Original code - homing.py:

Adding some additional logging to the code:

# X
homing_axis_distances: [69.30625]
hi.retract_dist: 40.0
needs rehome: False
# Y
homing_axis_distances: [-94.00625000000001]
hi.retract_dist: 40.0
needs rehome: True
# Z
homing_axis_distances: [-8.01625]
hi.retract_dist: 0.0

If I convert the dist variable to an absolute value it works as expected (axis is homed only once):

if any([abs(dist) < hi.retract_dist for dist in homing_axis_distances]): 

Homing the axis with the absolute value:

# X
homing_axis_distances: [69.30625]
hi.retract_dist: 40.0
needs rehome: False
# Y
homing_axis_distances: [-92.80312500000001]
hi.retract_dist: 40.0
needs rehome: False
# Z
homing_axis_distances: [-8.03]
hi.retract_dist: 0.0

Currently, if you have an imported cfg that save_config wants to override, it cannot comment out the lines in an imported cfg. configfile.py does properly override and can be overwritten, but the initial commenting out in an imported cfg cannot be performed.

With extruder block in a separate config, no PID settings in the save_config variable block, and no extruder section in printer.cfg, when you hit save_config, you get this error
"SAVE_CONFIG section 'extruder' option 'control' conflicts with included value"
However, if you add something to the variable block on printer.cfg, it is able to override those values which do properly apply.

Proposal is just to fix save_config to also check any included files for the particular block it is looking for (in this case, [extruder])

I tried to do this but I'm too smooth. Basically, I want to pass accel_per_hz into the csv, and then also use it when the graph png is generated. The reason it needs to be passed into the csv is because the current value may not match the value from when the csv was created.

• Pass it into the generated csv
• Add it somewhere that makes sense on the graph generation (above/below recommended shaper or something)

This should probably also be ported over to bleeding edge.

I'd like to rework this commit here to instead load a mesh defined in the [bed_mesh] section.
Behavior desired:
define in bed_mesh config block:
bed_mesh_default = [mesh name here]

If no default mesh defined, load nothing. If the specified mesh doesn't exist, either load nothing or give error.
Otherwise, load specified mesh on boot.

Idea from Mr. Leddhedd.

Currently, one of the more effective methods to control a chamber heater is done in a somewhat hacky way by configuring the PTC heater as a reverse temperature fan along with a temperature fan to circulate hot air. An example configuration is shown:

[temperature_fan chamber_heater]
sensor_type: Generic 3950
sensor_pin: #chamber_thermistor
min_temp: 0
max_temp: 120
gcode_id: chamber_heater
pin: #to chamber heater ssr
target_temp: 0
shutdown_speed: 0
control: pid
pid_Kp: 2
pid_Ki: 5
pid_Kd: 0.5
reverse:true

[temperature_fan chamber_heater_core]
sensor_type: Generic 3950
min_temp: 10
max_temp: 250
sensor_pin: #ptc_core_thermistor
gcode_id: chamber_heater_core
pin: #to large fan
target_temp: 65
shutdown_speed: 1
control: pid
pid_Kp: 200
pid_Ki: 15
pid_Kd: 400
kick_start_time: 0.5 

This results in a behavior where the chamber heater is turned on by setting the "temperature fan" called chamber_heater to the desired chamber temperature, at which point the chamber heater's will will enable as soon as the temperature of the core reaches the defined target_temp, in this case 65 degrees.

Instead, it would be simpler and more consistent with the other heaters used typically in a printer if Danger Klipper would have a built in heater_chamber heater type. Then a config could be defined in a more consistent manner, perhaps in a similar fashion to how the [extruder] section of configuration is set up. Then a minimum config section could be defined specifying the pins for the heater_core, core_thermister, chamber_thermister, and chamber_fan as well as their respective minimum and maximum temperatures.

I am having a hard time figuring out how to get extra IS features working.

There are no clear instructions on how to accomplish these features.

Any help would be greatly appreciated!

Currently, saved variables are stored at the end of the printer.cfg file in an odd structure. In my humble opinion, there are several areas for improvement.

• Store these variables in a separate file from printer.cfg (without those ugly comments structure). Hopefully, this will simplify the structure. This file would simply be read after printer.cfg when loading the configuration.
• Allow values to be overridden (as is alreadyin the rest of the configuration). Indeed, in the case of a distributed configuration, it is currently impossible to perform a SAVE_CONFIG, klipper returns an error, (I don't know the exact mechanism). -
• So, commenting on configuration variables becomes obsolete

I hope I've made myself clear, thanks for your work!

I first reported this for mainline Klipper in 2021: Klipper3d/klipper#4442. Since then, a number of people have become interested in the matter, and I think we've come to better understand the issue.

To recap, the original "smell" was that the behavior you get with PA of 0.00001 is vastly different from with PA=0, because whenever PA is "on" (nonzero), PA smoothing is in effect, and it not only smooths the amount of advancement made by the extruder to compensate for pressure needed to extrude at higher velocity, but also smooths out the base motion of the extruder.

On the upstream report, myself and others did a lot of math explaining why this is bad theoretically, but since then the biggest practical effects identified have been:

• Smoothing applies to retraction. This interferes with extrusion just before a retract or after an unretract, and is likely responsible for a number of issues people see with poor restart after retraction, especially if the problem is speed/accel-dependent.

• When E base position is smoothed around corners and the cornering time is significantly less than the smooth time, the extrusion rate does not lower like it should at the corner, but is only slightly lowered in a large neighborhood of the corner. This means the corner itself bulges, with slightly too little material before/after the corner. This can be partly compensated by using a larger PA value to negate the corner bulge, but that's wrong and will make non-corner velocity changes extrude wrong. I believe this is the main mechanism by which PA is believed to be "acceleration-dependent" and "speed-dependent" - the fudge factor here depends on the relationship between speed, accel, and smooth time.

There was no progress on reaching consensus to upstream a fix for this, but there were two implementations of the concept:

1. an original hack by myself that just ran the integration twice, once with PA=0, and subtracted that one (the pure smoothed base position) out to get a smoothing of just the advance, then added the unsmoothed base position, and

2. a more invasive patch by @Piezoid to completely remove base position integration. This saves compute time rather than adding to it, but is hard to rebase against upstream changes. I'm not sure where the original is but my inclusion of it was here: richfelker/klipper@84431c3

I would like to see DangerKlipper lead the way in getting rid of base position smoothing by PA. Dmitry's work in bleeding edge has already factored out the integration of advance vs base position, such that the following minimal patch disables use of the smoothed base position:

diff --git a/klippy/chelper/kin_extruder.c b/klippy/chelper/kin_extruder.c
index 50f33f96..cf3735d4 100644
--- a/klippy/chelper/kin_extruder.c
+++ b/klippy/chelper/kin_extruder.c
@@ -226,6 +226,10 @@ extruder_calc_position(struct stepper_kinematics *sk, struct move *m
                 pa_range_integrate(m, axis, move_time, sm,
                                    &e_pos.axis[i], &pa_vel.axis[i]);
             }
+            // get rid of (bad! bad! bad!) smoothing of base position
+            e_pos.axis[i] = num_pulses
+                ? shaper_calc_position(m, axis, move_time, sp)
+                : m->start_pos.axis[i] + m->axes_r.axis[i] * move_dist;
         }
     }
     double position = e_pos.x + e_pos.y + e_pos.z;

Clearly this is not the right way to do it, since it throws away a bunch of nontrivial computation.

If we want to leave smoothing of the base position as optional behavior, I believe the right thing to do is to separate the integration into two calls, where integrates the base position (only called if desired) and the other integrates the advance ("velocity") and returns it (no more need for returning a second value via a function pointer). But I'm not sure if this code is used anywhere else, like in IS smoothing; if so, more care is needed when ripping it in two.

If we don't want to keep smoothing of the base position at all, the integration can be simplified to only integrate the advance ("velocity") term.

If there is consensus on how to proceed, I'm willing to work on the actual code changes and PR.

I know people who never turn off their printer and always have it heating. Adding a idle_timeout timeout=0 call just doesn't work for klipper. Wondering if way to make it turned off or just set to 0 to turn off the feature?

I'm suggesting adding functionality to #65 that, on second home (via minimum homing distance), it compares the distance to the home move.
If homing retract distance is 10mm, you should see ~10mm worth of movement + some margin of error between the move start and it hitting the endstop. If you don't, throw an error as a sensorless homing fault has occurred.

Say your sensorless triggers mid X travel, it will retract 10mm and rehome. If it moves more than 10mm, it will throw a fault.
If your toolhead is at the endstop, and it hits the endstop, it will retract 10mm, rehome, calculate distance moved to be ~10mm, and will not throw a fault.

One issue with this idea is that it will not function if the distance traveled is OVER minimum homing distance/retract distance, but it triggers mid beam.

Hopefully all of this makes sense.

Since version 0.10 Klipper doesn't fit on the less powerful AVR microcontrollers anymore, namely:

• atmega168
• atmega328
• atmega328p
• atmega32u4

In 2022 I made some experiments to try and solve that, like:

• manually compiling avr-gcc from gcc 12.1.0 (I followed the instructions on this blog post: https://blog.zakkemble.net/avr-gcc-builds/), since the avr-gcc that is packaged on Debian is version 5.4, which means we don't have access to a lot of optimization options and flags;
• also manually compiled and installed version 2.1.0 of AVR-LibC.

After these were installed, proceeded to compile a lot of tests, including manual Makefile edits, and while using optimization flags/option did indeed reduced the compiled firmware, they were still too big to fit an ATmega32U4 mcu (which was my main concern at the time).

What really did the trick was manually commenting out some files on the /src directory. On my case, I have designed a toolhead control keyboard, so I could use it to move the toolhead without the need to go to my computer for that. Because of the use case, I commented some files entirely, like lcd_hd44780.c, lcd_st7920.c, neopixel.c, sensor_adxl345.c, and thermocouple.c, which made the resulting firmware finally fitting the 32u4.

You can already select features to be disabled on the make menuconfig environment, as seen here:

and here:

, but they are only available for the atmega168, atmega328, and atmega328p microcontrollers, leaving the 32u4 uncovered, and even so they are not enough to make the firmware fit as is. So, my request is to expand the features that can be removed, so you can make Klipper fit those AVR mcus again, and add these options for the mega32u4 mcu.

Hello! I'm making a custom printer that's extruding some strange material (sorry cannot say much) and I plan to have an extruder with two cartridge heaters and one (or maybe two) thermistors. The cartridge heaters will be the same and I would like to control it with one input, do you think this would be possible? And if I used two thermistors to take the average value from them to determine the temperature?

I looked on some online forums and they reccomended using danger klipper. Thank you for your help and time, I appreciate it loads and am looking forward to your responses. Thank you again!!

3W
What - Change how DK treats the "kinematics: none" setting. Today it requires you to remove stepper settings and some arbitrary acceleration settings to allow you to boot with this specific setting.
Why - To make the setting significantly more usable to configure your printer in whatever order you want, this setting could enable that
Who - Anyone ever wanting to randomly disconnect a mcu dealing with steppers without having to comment out various config blocks to debug issues, change the order of operations on your configuration journey or just not like being annoyed by arbitrary needs to comment out settings you'll need to comment back in later

TLDR; make "kinematics: none" not be super annoying to use when you've got a half-baked printer config you're trying to work on and not be forced into this odd order of operations the current setting implementation insists of doing.

Hi there. I've been using @dans98 's fantastic PID tuning improvements on my Artillery Genius printer since moving it over to Klipper. The improvements have made Klipper useable for me in terms of fixing bed temp overshoot.

I've recently replaced my hotend heat block, and my hotend temps have been overshooting pretty severely since. I did a PID tune using stock Klipper, and gave up waiting for the integral windup overshoot to settle to the target. So, retrying the updated PID tuning code, I get results that I don't recall as typical, based on my bed tuning escapades last year.

Here's an example:

01:50 PID parameters: pid_Kp=63.194 pid_Ki=7.435 pid_Kd=134.288
The SAVE_CONFIG command will update the printer config file
with these parameters and restart the printer.
01:50 sample:15 pwm:1.0000 asymmetry:-5.1549 tolerance:0.0000
01:50 sample:14 pwm:1.0000 asymmetry:9.4129 tolerance:14.9269
01:50 sample:13 pwm:1.0000 asymmetry:-0.1686 tolerance:14.9269
01:50 sample:12 pwm:1.0000 asymmetry:-6.5073 tolerance:14.9269
01:49 sample:11 pwm:-13.9269 asymmetry:-3.4528 tolerance:14.9269
01:49 sample:10 pwm:-9.3790 asymmetry:2.5606 tolerance:10.3790
01:49 sample:9 pwm:-1.9767 asymmetry:4.6231 tolerance:5.4575
01:49 sample:8 pwm:1.0000 asymmetry:4.8241 tolerance:5.4575
01:49 sample:7 pwm:1.0000 asymmetry:5.4395 tolerance:5.4575
01:49 sample:6 pwm:-4.4575 asymmetry:-4.5732 tolerance:5.2660
01:49 sample:5 pwm:-3.4905 asymmetry:0.9791 tolerance:4.4905
01:49 sample:4 pwm:-0.9058 asymmetry:-5.9395 tolerance:1.9058
01:49 sample:3 pwm:0.8085 asymmetry:-5.1476 tolerance:n/a
01:49 sample:2 pwm:1.0000 asymmetry:-0.6716 tolerance:n/a
01:49 sample:1 pwm:1.0000 asymmetry:5.4062 tolerance:n/a
01:46 PID_CALIBRATE HEATER=extruder TARGET=240 TOLERANCE=0.01 WRITE_FILE=1

My concerns here are:

• The calibration "completes" suspiciously quickly -- samples are being reported in bursts, with the whole thing completing in a minute or so after reaching temp.
• In addition, oftentimes the asymmetry will bounce between +ve and -ve values, then the tolerance will suddenly slam to 0. NB: I do recall the tolerance suddenly hitting zero from tuning the bed, but cannot recall the significance or remediation.
• Not shown, but if I reduce the target temp to 220, I'll get a "extruder not heating at expected rate" error. I've also tried with increasing the tolerance to 0.02.

I'm unsure if this is a bug (especially the tolerance suddenly hitting a flat zero) or expected behaviour that isn't elucidated in the docs.

Here's some supporting info, if it helps:

Screengrab 1:

Screengrab 2:

klippy.log (link to sprunge.us pastebin)

Many thanks for any insights anyone could offer!

Gcode shell execution is great! However, it doesn't need to be enabled 100% of the time, and it could potentially introduce new vulnerabilities that would not be present without the ability to execute gcode shell commands. Disabling gcode shell execution when it is not needed should remove or greatly reduce the possibility of the machine being compromised through the execution of gcode or mainsail/fluidd console commands.

Use-case:

I have several nearly identical printers in a print farm. They all have custom toolheads, with CANBUS toolboards -- but all the toolheads are built identically to serve as warm-swap assemblies immediately after a failure. The expectation is regardless of the failure, I can swap a new toolhead in, restart the print, and then diagnose and repair the swapped toolhead at a better time.

Problem

The current state of the Klipper CANBUS implementation requires a step to query the bus and identify all UUIDs that are returned, and update a configuration file with the correct UUID. My understanding is that this UUID is read from either a chip identifier, or a hardcoded section of ROM, and is not changable by the end user.

Proposed Fix

What would be changable by the end user though, is a constant value set by the Makefile. If an option (under "Enable low-level options", requiring an extra step to access) was added to allow the user to specify a UUID, I would be able to flash all my toolheads with the same random ID. Since my machines will only ever run one toolhead at a time, this would allow me to swap the toolhead and restart the print, without having to open a terminal and query for CAN hardware, then update configuration files.

Mansplaining why this is an easy fix despite no experience in this codebase

My expectation is this hardcoded value could be stored in a compile-time array while the "reply to UUID request" code can check this array for a value, and if absent populate it from the original UUID mechanism (then always return the array contents when queried). Setting the option would pre-populate the array, so the code at runtime would not know (or care) if the array had been filled via compile-time directive, or queried earlier.

Perhaps an idea that should be simple to implement, but it would would be nice to have another parameter in the Z Tilt / QGL section of the config to adjust the gantry height lower to the bed after the initial correction. Essentially, after the initial lap of the gantry level, the second lap (and however many retries it does) can be much closer to the bed. This would allow the horizontal_move_z parameter to be very close to the bed, while initial_horizontal_move_Z could be much higher off the bed to avoid a gantry crash. This would cut down on gantry level times significantly if the probe lowering speed is relatively slow.

I'm try to switch to danger klipper from klipper, so i can do some testing and do a pr for the pid calibration improvements. I used kiauh to switch over to my fork of danger clipper master, but im getting an error thats looks to be encoding or json decoding related.

klipper: v0.0.0-5104-g2c0d70bb-inferred
mainsail: v2.7.1
moonraker: v0.8.0-138-gfe120952

from the klipper log

webhooks: Error decoding Server Request {"id": 1978684400, "method": "info", "params": {"client_info": {"program": "Moonraker", "version": "v0.8.0-138-gfe12095"}}}
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/webhooks.py", line 268, in process_received
    web_request = WebRequest(self, req)
  File "/home/pi/klipper/klippy/webhooks.py", line 63, in __init__
    raise ValueError("Invalid request type")
ValueError: Invalid request type

from the moonraker log

2023-08-27 15:42:55,577 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.info, Code: -32601, Message: Method not found
2023-08-27 15:42:57,577 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.info, Code: -32601, Message: Method not found
2023-08-27 15:42:59,579 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.info, Code: -32601, Message: Method not found
2023-08-27 15:43:01,578 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.info, Code: -32601, Message: Method not found
2023-08-27 15:43:03,582 [common.py:build_error()] - JSON-RPC Request Error - Requested Method: printer.info, Code: -32601, Message: Method not found
2023-08-27 15:43:04,831 [klippy_connection.py:wait()] - Request 'info' pending: 60.00 seconds

logs:
klippy.log
moonraker.log

i went into the WebRequest init and added a little logging.

        if not isinstance(self.method, str) or not isinstance(
            self.params, dict
        ):
            logging.info("dls method is : %s" % (type(self.method)))
            logging.info("dls params is : %s" % (type(self.params)))
            raise ValueError("Invalid request type")

the logged info.

dls method is : <type 'unicode'>
dls params is : <type 'dict'>

I'm not sure why this is happening, as i thought unicode was considered to be a string. if i revert to klipper everything works fine.

https://dangerklipper.io/Dockable_Probe.html

not sure what "Pin" I need to add? z endstop pin?

The activate_gcode option is listed on the Dockable_probe section documentation, yet it currently doesn't work.
Although reported that it's presence on the docs is a bug; it would be a nice, if not needed, feature, for probes such as Klicky00, that require limiting nozzle temperature in order to not melt the probe upon nozzle contact.

Issue

When using canbus or multiple MCUs sometimes during homing or operations which requires MCUs working in unison a timeout can happen. Currently this is coded as 0.025.

E.g. Homing - Communication timeout during homing probe

Workaround

Open up the timout value of TRSYNC_TIMEOUT in mcu.py to 0.05 either by editing directly or using rootiest script https://github.com/rootiest/zippy-klipper_config/blob/master/scripts/mcu_timing.sh to partially automate it.

However any changes to mcu.py get reverted on a pull.

Proposed Change

Make TRSYNC_TIMEOUT a variable

Introduced in Discord 4/5/24. Link

Abstract

Adding an air heater to the part cooling duct, to heat the cooling air above chamber temp, resolves many print quality, isotropy, and strength issues with high temp filaments that are prone to strain/stress and poor interlayer adehsion if the build volume is below a given material's glass transition temperature.
In "high temp" printing it is generally assumed one "cannot use cooling", but this is not true if the cooling air is sufficiently preheated. In fact, this method becomes compulsory to approach true strength potential with these feedstocks in non-commercial, high-end printers.
Klipper (and slicers I know of) have no native means to assign n+, independent heaters/sensors to a toolhead, nor control it/them in parallel (or in the loop) with the native part cooling fan controls that Klipper & Slicers definitely do control now.

This is a separate dynamic from chamber heat control, but dumping this much extra heat into the chamber could present challenges that are at odds with other workflows that try to keep chamber temperature up, down, or steady. In my case I need to actively cool my chamber, which I do now by propping the door open. That's another issue to resolve later, with other controls that are preferably in the loop too.

My Awareness

I'm really new to DK, so doing my best not to suggest things that exist. I've perused some related functionality that blends some of the heater and fan modules to overcome overlap between existing fan & heater modules that can't be used together sensibly:
#168 Fan Mixer - this could be useful if two airflow sources are needed for the heated PC.
#194 Controller temp fan - two competing sources of fan input is maybe the problem space, but with heater controls in the loop too.
#129 ADC Ignore - this might help with some of the problems by chamber temp drift from extreme heated part cooling thermal loads.

Requirements for my build

Safety

• when part cooling air heater is on, the PC fan must be on.
• when PC air heater is commanded OFF, the part cooler fan should be ON for a user-configurable post flow to prevent latent heat roasting anything it shouldn't. Some applications won't need it (e.g. metal heater housings). Pumps will cease flow promptly, fans may not.
• when fan speed < 100% the heater should be able to maintain target temp without error. Slicers can set PC fan speed very low.
• there should be some awareness between extruder temp and PC air/heater temp to prevent accidental overshoot. 250° C part cooling air could melt your print if you fat finger a temp control override in Mainsail et al.
• Multiple temperature sensors may be needed to really control the results as well as make smarter safety workflows possible. I'm considering some sort of flow/pressure sensor to make sure air is flowing as expected rather than just hoping the fan/pump is working.
• fan RPM verification with magnet on the motor shaft and hall sensor - this would be second choice to using air pressure for very safe heater usage.

Function

• M106 commands from slicer to GCODE should be able to control fan speed like a normal printer.
• Ideally the slicer could do the work of picking heated cooling target temperature, which is largely a function of feedstock Tg, but can only really be determined through experimentation.
• • If not possible, there has to be some compulsory prompt in Octo/Mainsail when starting a print that makes you pick a temperature.
• Being able to optimize both air speed and temperature is not something slicers seem capable of doing, but rheology in this application suggests there is and should be a relationship.
• Non-critical temperature fluctuations should not kill the print, but there still need to be ways to cascade higher severity measures as more unsatisfactory conditions are detected. If part cooling temperatures can't be controlled, it would still be preferable to continue the print if everything else is nominal. It may even be OK to keep pumping chamber-temp cooling air (but not ambient temp, which depends on your airflow source).
• There may be potential for in-situ annealing with really hot part cooling air, which is uncharted but exciting territory. For instance, deposit a layer, then run a slow annealing air pass along a path. I know, this is getting complicated.

I have other functions that I can't recall at the moment, but would like to submit this and then add to it as I remember.

Integration

• Chamber temp creep
  I have a 120VAC PTC and 12V blower in one unit, no problem getting the chamber to target temp (normally 135C) but to use filaments with high Tg I run my 310x310mm bed at 190C-230C which causes big chamber temp creep. Once I implement water cooling on motors I can let the chamber go to 150C. Propping the door open to vent it is not good. I need an active chamber cooler, which will be some kind of radiator with an HT fan on the inside of the chamber pushing air through the radiator on the outside. I think the heater and cooler need to work together. This might already be solved.
  The part cooling heater may be able to push up to 260C air, which also will cause creep that the system needs to know about toi avoid unnecessary conflicts- especially as flow increases.

Flopana77 has done some good work on firmware retractions for Klipper. This PR was declined for resource reasons on the Klipper mainbranch. Could this feature be pulled over into DK or at least DK Bleeding Edge?

Klipper3d/klipper#6311

Per the authors related work an extension of this feature is to add additional support for other types of z-hop moves.

Mainline Klipper 0.12 introduced a new axis_twist_compensation calibration, however it does not support dockable probes: https://www.klipper3d.org/Axis_Twist_Compensation.html

Could this be added to DK?

During machine configuration, it is necessary to establish the bounds the toolhead can safely move.

If the homing routine for an axis was expanded to display the distance travelled, this could dramatically simplify the initial setup of a machine. A procedure where the end user manually positions the toolhead to a known position (such as axis minimum) and then homing will get what the machine thinks the travel on that axis is. Knowing, for instance, that my X axis has 304mm of travel (as output by a DEBUG statement) will allow me to configure position_min and position_max to correctly position 0,0 on my print surface while still respecting the physical limitations of the machine.

Outputting the distance travelled during homing will remove the very manual process of moving the toolhead a fraction of a millimeter at a time while checking for a slip of paper being snagged by the toolhead against the ends of the machine.

Idempotency of the G10 and G11 commands is an important/key property of firmware-retract. It's what makes it so your start gcode can end in a retracted state (so it doesn't ooze and lose priming) even if your slicer (cough Cura) insists on performing its own retraction before the initial travel move, without getting a double-retract.

Maintaining statefulness of retraction after one print ends and before another begins is also important to keep filament retracted at the right point not to ooze or waste excess material priming the next print.

The changes in #83 make the former spam warnings, and completely break the latter by clearing retraction state after each print. They should be reverted and the system for introducing Z-hop re-thought not to break existing firmware-retraction semantics.

Alternative and more hacky solution to #111

M106 commands acting like a mixer where it mixes in something like aux fan at a certain point in the progression of the S param.

Slicers like Orca aux fan command is so very basic, for instance setting a fixed fan percentage starting from a fixed layer height. I think we could gain more value from it if it could act more like the cream on top of any toolhead fan.

I have recently been testing with a powerful vacuum fan for CPAP cooling. It works fine, there is just one issue: When suddenly increasing fan speed in large amounts, like going from 30% to 100% or so, the motor/ESC seems to cause short high-current spikes which make the PSU shutdown. The fan pulls ~110W on full power, however, a 250W PSU shuts down when increasing fan percentage in large steps.

This could be solved I think if one could configure a minimum fan spool-up time in Danger Klipper, for example, when a min spool-up time of 1 second is set in the config, and a gcode command makes the fan go from 30% to 100%, it will actually slowly increase the fanspeed PWM over a time of 0.7 seconds instead of instantly setting 100%.

Clock configuration on stm32h7 hardcodes a PLL_BASE of 5 MHz due to an implicit assumption that HSE is a 25 MHz crystal oscillator, which works for BTT Octopus Pro and Kraken boards. Unfortunately this breaks timing on boards without 25 MHz (e.g. Corevus-G v0.4 with a 12 MHz on HSE) — for example, all moves execute at 20% greater velocity, and more critically a clock frequency above 2^(32) / (10 s) = 429 MHz causes integer overflow errors.

I want to request a function/feature, where instead of having one set PA, It will have multiple the sharper the corner is.

For instance at 0-90 degree, it will be the standard PA, but the sharper the corner, like at 100-120-130 degree angle, it's so sharp, that it leaves a air gap between each line. To compensate for that, you add X amount of higher PA to fill that gap for that particular degree angle.

Use-case:
Allow Beacon to be used with default Dangerklipper

Problem:
Klippers/ Kevin most recent pull request had made clear Beacon may need a new home. Dangerklipper is the fork to do such.

Proposed Fix:
Add numpy for downloaders, then include beacons code.

During initial configuration one sometimes runs into issues where it would be desirable to disable the min/max temperature checks so that one could continue testing/troubleshooting during initial setup.

Some safeguards could additionally be put into place to safeguard against this potentially dangerous configuration. For example, the ability to start a print or to turn on heaters(possibly allowing heaters to run for a very brief period to verify wiring) could be disabled while this option flag is enabled.

I think there is an issue with Happy Hare (https://github.com/moggieuk/Happy-Hare) and Danger Klipper - klipper won't start as it looks like its not assigning the endstop to the stepper_mmu_gear. In the HH software you define pre and post extruder sensors and within it has code to assign them where they are used but I think that's failing somewhere in the code difference between mainline and DK.

I've taken a backup of my DK klipper directory so I can switch back if needed to help fault find.

MMU Hardware Initialization -------------------------------
Config error
Traceback (most recent call last):
  File "/home/reapola/klipper/klippy/klippy.py", line 265, in _connect
    self._read_config()
  File "/home/reapola/klipper/klippy/klippy.py", line 200, in _read_config
    self.load_object(config, section_config.get_name(), None)
  File "/home/reapola/klipper/klippy/klippy.py", line 184, in load_object
    self.objects[section] = init_func(config.getsection(section))
  File "/home/reapola/klipper/klippy/extras/mmu.py", line 6056, in load_config
    return Mmu(config)
  File "/home/reapola/klipper/klippy/extras/mmu.py", line 632, in __init__
    self._setup_mmu_hardware(config)
  File "/home/reapola/klipper/klippy/extras/mmu.py", line 645, in _setup_mmu_hardware
    self.mmu_toolhead = MmuToolHead(config, self.homing_extruder)
  File "/home/reapola/klipper/klippy/extras/mmu_toolhead.py", line 106, in __init__
    self.kin = MmuKinematics(self, config)
  File "/home/reapola/klipper/klippy/extras/mmu_toolhead.py", line 417, in __init__
    self.rails = [MmuLookupMultiRail(config.getsection('stepper_mmu_' + s), need_position_minmax=mm, default_position_endstop=0.) for a, s, mm in self.axes]
  File "/home/reapola/klipper/klippy/extras/mmu_toolhead.py", line 417, in <listcomp>
    self.rails = [MmuLookupMultiRail(config.getsection('stepper_mmu_' + s), need_position_minmax=mm, default_position_endstop=0.) for a, s, mm in self.axes]
  File "/home/reapola/klipper/klippy/extras/mmu_toolhead.py", line 627, in MmuLookupMultiRail
    rail = MmuPrinterRail(config, need_position_minmax=need_position_minmax, default_position_endstop=default_position_endstop, units_in_radians=units_in_radians)
  File "/home/reapola/klipper/klippy/extras/mmu_toolhead.py", line 555, in __init__
    super(MmuPrinterRail, self).__init__(config, **kwargs)
  File "/home/reapola/klipper/klippy/stepper.py", line 417, in __init__
    endstop_pin = config.get("endstop_pin")
  File "/home/reapola/klipper/klippy/configfile.py", line 85, in get
    return self._get_wrapper(
  File "/home/reapola/klipper/klippy/configfile.py", line 47, in _get_wrapper
    raise error(
configparser.Error: Option 'endstop_pin' in section 'stepper_mmu_gear' must be specified

There's another fork of Klipper which has added ADS1118 support, for use on Replicator 2 clones as a thermocouple amplifier.
I think it would be nice to have alongside #103, and the ADS1118 features a few key differences that make it more desirable for certain usecases over existing supported SPI Thermocouple chips.

Comparison between the TLA2518 a PR is up for, and the ADS1118:

• Both use SPI with a single ChipSelect pin rather than needing multiple I/O pins for each input
• Both can run off 3V3 or 5V
• TLA2518 is 12-bit, ADS1118 is 16-bit
• Sample Rate maxes out at 1000 per second on the TLA2518, compared to 860 on the ADS1118
• Price on Mouser:
  • TLA2518 is £3.53/e
  • ADS1118 is £4.39/e
• The ADS1118 can operate as Thermocouple input; The TLA2518 only accepts ADC inputs

I feel like the ADS1118 isn't particularly worth it for use as a regular ADC Thermistor input due to the extra cost and halving of inputs compared to the TLA2518, unless the extra bitrate makes it better despite lower sampling rate.

It does, however, seem to shine rather well as a Type-K thermocouple amplifier, being the amplifier of choice on various expensive printers.
In particular, its cheap. really. cheap.

The next two cheapest amplifier chips that Klipper supports are the AD8497 at £4.65/e, and the AD8495 at £6.59/e
Both of these chips come with major flaws.

• The AD8495 can only read upto 400c, not really enough for HT materials
• The AD8497 can only read upto 250c, barely enough for ASA

The ADS1118 can read up to 1,250c, Plenty enough for extremely high-temperature printing (god holy shit it better be wtf...), whilst being over £2 cheaper and easier to source than the next cheapest chip capable of over 500c- the MAX31855 for £6.67/e

"ok but pera the only boards using this are these randomass replicator clones"

I'm currently working on a mainboard that uses an ultra-cheap STM32 MCU and then has four slots for custom SPI modules, rather than "wasting" I/O on temperature inputs the user may not want.
I already have a design for the TLA2518, and had planned to make a module for a Thermocouple amplifier and a PT100 RTD. It'd be really nice if I can have that thermocouple amplifier be cheap as hell.
Added bonus is these modules should work on any machine with exposed SPI pins and I/O to use as CS, not just my mainboard.
I might design a board even if there isn't an active PR or dev work yet, idk yet

Log: https://discord.com/channels/1029426383614648421/1164249107938947084/1236886032184770610

This keeps happening during the second round of estimating z pivot points.
It seems like for first round it works fine.

It would be great to have an easy guide, just like adding using Kiauh, but for removing DK.

https://github.com/SnakeOilXY/klipper-extended-corexy-kinematic/blob/master/doc/homing.md

pls and ty

Has this ever happened to you?

"MCU 'mcu' shutdown: ADC out of range"

Well WHAT ADC???? You ask

Klipper says "ADC OUT OF RANGE"

So you go to the logs - sometimes, you can actually see the ADC that had the issue

Sometimes, its not captured, so you are just sitting there going "well wtf am i supposed to do now?"

Enter this feature request:

Please have klipper tell us what ADC it freaked out about so I can troubleshoot better without having to dig into the logs and the exact error.

As a bonus, have it tell us what the actual temperature it saw and what it thinks the limit is

Thank you.

On Klipper's Discourse that feature was requested as well, but the tone of the dialogue there indicates that it has a very slim chance of being implemented.

Prusa made available a library for the conversion from text to binary and from binary to text through the AGPL v3 license: https://github.com/prusa3d/libbgcode

Argument for this implementation:

• it dramatically reduce the file size of the g-code, making it possible to be transmitted faster while also occupying less space on the target printer.

Arguments against this implementation:

• only supported by PrusaSlicer right now;
  • counter-argument: this may not be the case in the near future, as popular forks like SuperSlicer and OrcaSlicer may implement this feature as well.
• make it impossible to read the g-code file to find possible errors;
  • counter-argument: humans reading g-code isn't a concern of Klipper, that should be handled by a GUI like Mainsail, Fluidd, or even OctoPrint.
• may need to implement some sort of error checking to ensure there wasn't any corruption of the file while being transmitted/stored.

Does anyone have another point to add to the discussion? I myself think this isn't absolutely necessary, more like a "nice to have" feature.

Sensorless homing is a bit tricky with high current low impedance motors (LDO 2804AH). I find they're most reliable when using the following steps, per axis:

1. Lower the run_current to the home_current
2. Home the axis
3. Back off 5mm
4. Raise the run_current back to the configured value
5. Back off the axis to a minimum of 0.5-1.0x the rotation distance (20-40mm in my case)

It would be nice if the good sensorless feature had an additional setting, such as sensorless_minimum_dist, that value could be compared to the distance moved as well (currently using homing_retract_dist).

Homing would then follow this process, per axis:

1. Lower the run_current to the home_current
2. Home the axis
3. Back off by homing_retract_dist
4. Raise the run_current back to the configured value
5. Back off the axis to the endstop position minus sensorless_minimum_dist
6. Check if the distance moved is at least sensorless_minimum_dist and re-home if required

I know many people who use the plugin and I think it would be a small yet great addition. This would just be an addition like belay and tradrack for example.

Here's a link to the repo

I like big prints, I cannot lie

When doing a tilt, the 3 points that are chosen form a plane, but they may not be the most representative of the total print area (make this dynamic for bonus points???)

My request is with the rapid adoption of beacon3d and its imitators, that klipper support a "quick mesh" option, generate a best fit plane off of that mesh, and then tilt the bed to fit that best fit mesh until variance from the baseline meets criteria. This allows the average deviation of the bed to be used instead of 3 ideally (but not always) representative points that may reduce z travel over very large prints with very large printers.

Thanks!

Luke

Currently the example pa test macro only uses a resolution of 0.005 for the tuning_tower factor. This value can of course be changed manually but it would be neat if the user could provide the macro with a pa value and a +/- value that is then used to print the test print for finer tuning.

As an example:
First the user would print the pa_test normally using a factor of 0.005.
After this print the user decides that a pa value of 0.025 is about right for his machine.
Now the user would run the script again but would set the new pa_value variable to 0.0025 and the +/- value to 0.1.
The macro would no print the pa test print but start the pa value at 0.015 (instead of 0) and use a factor of 0,00004 if the height of the pa test print was set to 50mm. Meaning when the print finishes the top layer would have a pa value of 0.035.

When developing complex macros, Klipper often has to be restarted for testing. This adds up to a lot of time. Especially when one needs to do things like homing every time before the macro can be tested.

To make macro development easier, it would be nice to have an ability to reload macros, e.g. by executing a command like RELOAD_MACROS.

TBD: should this reset gcode variables or not.

Resetting would give a clean slate for my own macros, and also handle the case of newly defined variables. But it would also reset the state of other macros (which I'm not working on), so it would modify the state of the printer.
I'm not sure which is the lesser evil.
Maybe being able to reload just the macros from one specific cfg file (including resetting variables) would solve this. Usually, when I work on macros, everything I'm working on is in the same file, so just reloading that would be fine.

Currently there isn't a "smart" error when using dual_carriage in corexy mode - it responds with the below:

Ideally, this would provide a more useful error message like "dual_carriage not compatible with currently selected kinematics system" prompting the user (like dum-dum me) to make sure they're trying to use it correctly.

I tried installing DangerKlipper (might have been BleedingEdge, not sure) on my Tridex, which is using the configuration files from this repo:
https://github.com/joseph-greiner/tridex_mods/tree/main/printer_configuration
Single extruder prints with either toolhead (let's call them T0 and T1) work as expected.
When I tried a dual extruder print, I noticed that T1's extruder motor was spinning in sync with T0's extruder motor, even though T0 was the "active" toolhead, and the T1 toolhead wasn't moving at all.
Conversely, when T1 is the "active" toolhead, although the toolhead moves through the XY motions of the layer being printed, its extruder motor doesn't spin at all, meaning that no filament is extruded except for a tiny bit of oozing.
Reverting the host and MCUs (a Pi 5, a BTT Kraken and two BTT EBB36s) back to stock Klipper resolved the issue and restored the expected IDEX functionality.
I have attached the GCODE file for the print, my printer configuration files for the Tridex, and a link to the video that demonstrates what I am talking about.
IDEX Issue with DK.zip
https://discord.com/channels/1029426383614648421/1164249107938947084/1249739604358070397

On mainline Klipper I'm able to set max_power: 0.95 on a [heater_fan], to reduce noise without much effect on heater performance. In Danger Kilpper however, I'm getting this error:

shutdown value must be 0.0 or 1.0 on soft pwm

This seems to be related to the fan speed normalization feature (#44), since I get that error even if I explicitly set shutdown_speed: 1.0. It's only with max_power: 1.0 that it doesn't error.

Not sure if this is intended or just an oversight, but IMO it doesn't make much sense to scale shutdown speed given it's purpose.

klippy.log