5 ms·

If I recall correctly, 3D printers don't even handle smooth curves in 2D. I've heard CNC people express contempt at how primitive the Gcode used by printers is,

If I recall correctly, 3D printers don't even handle smooth curves in 2D. I've heard CNC people express contempt at how primitive the Gcode used by printers is, how it doesn't support any of the advanced features of machine movement that create smooth curves.

tslater2006 2y ago
This is correct the last I read about it, but there was a project called ArcWelder that would post-process your gcode and convert the motions to true arcs. The printers today support the arc gcode, but the slicers don't generate them. https://github.com/FormerLurker/ArcWelderLib https://github.com/FormerLurker/ArcWelderLib
- jepler 2y ago
  arc support may exist but be poor. For example, I recently read prusa's documentation, which states "[G2 and G3 controlled arc move] commands don't propperly work with MBL enabled. The compensation only happens at the end of the move, so avoid long arcs." MBL is mesh bed leveling, an important technology that helps compensate for imperfections in the flatness of the print surface.
  - double0jimb0 2y ago
    Bambu Lab does this. The accel values they print with are so high without arcs it would get quite violent. X1C is most impressive piece of hardware I’ve bought recently, just bought another today. Prints 4X faster than ultimaker https://wiki.bambulab.com/en/software/bambu-studio/acr-move https://wiki.bambulab.com/en/software/bambu-studio/acr-move
    - dotnet00 2y ago
      This doesn't sound right, plenty of printers print as fast as Bambus and faster, yet arcs are not a go-to for them (Voron, RatRig, Annex communities all seem totally indifferent to that feature). The value of arcs is in reducing gcode size and thus allowing weaker processors to handle particularly curve heavy prints. Since other fast printers have until very recently been mainly DIY and Klipper based, they've had more than enough processing power to handle unwelded gcode without special handling for arcs due to typically doing all the processing on an RPi. If the slicer can't generate arcs, it has to do what the firmware does in the case of arc gcode, that is generate a large number of small moves to represent the arc with sufficient resolution, this doesn't affect jerkiness because as long as the firmware is keeping up in processing the gcode, the steppers move the same as they would with the equivalent arc gcode. The 'pulses' the page mentions would only occur if the processor can't keep up with the movement of the toolhead.
      - iancmceachern 2y ago
        You are confusing 2 things, both are true. Yes, using arcs is better because it negates the need to make a bunch of smaller moves, uts better for the controller and the motion itself. Just because those printers are also fast, doesn't mean the arcs aren't still better for these reasons.
        crote 2y 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.
        double0jimb0 2y ago
        Any non-arc generates instantaneous acceleration changes at the line inflection points, these are impossible for a mechanical system to perfectly implement. Huge amount of jerk results the closer/faster one tries to achieve instantaneous acceleration. Why wouldn’t a system try to use arcs and splines to minimize these effects? The CNC controller world has been trying to solve this problem for decades. Turning everything into line segments seems to go in opposite direction of this progress.
        iancmceachern 2y ago
        You are missing a lot of technical detail. 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.
    - causality0 2y ago
      Why now? They're expected to announce a successor printer in the next few months and they've said the X1C, as their oldest printer, will stop getting firmware updates next year.
imtringued 2y ago
The 3D printer community is oddly resistant to step files. They claim that step files get converted to STL and therefore it doesn't matter. Except there is an obvious problem with this argument. First of all a mesh isn't an STL file, second the printer can adapt its mesh generation based on your slicer settings so that it always has a high enough resolution. Third, the mesh generator can adaptively generate high resolution meshes in complex geometries and low resolution meshes at simple geometries in the same part. Fourth importing step files generates G code with arcs which speeds up printing time. https://www.reddit.com/r/BambuLab/comments/w15mg6/improvements_in_printing_speed_with_step_files/ https://www.reddit.com/r/BambuLab/comments/w15mg6/improvemen...
- naasking 2y ago
  There are some good reasons: https://en.wikipedia.org/wiki/ISO_10303-21#Criticism https://en.wikipedia.org/wiki/ISO_10303-21#Criticism
