Cancelling object leads to excessive retraction, which causes Klipper to fail the entire print
NameOfTheDragon opened this issue · 10 comments
Note: I tried to bring this up on the Octoprint forum, but despite insisting on me giving "as much information as possible" I was prevented from posting because "new users can only post one image" :( I'm pretty sure it's a bug anyway (I'm a software developer), so here we are.
Problem: Print failed because Klipper detected a "large retraction" after using Cancel Objects
Print suddenly stopped. Klipper reports "Extrude only move too long" and there is an unreasonably massive retraction in the GCode (which isn't in the original GCode file)
What did you already try to solve it?
I tried unsuccessfully to post on the Octoprint forum.
Logs
octoprint.log
plugin_cancelobject_cancelobject.log
serial.log
Problem occurred at 2020-06-18@21:35:00 give or take 1 second
Terminal output leading up to the error is as follows.
GCode downloaded from Octoprint.zip
The GCode file (downloaded from Octoprint) does not seem to contain this instruction so it must have been inserted by a plugin. The line numbers don't exactly match but this seems to correspond to line 47375 in the linked GCode file.
Prior to this, I had used "Cancel Objects" to cancel printing two of the objects on the build plate as they had detached from the bed. The nozzle is stopped over the position where one of the detached objects would have been, so I suspect this might be a smoking gun.
In this screen snipping of the Prusa Slicer thumbnail image, I have marked the two cancelled objects in red. The upper one is where the print head stopped, after just finishing the object behind it on the bed.
This photo of the print bed shows where the print head stopped, over the blank space where the cancelled object would have been if it handn't been knocked off the bed:
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
Creality Ender-3 kinematics
BTT SKR Mini E3 mainboard running Klipper firmware
First, you should set PrusaSlicer to use relative extrusion, not absolute. The instruction is from your firmware, and there has been no testing with this plugin using Klipper.
As one software developer to another, that seems like a weak response if you don't mind me saying. I'm sorry but it won't wash to tell me that my slicer configuration is wrong. The GCode is well-formed and it should have worked. Relative or absolute extrusion seems irrelevant, and this problem is upstream of the firmware so testing with Klipper is also irrelevant. Marlin would probably have choked on this just as badly. The problem is that there was a ~600mm retraction that was not in the GCode, which came from Octoprint not from the firmware or the slicer, which would have unloaded the filament several times over. Klipper correctly caught this bad input and prevented it from happening.
I've gone to a lot of trouble to provide a very detailed bug report, and it is very disheartening to receive a dismissive reply that seems to be based on seeing the word "Klipper" in the title. I don't know if I caught you at a bad moment (I certainly have them) but I'd appreciate it if you would at least justify my effort with an attempt to look into the issue rather than trying to blame other software.
It is relevant and the plugin clearly says it recommends relative instead of absolute extrusion. It is not a 600 mm retraction, it is a missed reset of the extrusion distance when using absolute extrusion. The plugin/firmware/serila comms or something missed the G92 EXXX to reset the extrusion. This is the reason why I recommend relative extrusion. I appreciate your effort in your bug report. It was detailed and provided necessary information. However, as I do not run any klipper setups, I cannot run any tests that will be beneficial to you. If you want to be helpful to the community, try it with relative extrusion and report the results.
Hi,
I am also trying to get this to work with Klipper. For anyone who has tried it, is this what my END_PRINT macro should look like in terms of putting in the ; process ENDGCODE?
[gcode_macro END_PRINT]
gcode:
; process ENDGCODE
# Turn off bed, extruder, and fan
M140 S0
M104 S0
M106 S0
G91
# Raise nozzle by 10mm while retracting
G1 Z10 E-6 F3000
G90
# Disable steppers
M84
# Add a command here to disconnect the mcu from host
# PSU OFF
M81
@DroneMang Note that this issue relates to the Cancel Object plugin, not cancelling the entire print job. The end gcode therefore shouldn't have any bearing on that.
@paukstelis I do not believe that Klipper has any bearing on this at all. Prusa Slicer doesn't know I'm using Klipper and it produces gcode that is compatible with Marlin. Furthermore, I think the plugin really should work with the default gcode produced by most slicers, and they nearly all use absolute extrusion by default.
Your assertion appears to be that some other part of the system is "missing" the extruder reset. Respectfully, I disagree; you're just putting up smoke screens. I've provided you with the full serial log that shows exactly what was sent to the firmware, so we have no need to speculate about this. The reset was never sent, because it was filtered out by the plugin. That's a bug.
If I'm wrong, then I apologize, but I don't think I am. Just point me to the evidence that the plugin didn't cause this and we can close the issue and I'll go away.
The G92 should have been injected by the plugin. It wasn't filtered by the plugin. I suspect there are issues with how octoprint does command injects, which is again one of the reasons why I recommend relative over absolute extrusion. I was never able to observe inconsistent behavior on my systems, but others reported inconsistencies with absolute extrusions. If I can't reproduce a bug, how can I fix it? No smoke screens, just no way to help you. Have you even tried with relative extrusions to see if it works? It is one box to check in PrusaSlicer. Also, most systems use relative, not absolute extrusion these days (all of Prusa's stock profiles included).
The serial log you provided is not particularly helpful (did you even look at it?). If you really want to figure this out:
- Test relative extrusion
- Use a test setup for absolute extrusion that you can consistently show an issue.
I just cancelled an object on my setup, using relative extrusion which led to the printer jumping about appearing to complete cancelled steps in mid air without extruding. By the time I had looked at the printer again, the filament had completely unloaded, and a glance in the side showed with every jump it was retracting more and more.
No log to show for it as i've had some unrelated issues with octoprint today, but just throwing in my 2c, that this happens relative too, and on Marlin.
Please provide gcode. This sounds most like you are using coasting+retraction with either Prusaslicer or Superslicer. For whatever reason those slicers have chosen to place the coasting movements outside of the object movements. I could see that leading to unloading if it it does not properly unretract on the next object, or you cancel many objects in a row.