Non conventional 3D Print challenges (GCode)(fullcontrol.xyz) |
Non conventional 3D Print challenges (GCode)(fullcontrol.xyz) |
I've been developing a similar add-on for Blender called nozzleboss. https://github.com/Heinz-Loepmeier/nozzleboss It lets you use Blenders modeling tools to create toolpaths directly and export to G-code. It has an importer as well, that lets you edit existing G-code with Blender, e.g. using sculpt tools to deform G-code paths. https://www.youtube.com/watch?v=aoM8-Xdh9w8
Using Blender is nice here, because you have access to so much modeling tools already and don't need to code to generate G-code (though you could, Blenders python api or geometry nodes is very well suited for that). The add-on uses vertex colors to store meta information on every segment of the G-code, so you can paint on extrusion/speed multipliers or color itself very intuitively. (Different colors in FDM printing are usually done by segmentation of the mesh into different parts, which can be difficult. Though PrusaSlicer introduced multi-material painting recently, so if you are interested check that out.)
Folks,rhklein's work is unique. If you want to see some astonishing 3D printing thinking manifested in strangely beautiful, unearthly objects, check out @nozzleboss on Instagram.
https://github.com/jminardi/mecode
Its been a few years since I have worked on it but from what I understand the lab members are still using it.
While I understand the need for it in this case, there are a lot of good reasons why the slicer/cam suite is supposed to be intimately meshed with the machine and environment itself.
However, there are a number of movements that could sneak past those kinematic limits and still cause significant damage.
For example, the Z lower limit is usually a few millimeters below the print bed since the bed position varies (due to bed leveling, thermal expansion during heating and so on). A malicious G-Code file could move the Z axis gradually lower, in small increments, but with high overall speed. The nozzle/printhead would then slam into the bed, generally causing damage.
A malicious G-Code file could also try to drag the nozzle across the print bed in patterns, gradually lowering the Z position so that it will certainly touch the bed at some point. Such a file has the potential of completely destroying a print surface.
Finally, nothing prevents a malicious G-Code file from first printing an object normally, just to finally lower the Z position and crash into the object with high speed. Such a movement would likely cause damage to the printhead and possibly other parts, depending on how well the printed part adheres to the print surface.
Those are a few possibilities that I just thought of. Luckily, for a 3D printer the damage is contained to the printer itself. But for other machines operating on G-Code the risk could be far more severe. For example, if a tool-changing CNC router (read: $$$) slammed a tool somewhere it shouldn't with full force, it would not only cause thousands in damage to the machine itself, but could also wreak havoc to its environment by catching fire or other outcomes I won't enumerate here.
Not a huge deal in my opinion.
I'm interested in printing small parts containers very fast ... just open topped boxes ... and am looking forward to trying this with big nozzles.
While true for the original FullControl, I've understood they are currently working on a new version in Python, and presumably that is what was used to generate the gcode that's on the website right now.
I am confused about how this helps with printing those parts shown on the website.
I agree, BTW, PETG is much better.