Jamini’s Large Assignment 4

Description + Process

For this assignment, I created three different structures. My favorite aspect of writing straight G-Code rather than using the slicer is the ability to draw more interesting paths, whether planar or not. So, I wanted to test out a few of the different options that this advantage offers, using the Python extruder turtle library. The first was a ‘simple’ looping path. Second, I tried out using the turtle to create a non-planar surface that followed a wave pattern with increasing amplitude and radius at each level. Third, I used small steps outward to create a dotted surface, where each row represented an iteration of a particular cellular automaton rule.

Shape 1

The first, the loopy circle, was more of a challenge than expected. This shape can’t be created with a normal slicer, or at least turn out as well with one, because of the fine lines of the turtle’s path. It only extrudes one, single path for each layer, which would turn out weird with the way a slicer generates its G-Code. Actually designing the structure using the turtle was fairly simple. It starts with a basic t.forward, t.right, and the angle of the turn is a function of the step/iteration. To make the angle gradually increment from 0 to 1, and then back to 0, I used a sine function. Finding the values needed for a perfectly even single loop required some trial and error. As it turns out, 540 steps with an angle function of sine(0.35125 * i) creates this, with a small offset to make the structure rotate slightly at each layer. Subtract 0.00005, and it is almost perfectly straight. Here’s how the digital representation looks:

Printing this one did not go as well. Something weird was going on that I don’t quite understand. It looks fine in both Rhino and Cura, but when it prints, it does not work at all. I hoped it was the same issue as I was having with the second shape, which had to do with decimal rounding, but it still didn’t work. Here’s what that looked like:

Shape 2

The second shape, the wave structure, takes advantage of the non-planar feature of the no slicing approach. Accordingly, this one can’t be created in a regular slicer because the extruder does not follow a planar path. Something similar could work with a slicer, but it would not come out nearly as smoothly, and the walls would be created with the usual back-and-forth rather than just following the path of the circle. I started with writing a single layer that followed a sine wave in the z direction and a circle in the xy plane. Once that was working, I added extra variables to adjust the radius of the circle and the amplitude and period of the wave. This one wasn’t too much of a hassle, except actually printing the shapes did not work at first. As mentioned, it turns out the issue was with the rounding, because I used very small steps that resulted in very small changes in x and y. The G-Code was being written in scientific notation rather than regular decimal representation, which Leah noticed when I asked for help. She updated the turtle library, and after that this one worked fine.

Here’s the digital representation:

And here’s the final product:

Shape 3

This shape is the most exciting (to me) because of the added interest of the cellular automaton. This one can’t be created with a normal slicer because of the dots along the surface, which would probably not be understood very well by the slicer. I implemented rule 110 by following what I saw in this gif. There’s probably a really elegant way of doing it, but I stuck with an if/elif/else structure to avoid making weird mistakes that would take forever to debug. I started with a random array of 1s and 0s of a given variable length, and for every row in a given number of iterations, applied the rule to the row and appended the new one to an array of the row’s history.

I printed out a PLA version first to make sure the G-Code was working as expected. It seemed to come out okay. To move onto the clay version, I added a solid base, which was not as simple as expected just because of simple mistakes and arithmetic errors. Even once that was working in the G-Code, the base didn’t print out very well, and Leah rescued it by just pressing in clay scraps to fill it in. After that, printing the walls went well. However, as I was cleaning up the Python code and adding comments, I realized that I was actually skipping two rows of the cellular evolution in the smooth/plain rows rather than just inserting two plain rows in between each evolution. So, the pattern isn’t very recognizable as the intended rule, but it still looks neat. Here’s the digital representation:

And here’s the final product:

link to code