Non conventional 3D Print challenges (GCode)(fullcontrol.xyz)
fullcontrol.xyz
Non conventional 3D Print challenges (GCode)
https://fullcontrol.xyz/#/models
27 comments
Nozzleboss is a tremendously interesting tool, thank you for creating and sharing it.
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.
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.
Thank you very much for all the praise.
Cool to see some fellow 3dp enthusiasts here.
I wrote a python library for directly generating GCode when I was working at a university lab that needed more direct control over their very high end 3D printers. You can check it out here:
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.
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.
please read and understand any third-party gcode before running it on any machine, anywhere.
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.
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.
Can you elaborate on this?
Not OP, but the firmware on the printer executing the G-Code assumes it is trusted and does not check it any further, apart from certain kinematic limits. With kinematic limits, I mean simply mean that the X/Y/Z position, velocity and acceleration is limited based on printer/user settings. These limits (especially the position limits) ensure that you can't slam the printhead into the physical limits of an axis with full force, which might cause damage on the mechanics.
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.
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.
G-code is mostly a list of instructions that tell the machine how to move. As result, it can tell the machine to move in ways that might damage the machine, like bonking into itself or pushing the nozzle into the bed or print. There are nice visualizer that will draw the toolpath so you can see it.
Not a huge deal in my opinion.
Not a huge deal in my opinion.
No Prusa mini support. I hope it will be added soon since this way of printing could be very convenient for certain parts of a model.
[deleted]
Usually you try to avoid overhangs but this experiments makes you realize of the true limits of the 3d printer.
I'm gonna try the Pin Support Challenge next weekend.
https://www.instagram.com/p/CjVvw5xjt2o/
https://www.instagram.com/p/CjVvw5xjt2o/
PLA gets so much stronger when annealed. Would it be within the spirit of the challenge to print this upside-down so that it can support the sphere, but only after annealing? Or you could anneal the pillar with a small heater as you print it.
The bonds between layers get stronger when annealed. I don't think it will make much difference in this case since there are no layers in the pin.
Oh my God I didn't even realize this was a thing. Thank you and there goes my evening! :-)
Just note that it will also shrink the print.
So what's FullControl? Modeling software? Control/driver software? I'm not very versed in 3D printing and I can't really understand their "about" text.
It's a bunch of Visual Basic behind an Excel spreadsheet, that helps you generate gcode directly, rather than via CAD/slicers. That gives a level of control that is awful and wonderful. There are a bunch of youtube short videos with demonstrations.
I'm interested in printing small parts containers very fast ... just open topped boxes ... and am looking forward to trying this with big nozzles.
I'm interested in printing small parts containers very fast ... just open topped boxes ... and am looking forward to trying this with big nozzles.
> It's a bunch of Visual Basic behind an Excel spreadsheet
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.
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.
So does it allow you to do things that slicers wouldn't do? Or use tricks that slicers wouldn't use? Like inline assembly is used in programming?
I am confused about how this helps with printing those parts shown on the website.
I am confused about how this helps with printing those parts shown on the website.
Yes and no. Several of these could probably be done with a proper model and "vase mode" in a normal slicer. However, others are simply not possible in a normal slicer because slicers limit you to planar layers and moves. So for example the pin-support challenge cannot be done in a slicer because they would try to slice the pillar into many individual layers with retractions and moves instead of continuously extruding while increasing the z-height as this gcode does. Similarly, the non-planar spacer wouldn't work in a normal slicer either because it's non-planar by design.
> not possible in a normal slicer because slicers limit you to planar layers and moves
That might change, I saw this about 'conical slicing' recently:
https://youtube.com/watch?v=1i-1TEdByZY
That might change, I saw this about 'conical slicing' recently:
https://youtube.com/watch?v=1i-1TEdByZY
We need 3D slicers, surely someone tried to make AI for that already ?
That sounds horrific.
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.)