15 minutes ago, 14bitvoid said:jarring with very detailed curves, causing blips.
Yes! This. When exporting to STL it's tempting to do high resolution (more detail, more triangles) but this can cause problems for Marlin which doesn't have much memory and can only plan 16 moves ahead.
Also Cura will throw away some points/gcodes if you have too many - this is adjustable in cura. See these 3 settings in cura and read their descriptions:
Maximum Resolution
Maximum Travel Resolution
Maximum Deviation
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Recommended Posts
gr5 2,167
If you email ultimaker they will send you the UM3 marlin source code. I tried it. They sent it to me. I can send to you if you want. I forget where I put it but I'm sure I labelled it and placed it carefully such that I could find it again.
I just found it. It's from 2017 but I'm 98% sure they didn't touch the path planner. They have never touched the path planner so it's the same as regular Marlin from many years before 2017. The sort of things they change are gcodes and features like reading sensors and stuff like that. Not the path planner.
Send me your email in a DM and I'll email you the code.
Anyway I've been over the source code of Marlin's path planner like 10 times and know it (knew it) pretty well. Are you familiar with it? If not I'll tell you a few details:
Ultimaker Marlin looks 16 moves ahead. The path planner doesn't know what's in the 17th move and it may need to come to a complete stop so it never reaches a speed such that the 16th move can't come to a complete stop.
In other words at any given moment there are typically 16 moves in the queue that have been planned and if you look at them they tend to be a general deceleration to a stop on the 16th move (if they are all short moves). If there is a "long" move (over 16mm long) then you can go max speed up to that move which alone will be able to come to a stop if necessary.
These 16 moves in the queue keep getting updated when move is completed and a new move is ready to be added (each gcode is one move). They are updated to higher print speeds.
So here is one cause of slowing/stuttering/erratic moves:
If you have say 50 moves very close together like on a corner with way too many triangles, then the printer has to come to almost a complete stop and prints that corner very slowly.
If you are printing artwork such as "yoda" and there are lots of movements in different directions on an irregular bumpy surface and there are too many triangles you also get stuttering, erratic printing.
Usually this can be fixed with triangle decimation which reduces the triangles in an STL without changing the part's overall shape much at all.
Link to post
Share on other sites