|
|
|
|
|
by crote
765 days ago
|
|
I don't think this is necessarily the case. With multiple smaller movements the printer doesn't have to come to a full stop between moves. It can simply compare the movement vector of the current segment to that of the next one, and adjust the direction it is moving in accordingly. Use enough segments, and you get some pretty smooth movement. As dotnet00 already mentioned, this is exactly how printers currently implement arcs: the software interpolates the arc into a bunch of tiny line segments. If anything, I'd expect an arc gcode to generate more small movements than whatever the slicer is outputting. |
|
Yes, the controller does (stop between moves), it doesn't have a way of knowing.
Also, with the larger motion commands like arc, some controllers do what's called read ahead and they change what they're doing now based on what they're doing next. If what they're doing now and next are just tiny little vectors that doesn't help, but if they're big moves then it helps a ton.
It's like the difference between a .iges or parasolid file and a .stl file.