Have any Slic3r users encountered lines of G-code containing a feedrate of zero?

Have any Slic3r users encountered lines of G-code containing a feedrate of zero?

I ran into it this week. For a while I thought something was wrong with my printer firmware or electronics, or something. I’d started the print and it ran fine for the first few layers, then it stopped dead. Only way to recover it was to reset the arduino. Then I started some test runs with no extrusion and realized it was stopping at the same point in the print every time. This pointed to a G-code problem. I groveled through the G-code a bit and finally found it. A line that looked like this:

G1 X1.234 Y5.678 F0.000

The machine would run fine until it hit this line. Then it would dutifully sit there, moving at a feedrate of zero, until it reached the appointed coordinates, i.e. forever.

Haven’t had this myself. What firmware is your version of slic3r targeting? And what version of slic3r?

It’s Slic3r 0.9.7 targeting Teacup firmware. I’m going to enter an issue on Github, after I gather some more data.
I’m running it on an old Windows XP machine.

Is this point on on the fill pattern? I had that issue once and changed the type of fill pattern.
0.9.8 just came out. I am using it now with no issues. Quite a few bug fixes, but none that l interpret to fix your issue. Still might be worth a try?

I fixed a bug where the gcode output had zero distance, much different problem, I know. But it got rejected because I didn’t have an stl that would recreate the problem. I wouldn’t bother filing a bug against an outdated version, nor any version, without a fix and a problematic stl.

I did some more testing and I think I chalk this one up to user error.

I had intended to set the infill to 0%. Instead I set the infill speed to 0. Not sure how I did that, seeing as how those two settings aren’t even on the same screen.

@Chris_Vestal It was your question about infill settings that made me check there.

@Mark_K I do software testing for a living. Believe me, I wouldn’t have filed a bug report without being able to provide full documentation.

I may have experienced this as well. I came home one night and found the printer with the nozzle on and the head parked part-way through a print. The controller was responsive and everything seemed normal but for the whole thing just seeming “paused”.

I figured the firmware crashed or something but I’m going to go back and look at the Gcode to see if maybe I ran into the same bug?