huge E movement on short move

[arhi]

OrcaSlicer Version

1.8.1

OS version

Win11

Additional system information

No response

Printer

SOVOL7PLUS

How to reproduce

right click - add primitive - orca cube, slice, print

Actual results

printer crash!

G-Code generated have invalid part. Looking at attached G-Code

; stop printing object OrcaCube id:2668126654464 copy 0
M106 S255
;LAYER_CHANGE
;Z:28.5
;HEIGHT:0.5
;BEFORE_LAYER_CHANGE
;G92 E0.0
;28.5


;WIPE_START
G1 F3416.595
G1 X163.245 Y160.074 E19.06126   ; 
M106 S68 ; 
G1 X163.245 Y159.302 E83.68531 ; ---------------> CRASH!!! 
;WIPE_END
G92 E0

So OS generated a move of 0.772mm in Y direction, X is staying still and extruder is to move 65mm in that time (156mm3 in 0.014 sec).

Expected results

no E moves that break the flow rate of the filament set in filament settings and no nonsence E moves, this makes no sense to pump this much plastic in .7mm of space

Project file & Debug log uploads

CRASH.gcode.zip

Checklist of files to include

• [x] Log file
• [x] Project file

[SoftFever]

Hi, Can you attach a project file? @igiannakas has improved the wipe logic to prevent this error. But your retraction length seem way too long so I want to double check

[igiannakas]

@SoftFever this is an interesting one as it doesn’t seem to be retracting while wiping but rather extruding 🤷🏻‍♂️

[SoftFever]

@SoftFever this is an interesting one as it doesn’t seem to be retracting while wiping but rather extruding 🤷🏻‍♂️

that's true.

~~Oh, I think I know. He is using absolute extrusion mode with G92 E0 command in layer change g-code. @arhi Please either remove G92 E0 in your layer change g-code or change to relative extrusion mode.~~

[igiannakas]

But doesn’t orca stopping slicing when g92 e0 is in the layer change gcode for absolute extrusion? 🤔

[SoftFever]

yeah, it's not that issue. Anyway, no point to guess for now until a sample project is attached.

[igiannakas]

True - I tried breaking the latest 1.9 with any edge condition you can imagine and couldn't get that to happen. Maybe it's fixed with the rework. Indeed, project would help a lot. @arhi please attach your project file to review and to check whether this is occurring in 1.9

[arhi]

Move exceeds maximum extrusion (201.137mm^2 vs 44.000mm^2)

not crashing any more as I fixed the printer config and put some sanity check but still tries to extrude a God through the nozzle :D

sorry for the delay... NY and all ...

Here is the project file OrcaCubeCRASHING.3mf.zip

[arhi]

@SoftFever attached, sorry for delay @igiannakas note that I have 1.8.1 on win11 and 1.8.1 on macos, this happens only from win11, when I slice on mac, same version, same project file, same everything the print goes through no problem, this "huge E" does not get generated!! dunno if that's usable info... I do not see anything other than 1.8.1 for version info, if there's a way to get some additional info I'll get it

[arhi]

