Since it's so consistent I doubt this will work but it's worth a shot. Try giving Printrun a higher priority by opening the Task Manager (ctrl+alt+delete), go to the processes tab, find printrun, right click and choose "Higher than normal" under "Set priority" (roughly translated from Swedish but it should be fairly close). What this does is to make Windows assign more of the processors time to Printrun so that other programs asking for CPU cycles will have to wait their turn.
Well I'm more confused than ever, but I got to print Yoda at around F15000 - I just don't know what happened.
I thought I'd try slowing it down a bit, so I opened the gcode file in an editor an replaced F15000 with F10000 (not realising that only the first few layers used that exact feedrate). I saved, opened Printrun, and printed perfectly.
But halfway through the print I thought to myself "it seems really fast". So I looked at the gcode file and realised that from about layer 5 it was printing at F16283 or something, and the feedrates were constantly changing - obviously a setting in Slic3r I don't understand. Nevertheless, it was printing smoothly at the feedrates that were causing me problems before.
If the staggering occurs again, I will try assigning Printrun a higher priority in Windows, and will see if that's the source of the problem.
Thanks for the help.
Try not to use "acceleration" with slic3r. The marlin software will do that automatically for you.
it is easy to explain the non-staggering infill: straight lines take longer to print, so there needs to go much less info over the line. That means no buffer underruns and no slowdown or stopping. That is most likely what is happening to your perimeters, if your STL was very detailed, the resulting gcode to the perimeter will have a lot of very small segments that take more time to send than to execute. Marlin tries to mitigate this by going slower when its buffer gets low, but when conditions are marginal it will stop once in a while.
See if reducing the baudrate to 115200 makes the problem go away. Another option is to decimate the stl in meshlab (reduce the number of facets) to make the average path lenght longer.
Recommended Posts
owen 19
Could be baud rate, mine doesn't quite handle 250,000 from Printrun. Try 115,200
Link to post
Share on other sites