Klipper: Move exceeds maximum extrusion (8124319918345161.000mm^2 vs 0.640mm^2)

[ArmyAg08]

A print failed early on with the error "Move exceeds maximum extrusion (8124319918345161.000mm^2 vs 0.640mm^2)". This happens somewhat frequently and can usually be fixed by shifting the model slightly and re-slicing. Sometimes I'll have to print fewer parts at a time to resolve. This looks similar to a few other issues that were closed recently but I have a log file attached below. Please let me know if you'd like any more information.

klippy.log

[ArmyAg08]

Here is a new log with the gcode file I attempted to run.

klippy.log
PI3_cable_chain_x40.txt

[KevinOConnor]

This appears to be a bug in how Klipper handles bed_tilt transformations - it seems that after a transformation update an extrude only move can appear as an extruding move with an infinitesimal amount of XYZ movement.

I need to think a bit on how to fix this.

As a short term workaround, I think adding a "G1" command without any extrusion immediately after your bed_tilt_calibrate command should avoid this.

-Kevin

[ArmyAg08]

Thanks for the quick feedback. I will give this a try in my next print and let you know how it works.

[ArmyAg08]

I added just a G1 after BED_TILT_CALIBRATE on a file that failed. This workaround appears to have worked for now. I will update if I see the issue again.

[tonhozi]

I had the same problem but was not able to get the klipper.log on time. I did got the log from octoprint though:

2018-07-19 20:23:21,281 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: Move exceeds maximum extrusion (25.845mm^2 vs 0.640mm^2)
| Last lines in terminal:
| Send: N715993 G1 X140.929 Y96.115 F2700*71
| Recv: ok
| Send: N715994 G92 E0*112
| Recv: ok
| Send: N715995 G1 E-6.5000 F5100*41
| Recv: ok
| Send: N715996 G1 Z72.800 F1002*17
| Recv: ok
| Send: N715997 G1 X119.958 Y81.397 F7200*71
| Recv: ok
| Send: N715998 G1 Z72.400 F1002*19
| Recv: ok
| Send: N715999 G1 E-0.1000 F5100*39
| Recv: ok
| Send: N716000 G92 E0*119
| Recv: ok
| Send: N716001 G1 X119.955 Y81.178 E2.3534 F2700*52
| Recv: // Move exceeds maximum extrusion (25.845mm^2 vs 0.640mm^2)
| Recv: // See the 'max_extrude_cross_section' config option for details
| Recv: !! Move exceeds maximum extrusion (25.845mm^2 vs 0.640mm^2)
2018-07-19 20:23:21,287 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Cancelling"

[tonhozi]

Some more details. Sliced on Simplify3D. I will not attach the whole g-code because it is 60mb. It failed after 07:20:41 printing. OctoPrint 1.3.9rc3 running on OctoPi 0.15.0.

Printer CR-10s 2017

`===== Config file =====
[stepper_x]
step_pin = ar54
dir_pin = ar55
enable_pin = !ar38
step_distance = .0125
endstop_pin = ^ar3
position_endstop = 0
position_max = 300
homing_speed = 50

[stepper_y]
step_pin = ar60
dir_pin = ar61
enable_pin = !ar56
step_distance = .0125
endstop_pin = ^ar14
position_endstop = 0
position_max = 300
homing_speed = 50

[stepper_z]
step_pin = ar46
dir_pin = !ar48
enable_pin = !ar62
step_distance = .0025
endstop_pin = ^ar18
position_endstop = 0.5
position_max = 400

[extruder]
step_pin = ar26
dir_pin = ar28
enable_pin = !ar24
step_distance = .010526
nozzle_diameter = 0.400
filament_diameter = 1.750
heater_pin = ar10
sensor_type = EPCOS 100K B57560G104F
sensor_pin = analog13
control = pid
pid_kp = 23.628
pid_ki = 1.010
pid_kd = 138.221
min_temp = 0
max_temp = 250

[heater_bed]
heater_pin = ar8
sensor_type = EPCOS 100K B57560G104F
sensor_pin = analog14
control = pid
pid_kp = 74.497
pid_ki = 1.245
pid_kd = 1114.655
min_temp = 0
max_temp = 100

[fan]
pin = ar9

[mcu]
serial = /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06OJ0F-if00-port0
pin_map = arduino

[printer]
kinematics = cartesian
max_velocity = 300
max_accel = 3000
max_z_velocity = 5
max_z_accel = 100

[display]
lcd_type = st7920
cs_pin = ar16
sclk_pin = ar23
sid_pin = ar17

=======================
Configured MCU 'mcu' (633 moves)
Loaded MCU 'mcu' 66 commands (v0.6.0-271-g244d0aa-20180714_154735-octopi / gcc: (GCC) 5.4.0 binutils: (GNU Binutils) 2.26.20160125)
MCU 'mcu' config: RECEIVE_WINDOW=192 SOFT_PWM_MAX=256 SERIAL_BAUD=250000 ADC_MAX=1023 PWM_MAX=255 CLOCK_FREQ=16000000 MCU=atmega2560 STATS_SUMSQ_BASE=256
Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/printer.cfg', '-l', '/tmp/klippy.log']
Git version: 'v0.6.0-271-g244d0aa'
CPU: 4 core ARMv7 Processor rev 4 (v7l)
Python: '2.7.13 (default, Nov 24 2017, 17:33:09) \n[GCC 6.3.0 20170516]'`

[KevinOConnor]

On Fri, Jul 20, 2018 at 07:48:32AM -0700, Pedro Tonhozi wrote:

