Move exceeds maximum extrusion

[antonyburden]

Since trying the last dev2 builds I occasionally get errors like this:

"Move exceeds maximum extrusion (4.980mm^2 vs 0.640mm^2)"

Did hundreds of prints with dev1 and never had this issue. nothing changed my end.

I am using Klipper and latest PrusaSlicer 2.3.0 Beta 3

Had the error with the Stable release of PS too, so I don't think it's a beta thing.

[FormerLurker]

Can you post the exact version listed in the arcwelder tab as well as the source and target gcode please? Thanks!

[antonyburden]

Thanks - here you go:

Arc Welder v1.0.1rc1.dev2+u.8964fbe

move_exceeds_max_extrusion.zip

[FormerLurker]

Thanks! I see you are using the latest devel branch code (minus one push for exception handling, which is fine). Brave soul :)

One other thing that would help immensely is knowing which line of gcode triggered the error you referenced. Otherwise I'll have to find some way to trigger it myself (I don't have the ability to run klipper ATM), which will probably take a custom program to detect. This could probably be extracted from the octoprint terminal or by a full serial log, but if you don't have it already you would have to re-print the offending gcode. I know that would be a pain, but it would take a lot less time than if I have to examine every line of gcode in the file :)

[antonyburden]

I tried the latest, in hope you had fixed it ;-)

No worries, I will get it printing without any filament, happened about 20 mins in or so, so once my current print has finished I will get to doing it.

[FormerLurker]

Awesome! FYI, I have heard others say klipper may not be calculating the volumetric flow for arc commands properly in all cases, but maybe it's ArcWelder. Typically it's been like 75/25 firmware issues to arc welder issues (more if I count arcs being disabled as a firmware issue, lol)

[antonyburden]

Ok, this is weird. It actually stopped at the end of the gcode - but it's no where near the end of the original non-arc'd print - only 2.8mm in out of 31.5mm

Line 138755 G1 X114.648 Y125.188 E0.01941 @Objectstop octopus4_smooth.stl id:0 copy 0

[FormerLurker]

What does @Objectstop octopus4_smooth.stl id:0 copy 0 do? Is it a coincidence that it had issues right before that line, or is it somehow contributing.

but it's no where near the end of the original non-arc'd print

You mean you got that error message for line 138755, but it had stopped printing well before this (like many layers)? That doesn't make much sense at all.

I don't know what @Objectstop is doing, but I would assume it has something to do with canceling objects?? I would try removing that plugin/event and re-testing. Perhaps it is an incompatibility with some other plugin. It would make at least some sense if all the prior gcode lines were skipped after some point, though I'm struggling to understand why you would get the specific error you reported, unless by amazing coincidence your printer was setting almost exactly at point X114.648 Y125.188, skipped many lines, then hit that G1 command you pasted in such that the length traveled (would have to be VERY short) violated the maximum extrusion setting in klipper.

[antonyburden]

Its in all my gcodes, even successful aw gcode, if you look at the aw code I sent, that’s the last line of Gcode movement commands before all the normal end stuff. Aw has just stopped at 2.8mm for some reason.

[antonyburden]

I disabled the cancel object plugin - the line now reads ; stop printing object octopus4_smooth.stl id:0 copy 0 Anyway, it looks like it's going wrong then skipping all the way to the end. Going to let it run empty again with the aw gcode minus the plugin.

[antonyburden]

Think my previous report had the terminal buffer stopped because I never had autoscroll on. so ignore the above - this is where it goes wrong:

Send: N59378 G1 X143.659 Y112.89139 Recv: ok Send: N59379 G1 X143.779 Y112.93344 Recv: ok Send: N59380 G1 X144.091 Y113.04840 Recv: ok Send: N59381 G1 X144.390 Y113.16537 Recv: ok Send: N59382 G1 X144.606 Y113.25342 Recv: ok Send: N59383 G1 X144.678 Y113.28246 Recv: ok Send: N59384 G1 X144.956 Y113.40434 Recv: ok Send: N59385 G1 X145.223 Y113.53247 Recv: ok Send: N59386 G1 X145.446 Y113.64641 Recv: ok Send: N59387 G1 X145.483 Y113.66635 Recv: ok Send: N59388 G1 X145.703 Y113.78939 Recv: ok Send: N59389 G1 X145.731 Y113.80544 Recv: ok Send: N59390 G1 X145.972 Y113.95347 Recv: ok Send: N59391 G1 X163.623 Y124.86339 Recv: ok Send: N59392 G1 X172.297 Y119.06935 Recv: ok Send: N59393 G1 X170.639 Y111.91146 Recv: ok Send: N59394 G1 F1200.00081 Recv: ok Send: N59395 G3 X170.672 Y111.961 I-5.947 J3.961 E0.1240365 Recv: // Move exceeds maximum extrusion (4.980mm^2 vs 0.640mm^2) Recv: // See the 'max_extrude_cross_section' config option for details Recv: !! Move exceeds maximum extrusion (4.980mm^2 vs 0.640mm^2) Changing monitoring state from "Printing" to "Cancelling" Send: N59396 M8431 Recv: ok Send: N59397 M104 T0 S032 Recv: ok Recv: ok Send: N59398 M140 S0107 Recv: ok Send: N59399 M106 S0104 Recv: ok Changing monitoring state from "Cancelling" to "Operational"