I reproduced it on MAC too :( huge extrusion during WIPE .. not sure why would it try to push filament out during wipe ?! especially this much filament

...
;BEFORE_LAYER_CHANGE
;G92 E0.0
;22 

;WIPE_START
G1 F3559.99
G1 X136.967 Y173.087 E7.69158
M106 S204
M73 P60 R7
G1 X136.967 Y172.324 E32.40844  ; BUG!! 
;WIPE_END
G92 E0
;TIMELAPSE_TAKE_FRAME
;AFTER_LAYER_CHANGE
;22
...

mac1OrcaCube.gcode.zip

OrcaCube_mac_crashing_wipe_mm22.3mf.zip

[arhi]

btw is there a way to add to on_error some code to display g-code line number and content of that line to console?

[arhi]

@SoftFever change to relative extrusion mode.

I prefer relative extrusion mode myself but I'm just testing klipper for the first time (RRF/Smoothieboard mostly till now) so didn't want to change much, just put 0.8mm nozzle and increased few things to get it started to see how it works... when I have it working I'll move it to relative extrusion mode and I'll see if I can get both klipper and OS to have 0,0 in the middle of the bed :D

[arhi]

major changes from "default" (that worked for a while with .4mm nozzle)

• .8mm nozzle
• .95mm retraction
• .80-96mm line width
• .5mm layer height

[arhi]

tried now 1.9.0-beta same problem :(

52678: G1 X157.084 Y163.502 E1.03131
52680: G1 X157.143 Y164.24 E10.04082

so 9mm of filament into 1mm movement :(

probbly more places with that issue but this is the first one I found manually looking at g-code and again it is extruding instead of retracting filament during wipe

[arhi]

Move exceeds maximum extrusion (166.142mm^2 vs 44.000mm^2)

1.9.0-beta project bug-1.9.0-beta.3mf.zip

[igiannakas]

I've reproduced it. Will look into fixing it. In the mean time you can enable relative extrusion and add G92 E0.0 in the "after layer change" gcode section of your extruder.

[arhi]

will do thanks...

I found another issue, again huge E movement but now outside of WIPE

it is not as huge but retraction is 0.95mm and I see here E16 -> E10 -> E16 .. (almost no xy move) so 6mm retraction ?!?! (1.9-beta) If I reduce retraction to 0.5mm I get E15.6 -> E12.04 -> E15.77 so half but still order of magnitude more than configured ?!

Stanford_Bunny-61096line.3mf.zip

[arhi]

I've reproduced it. Will look into fixing it. In the mean time you can enable relative extrusion and add G92 E0.0 in the "after layer change" gcode section of your extruder.

great. do you think switching to relative would solve the problem? apart from G92E0 I assume I have to add M83 to the start code or OS will add that automatically ?

[igiannakas]

OK made some progress de bugging this.

This is caused by the fan kick start time. If you set it to 0 the issue goes away. If you set it to 0.1 the deretraction is even worse.

@SoftFever haven't debugged the code yet, but making some progress.

@arhi disable your fan kick start time for now and check again please.

[arhi]

@igiannakas :D I am not even using a fan :D :D :D no clue why is that set at all will try in a minute thanks ... you want me to test 1.9.0-beta or 1.8.1 ?

[igiannakas]

Please test with both - this should work with both versions and report back :)

[arhi]

1.8.1 on win11 - when I set fan speed-up time and fan kick-start time to 0 produced G-code that worked flawlesly

testing 1.9.0-beta arm64 now

[arhi]

1.9.0-beta finished ok after speed-up time and fan kick-start time are set to 0

So this is a good workaround for the problem :D

[igiannakas]

@SoftFever failed to wrap my head around the fan kick start code I’m afraid. I’ve also seen some funny things going on with it when doing color changes on the BBL. Should this function be renamed to experimental?

[SoftFever]

I can't repro it with the latest release build. I'm not sure whether my numeric error related fixes worked. Can you help me verify it? This is the latest build: https://github.com/SoftFever/OrcaSlicer/actions/runs/7409323725

[igiannakas]

I can't repro it with the latest release build. I'm not sure whether my numeric error related fixes worked. Can you help me verify it? This is the latest build: https://github.com/SoftFever/OrcaSlicer/actions/runs/7409323725

Yeap of course:

Check layer 44 & 43 at the end of the layer:

This is with the build above + the attached project file. bug.3mf.zip

[igiannakas]

If I disable fan kick start time, working as expected.:

[igiannakas]

I think the path split routine for fan kick start is messing the wipe move up - it tries to split it up I think and sets the wrong extrusion value.

[SoftFever]

I think the path split routine for fan kick start is messing the wipe move up - it tries to split it up I think and sets the wrong extrusion value.

Yes, need to revisit this feature. It has caused quite a lot of trouble according to the feedback I've received.

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.