- causality0 2y ago
  Man, I would pay out the nose for a program, possibly AI-driven, that could take a mesh and turn it into a step file.
  - dekhn 2y ago
    Fusion 360 does this, although with some limitations (https://help.autodesk.com/view/fusion360/ENU/?guid=MESH-CONVERT-TO-SOLID https://help.autodesk.com/view/fusion360/ENU/?guid=MESH-CONV...). I occasionally use it to take meshes and convert them to B-rep (fusion 360's preferred internal representation) using parametric/prismatic. It doesn't work for complicated geometry or high mesh vertex/edge counts. And in most of my work it's not necessary (I'm typically just carving mesh surfaces into wood, but sometimes I need to reverse engineer an STL). I guess I pay about $600/year (didn't check the latest pricing) for the base Fusion 360 non-professional product and it's worth every penny.
naasking 2y ago
> I've heard CNC people express contempt at how primitive the Gcode used by printers is, how it doesn't support any of the advanced features of machine movement that create smooth curves. The firmware supports them last I checked, it's the slicers that don't output proper arcs.

tslater2006 2y ago

This is correct the last I read about it, but there was a project called ArcWelder that would post-process your gcode and convert the motions to true arcs. The printers today support the arc gcode, but the slicers don't generate them. https://github.com/FormerLurker/ArcWelderLib https://github.com/FormerLurker/ArcWelderLib

jepler 2y ago
arc support may exist but be poor. For example, I recently read prusa's documentation, which states "[G2 and G3 controlled arc move] commands don't propperly work with MBL enabled. The compensation only happens at the end of the move, so avoid long arcs." MBL is mesh bed leveling, an important technology that helps compensate for imperfections in the flatness of the print surface.
- double0jimb0 2y ago
  Bambu Lab does this. The accel values they print with are so high without arcs it would get quite violent. X1C is most impressive piece of hardware I’ve bought recently, just bought another today. Prints 4X faster than ultimaker https://wiki.bambulab.com/en/software/bambu-studio/acr-move https://wiki.bambulab.com/en/software/bambu-studio/acr-move
  - dotnet00 2y ago
    This doesn't sound right, plenty of printers print as fast as Bambus and faster, yet arcs are not a go-to for them (Voron, RatRig, Annex communities all seem totally indifferent to that feature). The value of arcs is in reducing gcode size and thus allowing weaker processors to handle particularly curve heavy prints. Since other fast printers have until very recently been mainly DIY and Klipper based, they've had more than enough processing power to handle unwelded gcode without special handling for arcs due to typically doing all the processing on an RPi. If the slicer can't generate arcs, it has to do what the firmware does in the case of arc gcode, that is generate a large number of small moves to represent the arc with sufficient resolution, this doesn't affect jerkiness because as long as the firmware is keeping up in processing the gcode, the steppers move the same as they would with the equivalent arc gcode. The 'pulses' the page mentions would only occur if the processor can't keep up with the movement of the toolhead.
    - iancmceachern 2y ago
      You are confusing 2 things, both are true. Yes, using arcs is better because it negates the need to make a bunch of smaller moves, uts better for the controller and the motion itself. Just because those printers are also fast, doesn't mean the arcs aren't still better for these reasons.
      - crote 2y 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.
        double0jimb0 2y ago
        Any non-arc generates instantaneous acceleration changes at the line inflection points, these are impossible for a mechanical system to perfectly implement. Huge amount of jerk results the closer/faster one tries to achieve instantaneous acceleration. Why wouldn’t a system try to use arcs and splines to minimize these effects? The CNC controller world has been trying to solve this problem for decades. Turning everything into line segments seems to go in opposite direction of this progress.
        iancmceachern 2y ago
        You are missing a lot of technical detail. 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.
  - causality0 2y ago
    Why now? They're expected to announce a successor printer in the next few months and they've said the X1C, as their oldest printer, will stop getting firmware updates next year.

imtringued 2y ago

The 3D printer community is oddly resistant to step files. They claim that step files get converted to STL and therefore it doesn't matter. Except there is an obvious problem with this argument. First of all a mesh isn't an STL file, second the printer can adapt its mesh generation based on your slicer settings so that it always has a high enough resolution. Third, the mesh generator can adaptively generate high resolution meshes in complex geometries and low resolution meshes at simple geometries in the same part. Fourth importing step files generates G code with arcs which speeds up printing time. https://www.reddit.com/r/BambuLab/comments/w15mg6/improvements_in_printing_speed_with_step_files/ https://www.reddit.com/r/BambuLab/comments/w15mg6/improvemen...

naasking 2y ago
There are some good reasons: https://en.wikipedia.org/wiki/ISO_10303-21#Criticism https://en.wikipedia.org/wiki/ISO_10303-21#Criticism
causality0 2y ago
Man, I would pay out the nose for a program, possibly AI-driven, that could take a mesh and turn it into a step file.
- dekhn 2y ago
  Fusion 360 does this, although with some limitations (https://help.autodesk.com/view/fusion360/ENU/?guid=MESH-CONVERT-TO-SOLID https://help.autodesk.com/view/fusion360/ENU/?guid=MESH-CONV...). I occasionally use it to take meshes and convert them to B-rep (fusion 360's preferred internal representation) using parametric/prismatic. It doesn't work for complicated geometry or high mesh vertex/edge counts. And in most of my work it's not necessary (I'm typically just carving mesh surfaces into wood, but sometimes I need to reverse engineer an STL). I guess I pay about $600/year (didn't check the latest pricing) for the base Fusion 360 non-professional product and it's worth every penny.

naasking 2y ago

> I've heard CNC people express contempt at how primitive the Gcode used by printers is, how it doesn't support any of the advanced features of machine movement that create smooth curves. The firmware supports them last I checked, it's the slicers that don't output proper arcs.