Week 4: G-code Experiments

This week I focused on printing directly with G-code generated in Grasshopper with the prompt of not using any commercial slicing software. This week was much more about process than product, which reinforced some of my conclusions from the reading Being the Machine. While I'm not really happy with any of my prints, I learned more about the Ender 3 Pro's controls and settings than any other weeks.

• Rhino
• Grasshopper
• Sublime Text
• Ender 3 Pro

I began with the SimpleSlicer.gh example code. I initially tried to slice a torus, but it didn't appear to slice correctly, so I shifted to a cylinder. After, successfully exporting G-code from Grasshopper, I printed my first cylinder. It was ridiculously tiny (as seen in the first image), and very close to the front left corner of the print bed (or the origin in Rhino). I scaled the same cylinder up, and moved it further away from the origin to try to center it on the print bed (as seen in the first three images). I was very inspired by the examples that introduced procedural glitch into simple cylindrical forms. In image 4, I was attempting to add kinks into Simple Slicer, which looked like it added complexity in Grasshopper, but none of this translated in the G-code and the 3D print looked identical to the standard cylinder.

Next, I tried the GCodeTurtle.gh example to create the five sided extruded star (images 4-8). For some reason the "sides" parameter wasn't functioning properly for me, so I couldn't generate more complex shapes. The five pointed star printed fine. The initial line to the left (image 5) was very helpful to getting a clean and consistent first layer. My G-code generated with SimpleSlicer.gh didn't include this function, and I should copy it at the beginning of any G-code I generate, as it does automatically when I use Cura. I included a blob (image 6) where the extruder nozzle stopped when I aborted the print. Typically on a sliced print, the Ender 3 Pro will lift on the z-axis and retract on a paused or stopped print, but in my G-code it just stopped with the hot end on the print. Something to keep in mind for the future.

Next, I tried the printedFabricSimplified.gh and printedFabricComplex.gh examples. I added more pillars and more height. I shrunk the corner pillars to see if I could save time and filament, which worked fine on the first smaller swatch, but began to gradually fail on the larger swatch. It still held it's structure, and didn't show after I trimmed the supports off. I should have attempted to generate more complex weavings, such as over one under two, but I kept exploring other code examples.

I was curious if I could add a more complex mesh as my input instead of a Brep primitive. I made a icosahedron in Blender and exported it as an STL, which I imported into Rhino. I disconnected the "Brep" node and linked a "mesh" node to the beginning of the patch, which worked in the same way. I only printed half of the icosahedron because I figured the unsupported G-code vase would fail on overhangs. I was surprised how the spiral Grasshopper slicer pathways became more pronounced than the hard triangular geometry of the icosahedron model. As predicted the unsupported overhangs gradually distorted the form on each vertical overhang layer, resulting in stress tears. I let the print keep running until it started to totally fail because the stress tears were interesting and consistent.

I wouldn't choose to slice without a slicer again, but the limitation definitely forced me to learn more about Marlin commands, the manual control settings on the Ender 3 Pro, and basic functionalities that I may have taken for granted in Cura. It has definitely given me a deeper understanding of the different interfaces and what is happening at a programmatic level.

Inspired by our in class examples, I wanted to explore procedural glitching of a simple cylindrical pathway through under-extrusion, over-extrusion, or randomly toggling the extruder on and off.

I found this paper with detailed examples and code, but I don't know python well enough yet to figure out how to integrate these functions into the building blocks of our example code.

I had an idea to attempt to generate cellular automata with an online generator through Wolfram, and then I imported that image onto a form through an online lithophane generator. I was happy with this form, and attempted to slice it with SimpleSlicer.gh, but it was such a large mesh that Grasshopper kept crashing. I gave up after many instances of staring at the beach ball of doom, and decided maybe someday I will try to slice the STL in Cura. I added some images of the model rendered in Blender to help visualize.

I would still like to learn how to implement the functions from the paper into G-code, it would be very fun to explore these subtle automata patterns.

I attempted to import one of my STLs from Week 1, and transformed it into a fabric through an array modifier. I made 10x10 and 4x4 iterations, but they were both very large files that took a long time to process. Even just trying to reimport the 10x10 STL crashed Rhino. I was able to export G-code of the 4x4, but it totally failed on the print bed. The extruder was tracing tiny little pathways that did not adhere to the print bed and just lumped up on the nozzle, rather than laying the entire pattern layer by layer. Again, I didn't know how to solve this with just G-code, and decided to try again with Cura at a later date.