the line before the error is

G3 X170.672 Y111.961 I-5.947 J3.961 E0.12403

which is at line 63962 of the attached aw.gcode

test.aw.zip

[FormerLurker]

OK, I know what's happening, but I must say the slicer code there looks very suspicious. Will post back when I have a bit more time.

[FormerLurker]

Hey, quick thought, can you take a snapshot of your 'Preprocessor' settings for Arc Welder and paste them in:

It's possible that the path tolerance percentage is too high.

[antonyburden]

[FormerLurker]

This is very mysterious. I'm suspecting some math library issue. Will get back to this tomorrow and spend some time figuring out what is going on.

[FormerLurker]

OK, sorry this took so long. Got stuck working on an end of year project (december is always crazy for me), but finally finished and solved this problem. There were several issues I fixed, but the primary one causing your issue was the fact that I was not converting the percentages (for example 5%) to a decimal percent (0.05) for the path tolerance percent! I know this was working earlier, so I must have broken it during a recent refactor. Whoops.

Anyway, before I discovered the path tolerance conversion issue, I added a few more safety mechanisms to prevent the problem you were seeing. The first was arc direction detection change and prevention. Basically if an arc passes all the other safety tests (length tolerance, resolution, etc..), I also check to make sure the direction stays consistent across the whole arc. I think there is actually a limitation with the current implementation of this check that I'm working now to resolve, but I believe the main issue has been corrected.

You can test the fix by installing from this link: https://github.com/FormerLurker/ArcWelderPlugin/archive/e7e7d46e86d4f5c6ba77022f5e26a0511942260b.zip

Let me know how it goes. I'm going to work to fix the direction change testing and will post back when I feel that's working as well. Thanks!

[FormerLurker]

@antonyburden, I also added one final bit of code to completely eliminate this issue (hopefully), even if the path tolerance percent is cranked way up. In fact, for my tests I increased the value to 10,000%, and it still produced arcs correctly, even in the odd gcode you submitted.

In addition to the direction safety mechanism, I also added a final check to ensure that no segment of the original gcode path is allowed to cross into the space not occupied by the arc. This was the final sauce needed to generate arcs correctly in all cases, even when the original gcode path is suspect (100% overlap in your case). I've actually been working on this since last May, but only now was able to figure out why my previous attempts have been less than successful. I'm pushing out another devel/rc in a bit that contains this enhancement.

[antonyburden]

Thanks for the updates - back to being on PC now Christmas is over, will get to testing now.

[Z0333]

hi, i have the same problem. these are the gcodes 5X .95 LECH.zip

i'm using 1.0.0+u.bb71e8f with default settings.

thanks :)

[FormerLurker]

OK, so I added some additional checks to ensure extrusion is correct in odd cases. Perhaps try installing from this latest devel build via the plugin manager (Octoprint settings->Plugin Manger->Get More->From Url...):

https://github.com/FormerLurker/ArcWelderPlugin/archive/devel.zip

Please try running the exact same gcode file through arc welder, print the result, and let me know how it goes! Fingers crossed :)

[cmroche]

@FormerLurker I had the same issue, I can confirm that it's working now on the devel package.

[FormerLurker]

Thanks, excellent!

[cmroche]

I found a new case, though most of my prints have worked this one fails

Send: N43661 G1 X147.902 Y114.831 E-0.14948*78
Recv: ok
Send: N43662 G1 X148.208 Y114.831 E-0.09100*75
Recv: ok
Send: N43663 G1 E-0.07000 F2700.00000*48
Recv: ok
Send: N43664 G1 Z10.650000 F10800.000*60
Recv: ok
Send: N43665 G1 X162.698 Y115.151*41
Recv: ok
Send: N43666 G1 Z10.050000*121
Recv: ok
Send: N43667 G1 E1.40000 F600.00000*40
Recv: ok
Send: N43668 G1 F1500.000*91
Recv: ok
Send: N43669 M204 S800*96
Recv: ok
Send: N43670 G1 X168.640 Y115.152 E0.44141*110
Recv: ok
[...]
Send: N43672 G2 X168.870 Y115.152 I6.057 J-18337.012 E0.46304*68
Recv: // Move exceeds maximum extrusion (4.842mm^2 vs 1.440mm^2)
Recv: // See the 'max_extrude_cross_section' config option for details
Recv: !! Move exceeds maximum extrusion (4.842mm^2 vs 1.440mm^2)
Changing monitoring state from "Printing" to "Cancelling"

test.zip

[FormerLurker]

Have you updated to the latest beta? I did quash a decent sized bug 🪲

[cmroche]

I updated to the latest release on the dev branch before re-running and confirming (this morning).

[FormerLurker]

Ok, thx. Will fix this asap

[ilium007]

Is this fixed in v1.1.1 on OSX? I just downloaded and got the max_extrude_cross_section error on first print.

*oops - I am using arcwelderlib not this code. Obviously the issue is over there.

[john-parton]

Commented in the other issue. I still got this running latest Cura and plugin.