You can get raw gcode files by doing file/export - but the advantage of them staying in a .gcoce.3mf file is that they are easier to send to the printer remotely - rather than having to use an sd card.
1 Like
The G-Code “language” itself remains the same. I can only speak on CNC machines and how they process gcodes. But this is different with 3D printers. The MB will interpret g-code and sent tasks to the MCU to perform. But as for linear moves, arcs and feed/speeds those are fully interpreted by MCU’s.
Slicing software essentially acts as a “post-processor” that translates a 3D model into code readable by 3D printers. That code itself isn’t customizable unlike a CNC using say MasterCAM - I can “post” toolpaths and alter any line of code through out the entire program. With bambu lab you can alter certain area points of gcodes/mcodes only as all other “macros” are predetermined by the slicer specifically for the printer.
reprap, klipper and marlin post gcode & mcodes but not all 3 read the same to one another. Bambu Lab printers are marlin based btw.
Interesting breakdown, thank you for it. I was under the impression the gcode could define the route the toolhead would take. Based on your description it sounds more like the gcode specifies points to apply material, retraction, etc. but the MCU determines the best/fastest way to move from point to point. This might explain why I often see the printer work an area of the print, hop over somewhere else then later hop back.
1 Like