Invalid speed message - Githubissues

smoth90 commented 6 years ago

in some prints occur this error:

Invalid speed in 'N83153 G1 X91.804 Y129.181 E-6.5000 F0*16'

in attach you can find the gcode and the log file. the gcode has been sliced with Simplify3d, now i will try with slic3r but i don't think that is related to a slicer program. klippy.log

PP-YBBSB.zip

lucashpandolfo commented 6 years ago

That's because it's trying to move the toolhead with 0 feedrate.

smoth90 commented 6 years ago

yes, i think it's like a wipe movement, i don't think it's wrong to perform a move toolhead with 0 feedrate

lucashpandolfo commented 6 years ago

Well, the thing is, the line G1 X91.804 Y129.181 E-6.5000 F0 means something like move the toolhead to X91.804 Y129.181 (retracting 6.5mm of filament) with a zero speed. You can't move te toolhead with a 0 speed.

That being said, I think there should be an option to ignore this kind of silly errors (I have also seen negative feedrates in gcode files generated by slic3r) and continue the print at your own risk.

smoth90 commented 6 years ago

i agree, i don't know why s3d write that line, it's nonsense

lucashpandolfo commented 6 years ago

Hmm, maybe, just maybe... It's not a wipe movement, but a static retraction '''movement'''. So the toolhead is already at X91.804 Y129.181 and no toolhead movement is involved at all, just a retract. Reading the gcode file, I find that wipe while retract is enabled, so don't think it's a static retract.

Looks like that line is part of a 'gap-fill' section, and it reads

G1 X91.804 Y129.181 F9000
G92 E0
G92 E0
G1 X91.804 Y129.181 E-6.5000 F0

So, yeah. The toolhead is already at those coordinates and it's kind of performing a static retract. Maybe klipper could allow this kind of things (0 speed) if the toolhead is already there?

jakep82 commented 6 years ago

I don't think Klipper should be trying to fix bad gcode by making guesses about what should happen. Even if the toolhead is already at the location, the extruder needs a valid speed to retract the filament. This looks like a bug in S3D that needs to be addressed by them.

I should also note I recently had a gcode file sliced by S3D that failed part way into a print due to a bug in S3D. In my case it exceeded the maximum extrusion cross section set in Klipper by about a factor of 10. In that case Klipper may have prevented damage to my extruder and/or hotend. I've begun using slic3r more often now and I haven't seen this issue with gcode it generates.

smoth90 commented 6 years ago

I found that the F0 is generated only if the option "Only wipe extruder for outer-most perimeters" is enabled (at least for the STL that i'm printing at the moment).

I agree that it could be an error of the slicer, but i don't agree that klipper fail the print (the printer go from printing to operational state so in octoprint it show as completed not fail) just for an F0 move, since if it ignore it nothing happens to the print or the printer.

jakep82 commented 6 years ago

I don't think it's safe for Klipper to make guesses about which invalid line of gcode is okay to ignore. I didn't look at this particular gcode, but if it had ignored this line, wouldn't it then be asked to unretract that same 6.5mm of filament at high velocity? I don't want my printer trying to shove 6.5mm of filament through my hotend at 30mm/s after ignoring an invalid retraction line. I would much rather have the print fail with a warning about why so I can track down the root cause of the issue and fix it.

cmock commented 6 years ago

I just had a look at the Repetier and Marlin sources: Repetier ignores the "F" parameter unless it's > 0.1, Marlin ignores it unless it's > 0.0.

hg42 commented 6 years ago

following http://reprap.org/wiki/G-code#G0_.26_G1:_Move

G1 X91.804 Y129.181 F9000
G1 X91.804 Y129.181 E-6.5000 F0

would mean to move E by -6.5 while decelerating from F9000 to F0. Reprap.org defines it as one more variable that is ramped from a start value to an end value in this case. I always ignored this while reading, because my intution told me it might be conflicting with other acceleration behavior. But at least it's not illegal. It's not a move with F0 but a move that ends at F0.

KevinOConnor commented 6 years ago

On Thu, Feb 15, 2018 at 12:53:08PM +0000, Harald wrote:

following http://reprap.org/wiki/G-code#G0_.26_G1:_Move
G1 X91.804 Y129.181 F9000
G1 X91.804 Y129.181 E-6.5000 F0
would mean to move E by -6.5 while decelerating from F9000 to F0. Rreprap.org defines it as one more variable that is ramped from a start value to an end value in this case. I always ignored this while reading, because my intution told me it might be conflicting with other acceleration behavior. But at least it's not illegal. It's not a move with F0 but a move that ends at F0.

No, those docs are referring to an old "g-code experiment" where acceleration was explicit in the g-code. No widely used software implements that. It's just another example of how confusing and painful g-code is.

The F0 in the above command means perform the retraction at a speed of zero and it is a non-sensical request. It is a Simplify3D bug.

-Kevin

lenne0815 commented 6 years ago

@smoth90 Had exactly the same problem a few weeks ago and kevin investigated it, it is in fact an s3d bug.

moopco commented 6 years ago

Are you fucking serious "This isn't our problem, it's s3d's problem"

Get a fucking grip guys, you are small fish, s3d is the most popular professional software, it's your job to make your product work with theirs, not the other way around. At the very least, give us the option to turn off this shitty over protective nannying.

lucashpandolfo commented 6 years ago

No need to be rude. You can ask nicely too. It's a fact that S3D, the most popular professional software, is generating bogus g-code and I kind of agree with Kevin. Working around slicers bugs is kind of silly. The problem is that you can't retract at 0 speed. Ok, so what do we do? Nothing at all? Just ignore it? Retract at a given default speed?

Anyway, for now you can just sed the file replacing all the F0 instances if you like.

If you want to change the default behaviour to try some things, look here https://github.com/KevinOConnor/klipper/blob/master/klippy/gcode.py#L415

dragonnn commented 6 years ago

Do you use WIPE or something like that? What S3D version. Because I use S3D too and I don't see any g-codes like that.

hg42 commented 6 years ago

@moopco (ignoring your fucking words)

I get your argument. Think about it, someone creates an error and everyone should work around that, instead of fixing the error? That's why so many bugs are not fixed today. E.g. like Microsoft does when documenting a bug as "behavior" instead of solving the problem. Generations of programmers have to workaround these "features".

Back to the problem:

I would think, either there is (was?) a severe bug in S3D or your settings are weird. As a software guy I cannot imagine why a slicer should create such code under sane conditions.

I agree partly, the firmware could eventually tolerate illegal things that are not severe for the hardware or starting fires etc. But in this case, how to decide what to do?

The correct behavior for the firmware would be to do what the slicer told it, that is wait infinitely, because speed is zero and you never reach the target position. I guess you would not like this, right.

If the firmware should ignore the speed, what to do instead?

ignore the target position? then on the next move it would start at a wrong position, resulting in a blob or skips, may be ruining your extruder.
set the extrusion position to the new value without moving? then the extrusion is effectively ignored...but didn't it have a purpose?
move with some fictional speed? which one? For F0 I would choose a kind of minimum speed, because it would be reasonable to assume it's a rounding error, that happend to result in a zero. Now you wait for a looooong time.

cmock commented 6 years ago

What Marlin and Repetier seem to do is to behave like there was no "F" parameter.

If klipper goes the "bug compatibility" route, I suggest behaving like other firmwares do would be the right thing (in the sense of least surprise for the user).

oderwat commented 6 years ago

If one has this bad code from S3D and "Klipper" is not agreeing to solve it like Marlin/Repetier does, there is alway the option to remove the F0 parameter with an internal S3D post-process script. I am not sure if that works while GCode error correction is enabled though, but as Klipper does completely ignore the error correction, it will not even harm if you just replace any " F0" with "" or " F0" with "".

GregNuspel commented 5 years ago

One thing you must remember is there are variations on G-code. You would not want to run code for a Okuma on a HAAS because the code is different. Even from one Fanuc controller to another there are variations. So is this code processed for Klipper? If so give them an error report. If you are using code processed for another printer you may have to adjust the code. Post-processors have to be tweaked for the controller, we even tweak our post-processors at work to match our programming style and that is coming out of MasterCam a well established CAM software.

s1mpleman commented 5 years ago

If one has this bad code from S3D and "Klipper" is not agreeing to solve it like Marlin/Repetier does, there is alway the option to remove the F0 parameter with an internal S3D post-process script. I am not sure if that works while GCode error correction is enabled though, but as Klipper does completely ignore the error correction, it will not even harm if you just replace any " F0" with "" or " F0" with "".

Try the scripts tab on S3D and go to the Additional command section. Use: {REPLACE "E" "A"}

This will replace all instances of E, with A.

Klipper3d / klipper

Invalid speed message #173