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

[Peej11]

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

[Peej11]

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

[Peej11]

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

[Peej11]

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_crosssection' 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?

[ViperWorx]

@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

[Peej11]

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?