| Send: N715997 G1 X119.958 Y81.397 F720071
| Send: N715998 G1 Z72.400 F100219
| Send: N715999 G1 E-0.1000 F510039
| Send: N716000 G92 E0119
| Send: N716001 G1 X119.955 Y81.178 E2.3534 F2700*52
| Recv: // Move exceeds maximum extrusion (25.845mm^2 vs 0.640mm^2)
| Recv: // See the 'max_extrude_cross_section' config option for details
| Recv: !! Move exceeds maximum extrusion (25.845mm^2 vs 0.640mm^2)

This is not related to this issue. (The error raised in this issue is
specific to configs with a bed_tilt and a particular series of
commands.)

The above indicates there is a bug in the slicer that generated the
g-code. The last G1 commanded the printer to move .219mm while
extruding 2.3534mm of filament - that's a bad request.

-Kevin

[alfsoft]

MODULAR_E3D_DUCT_7.14.gcode.txt
octoprint.log
printer.cfg.txt

_Move exceeds maximum extrusion (4.308mm^2 vs 0.640mm^2) See the 'max_extrude_cross_section' config option for details_
Same happened to me twice. Attaching the second failed file for your investigation. Error is triggering on layer 113 on bridging part. First time this also happened on bridging. Maybe there's a way to ignore this kind of errors and only restrict extrusion to maximum available so the print could continue?

[AxMod3DPrint]

@alfsoft please provide your klippy.log as described in https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md so we can help you further.

[alfsoft]

@AxMod3DPrint,
klippy.log

[alfsoft]

Temporarily solved my issue by altering klipper/klippy/kinematics/extruder.py like this:

elif move.extrude_r > self.max_extrude_ratio:
            if move.axes_d[3] <= self.nozzle_diameter * self.max_extrude_ratio:
                # Permit extrusion if amount extruded is tiny
                move.extrude_r = self.max_extrude_ratio
                return
            area = move.axes_d[3] * self.filament_area / move.move_d
            logging.debug("Overextrude: %s vs %s (area=%.3f dist=%.3f)",
                          move.extrude_r, self.max_extrude_ratio,
                          area, move.move_d)
            move.extrude_r = self.max_extrude_ratio
            #raise homing.EndstopError(
            #    "Move exceeds maximum extrusion (%.3fmm^2 vs %.3fmm^2)\n"
            #    "See the 'max_extrude_cross_section' config option for details"
            #    % (area, self.max_extrude_ratio * self.filament_area))

(Commented out Error raising and inserted "move.extrude_r = self.max_extrude_ratio" above this line).
So far so good. The same file is printing now successfully and that bridging part printed completely normal. Maybe it is a good idea to teach Klipper to handle some stupid slicing errors and fix them on the fly?

[KevinOConnor]

@alfsoft - your issue is not related to this github issue. Your issue appears to be the slicer doing something quirky (extruding a significant amount with only a small head movement). You can work around it by increasing max_extrude_cross_section or by changing the settings of the slicer. (In particular, don't use "coasting" with Klipper - it wont do what you want it to do - use Klipper's pressure advance instead.)

[alfsoft]

Decided to try to print the same g-code, but only the bridging part with maximum extrusion check commeted and now there's another error happened when bridging was almost done: "_Heater extruder not heating at expected rate_". So simply disabling extrusion check did not work as I expected.
klippy.log
octoprint.log
MODULAR_E3D_DUCT_7.14TEST.gcode.txt

@KevinOConnor - going to try another slicer then, I guess. What value do you suggest for max_extrude_cross_section?

[alfsoft]

Tried this:

1. Disabled coasting in slicer settings and tried to print. Got "Move exceeds maximum extrusion".
2. Disabled coasting and increased max_extrude_cross_section to 64.0. Got brand new error "Rescheduled timer in the past".

Attaching klippy.log

[jakep82]

I've run into similar issues with Simplify3D. It's why I stopped using it. It regularly produces gcode with errors. Marlin will generally ignore the bad gcode, but Klipper will produce errors. I don't see these issues with Slic3r PE.

[alfsoft]

@jakep82 Thanks. Will try to fine-tune Slic3r like I did with beloved S3D. Too much effort was put in tweaking both S3D and Klipper. If I will not like Slic3r, I think, I have found a solution for skipping both "Heater extruder not heating at expected rate" and "Move exceeds maximum extrusion" errors. Well, at least my file was printed just now. I did two things:

1. Modified extruder.py
2. Lowered bridging fan speed from 100% to 30-40% in slicer. So now extruder is heating _at expected rate_.

Maybe I am repeating myself, but that would be a great option to enable bad gcode skipping/fixing in Klipper. That should definitely make it much user-friendly.

[jakep82]

I like that Klipper prevents my printer from trying to do things that could be bad. I would rather complain to S3D about it since I paid them a bunch of money for software that produces bad gcode. The fact that Marlin will ignore this stuff has made them lazy about fixing problems in their software.

[KevinOConnor]

@alfsoft - the issue you've raised is not related to this github issue. If you're looking for assistance, please open a new github issue and follow the directions at: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

[KevinOConnor]

I think this should be fixed now (commit 4573932f).

-Kevin

[ArmyAg08]

Thanks @KevinOConnor I will update soon and see if I encounter the issue again.

[ramsesiden]

Hello Im trying to resume a failed print, and Im receiving this same error when I send to print the modified gcode,
is it possible in Cura and Klipper as I usually did in Cura and Marlin?