Design a site like this with WordPress.com
Get started

Test castings

Moving along in my project I realized I needed to solidify my ideas and come up with a final form for these objects to manifest themselves. Taking inspiration from my previous test of casting the foam cutouts in plaster, and my prior experiences in concrete, I decided to try casting these shapes in concrete. For my initial tests I used previous foam tests from the syringe pump calibrations which is why these casts vary so widely in thickness and form.

These first tests were done in a concrete product I am familiar with, Rapid-Set Mortar Mix. This has been a great product for me in the past producing fine details in small castings and skinning larger objects because of its short setting time and lack of large aggregate. However these qualities and it’s significantly higher price may not me ideal for larger castings so I tried experimenting with more traditional concrete products.

The first 2×2 test used some foam forms close to my final design, but again these are just samples. I used this opportunity to tests a few things at once.

First I used quickrete, a new product to me which contains sand and gravel along with the cement. This turned out interesting since sand and gravel evidently does not absorb water like the mortar does, so much less water is needed; I however, did not adjust my recipe and ended up with a very watered down soupy mess. Surprisingly it still set up, produced decent details, and supported itself when suspended. In theory concrete with too much water is weaker but it was good enough for my test.

About that suspension, I also used this test to try out some holding options. These castings will be heavy and I’ll need a way to carry and display them. Since I’m still not sure if they hang on the wall, lay on the floor, or ideally, assemble into a freestanding sculpture I need a versatile solution. The three things I tried were an imbedded cleat, protruding bolts cast into the concrete, and an imbedded coupler nut cast into the concrete and bolted through a mesh insert. This last option seems the most useful and flexible depending on how I set these up for display. After making this casting I suspended the concrete from this connection for several days without structural failure.

My last objective from this test was determining weight. The 2×2 grid weighs 30lbs (still fresh and rather wet), but this let me know about the weight of the final 4×4 panel, about 120lbs.

Advertisement

Exploring Presentation

As the end of the semester nears, I’m beginning to think about presentation and how I can effectively show my research. Here are some pictures of the work I brought into my thesis crit, showing how I displayed the work for that class. Our first class got canceled so I had 2 setups over 2 weeks.

Syringe Pump Exploration

Syringe Pump?

Building off my caulk gun idea, I thought it might be useful to use liquids such as paint or acetone in a controlled manner. Enter the syringe pump. I found some files on thingiverse that got me started and allowed for a quick proof of concept. However, the design was both lacking and intended for a different motor, so it required lots of changes. you can see some of my process in these pictures. Maybe If the pump works and I clean up the file I’ll post a remake to thingiverse to keep the love going.

The Caulk Gun

Moving on from pyrography, I started testing out some messier and more unpredictable outputs. The first test, tubes of construction adhesive.

Machine in action video (Google drive Link)

Adding Efficiency and Polish

My initial tests prints worked but left a lot to be desired. First and foremost I had to change the movement. The hand drawn arcs were nice but a hassle to reconfigure when I wanted to change the size, or the order that the machine draws the dots. So I dove into grasshopper, drawing the movement structure with an algorithm that could be both more efficient and adaptable to different circumstances. The difference looks a little like this…

The next challenge was addressing the visible lines occurring as a result of heat cycling. While I couldn’t get the aluminum heat sink replacement tip to work, I found another solution, randomization. By randomizing the drawing order, the heat cycling becomes less apparent. However, since I am trying to ‘collaborate’ with the machine and utilize some of the unexpected elements that come out of the experiments, I came to a compromise which softens the cycling but does not eliminate it completely. I did this by randomizing each row individually instead of the entire image at once. This preserves the charming quirks of the machine while adding some intentionality and polish. See details below.

Up and Running

The Machine Works (Mostly)

Dylan, my modified 3D printer is up and running, creating pyro-graphic recreations of supplied images. The images are processed through a grasshopper algorithm which maps the brightness values of the image to time values for the burner to remain on the wood. While there are still some minor issues to work out, I think this is a promising start.

gCode: Generating gCode without a Slicer

Most times that I use a 3d printer, I model a solid object in Rhino, export to an STL, than use a slicer such as Prusa Slicer to generate the gCode which controls the movement of the printer. So controlling the printer manually, or without a solid object was completely new to me. Luckily, our wonderful professor, Ryan Hoover has already created a plugin for Grasshopper which converts curves in Rhino to into gCode moves. This plugin is called Xylinus.

