Dynamic Overhang causing 'Invalid speed in 'G1 F0"' in Klipper

[stevenscatina]

Description of the bug

Under Print Settings>Speed>Dynamic Overhang Speed when setting the speed for 0% overlap to 0 (with the intention of turning that option off and defaulting to the bridge setting) it instead writes a F0 speed into the gcode. This causes Klipper to report "Invalid speed in 'G1 F0'" and cancel the print when it reaches the first trigger of that overhang setting. Changing that setting to a number rather than 0 allows it to print normally.

Project file & How to reproduce

3DBenchy_Prusa_2.6.0.a5_bug.3mf.zip

Project file included, sliced for a LDO Voron 2.4 300mm kit printer.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.6.0-alpha5

Operating system

Windows 11

Printer model

voron 2.4 with stealthburner

[coolva]

I have just hit this issue myself.

[zeminfmok]

Yes me too

[windischadrian]

PrusaSlicer/src/libslic3r/GCode
/ExtrusionProcessor.hpp

    float                  speed_base = ext_perimeter_speed > 0 ? ext_perimeter_speed : original_speed;

Perhaps a float value of 0.01 would be > 0 but klipper / gcode sees it as F0? I know it's a common issue when comparing floats to 0.

My thoughts were about minimum layer time combined with overhang speeds

[EklDuderino]

I just ran into this issue with Prusa slicer 2.6 stable. Hundreds of hours with no problem on 2.6 and klipper. Any updates on this problem and how to avoid?

[suprchunk]

An hour into one today, and I just got this. I do not have dynamic overhangs off though, all my setting in that section are at 30mm/s.

I'm on:
Version 2.6.1+win64

[suprchunk]

Another hour into a print, first layer, and this shoots up again!!!

[Trogdor04]

I consistently run into this, any movement on this issue?

[GavinHanson]

Also seeing this issue :( really annoying!

[Manasx100]

Setting first layer speed to a value other than 0 solved it for me
Edit: Meant to say this solved it for me so if you can't find a solution and want to print try this if the other solutions didn't help

[64bitcube]

I'm having this issue as well. Slicer 2.7.1. It's popping up at layer 395 of a lithopane, and it occurs 34 times in that layer, but only that layer. I sliced 5 different models on the same settings, but only this one gcode had the error.

Perhaps a float value of 0.01 would be > 0 but klipper / gcode sees it as F0? I know it's a common issue when comparing floats to 0.

I assume I understand what your saying, but I want to point out that the gcode itself does say f0, not F0.01.

My first layer speed is not set to 0 (it's 30mms), so that's not a solution either.

I resliced it on the same settings just to confirm, and the gcode came out identical with g1 f0 present.

Reslicing after disabling dynamic overhangs did solve the issue, and g1 f0 is no longer present. I may play around later to see if there are other solutions, but for now I just need this print to be done, haha.

[numanair]

Ramping z-hop is causing this as well.

[lukasmatena]

Please, can at least some of you include a 3MF to allow me to reproduce the problem? I simply don't see the problem in the one and only 3MF that has so far been posted, and I was unable to find the combination of settings which would cause it. Thanks.

[64bitcube]

Sure. I've zipped both an isolated version of my project .3mf and a recompile of the gcode I did today (checked, the 'g1 f0's are still present as I described previously).

To confirm, I am running PS 2.7.1 on windows 10. Let me know if you need any other details.

Error Lithopane Project.zip

[lukasmatena]

Thanks.

Could you all please test it with 2.7.2-alpha2? There was a bugfix related to dynamic overhangs and it appears that the change also fixed this problem.

[okovjogurtu]

PS 2.7.2 - alpha2 - running on linux.
Problem occurs on Voron
Invalid speed in 'G1 X150.781 Y156.678 Z.45 F0'
Looks like this is on ZHOP

[lukasmatena]

@okovjogurtu It is difficult to say, because your report again doesn't include a 3MF to check. But is sounds like #12293, which is an independent problem, solved in the just released 2.7.2-beta1.

[okovjogurtu]

@lukasmatena Lukas you're right, sorry - my mistake, problem was #12293 and 2.7.2-beta1 solved my issue. Thank you