I created the necessary geometry by drawing a few curves in rhino, than arraying and weaving those lists together in grasshopper, to form a single, consecutive list of curves. After some more troubleshooting and tests to insure that list was properly ordered, I added in entry and exit moves, and input those curves into the Xylinus “Crv to GC” component. This gave me the gCode for the basic motion, but I still needed a way to control the intensity of the wood burning.

While this took some work to get right, the concept is simple. The gCode command “G4 S(n)” instructs the printer to “dwell” at its current location for “n” seconds. The (n) values were generated using a “range” with a reasonable domain for test grayscales, and the rest of the command was formatted with the “concatenate” component to combine text fragments. When I began actually using pictures the handoff was easy, I just swapped these values for remapped brightness values using the Grasshopper definitions from our “Encoding environment” workshop.

In these pictures you can see how the picture is divided into a grid and sampled for the lightness values, then how that translates to the machine.

Since Xylinus conveniently formats each curve as a tree branch the dwell commands were than inserted into the end of each list. From there I added beginning and end code, before saving out to a text file.

Pronterface: Controlling the Printer

Pronterface is the software I chose to control the printer. This application acts as the in between from the gCode generated in Grasshopper to the printer’s control board. The Pronterface software can be used to control just about any function on the printer from homing, zeroing individual axis, running gCode files, running manual inputs from the command line, and running code from customizable buttons for repeated tasks.

The custom buttons came in especially helpful for my updated zeroing strategy which requires a few specific commands.

Printing: Greyscales and First Images

To determine the time domain and test the function if the printer, it was necessary to print a few greyscales so calibrate my code. This exercise also allowed me to determine the size of the dot, and thus, how big the grid needs to be.

After these tests I moved onto printing pictures, specifically a portrait of Joseph Prusa. I chose this portrait to honor the printer’s origin and show my appreciation for the amazing work that the Prusa company has done for the digital fabrication community. After learning from that print I made a few changes, resized my curves and arrays for a lager image, than sent the longest print yet, an 80mm, five hour long self portrait.

Modifying the Printer (10/25/21)

First Draft

After removing the old x-carriage assembly with the extruder motor and the hot end, I got to work building my new attachments. The STL for the x-carriage mount freely available, so I printed one off to use as the base of the design. From there I mocked up a quick prototype from wood, and bolted that to my new print.

This initial mock-up was slightly flawed, but contains a few key features. Primarily, the burner is attached to a base plate which is free to travel in the Z axis. This plate is than tensioned downward with a rubber brand creating a spring action as the burner assembly descends. This first version also contains an auxiliary arm for bed leveling sensor, as the printer requires this attachment to home itself properly. In later revisions I learned how to home the printer through g-Code, negating the need for this sensor.

New Burner Tip?

After some tests prints, I determined that the burner could not stay hot enough to remain even and consistent over a long period of time. Given the same rest time on the surface, the intensity of the burns would degrade over time, since the burner loses heat energy with every burn, and could not replenish fast enough.

As a possible solution, I got some help to machine a new aluminum burner tip with a large heatsink. The goal here is to heat up the larger metal mass, which will stay hot for longer and bridge the energy gap. More testing is necessary.

A New Name

In accordance with the dFab shop convention, every 3d printer, or motion machine needs a name. Thus, this machine shall be named Dylan.

Preliminary Printer Tests

Getting acquainted with the printer interface

This week I performed some initial tests and trials to see how my wood burning idea would manifest. I connected the printer to pronterface and sent move and temperature commands. I also played with grasshopper, looking at Hoover’s custom plugin to generate g-code from grasshopper curves, but was unsuccessful at creating the program I need.

Examining gCode

For this week’s homework I compared the gcode for two objects I have fabricated, a 3d Print on a PrusaMK3s, sliced in Prusa Slicer, and a 3d carving milled on the Fanuc CNC router with gCode from RhinoCam.

I noticed many similarities, like G1 for move commands, and the syntax of how comments are inserted. There were also differences like the g2 and g3 codes in the CNC file which control arc moves.

I found the prusaslicer code to be much more user friendly, as each action had a comment explaining the function of the following code, for example

;Wipe Start

Followed by the move commands, then

;Wipe end

This made understanding the code easy. On the CNC code there were no comments, but you could discern things like step down by looking for a change in the z height.