A Really Big 3D Printer (5/15/2018)

And a Second One (WIP)

The First Really Big Printer

In December of 2017, I was in a meeting to help coordinate a display for a club I was the public outreach officer for at Innovation Day in January, and having recently seen the RepRap Hangprinter, I thought it would be cool to bring a hangprinter of our own. At the time, my trademark was essentially having too much confidence, so I talked to the other club officers about the idea and we decided to go ahead and make one. I took charge of the project, and started out with looking over the source files.

Since one of the benefits of a hangprinter is the massive build volume, one of the things we wanted to do was put an accordingly massive hotend on the printer so it could print as quickly as possible. To meet this goal, I designed a custom screw driven hotend that used pellets instead of filament. The design was based around a 1/2” auger drill bit, and had 240W of heater power in a custom heat block. Because the auger didn’t provide much compression on the plastic, to make sure that the pellets had ample time to melt the heater block had three 80W heater cartridges oriented parallel to the auger’s axis of rotation. To supply the pellets, a water bottle with the end cut off was used as a hopper, and pellets would flow into the auger at the top of the heatsink. To give the pellets some extra time to soften before reaching the heater block, the auger ran through a copper pipe. For the nozzles, I designed them to have a slip fit over the copper pipe and use screws to secure it to the heater block. I knew keeping the heatsink cool would be a challenge with 240W of heat, so I used a 2-stage 40mm server cooling fan to blow air over it, and tuned the speed based off of the heatsink’s temperature and the hotend’s performance. Finally, since driving the auger would require quite a bit of torque, as I learned with my old filastruder, I used a NEMA23 stepper motor with around 2Nm of peak torque, and could always add a gearbox later if needed.

I knew that making the hotend would take a lot of time and energy, so I kept the rest of the printer’s design simple, staying pretty close to the source design, with an 8’ tall frame made of 2x4’s, but using the same NEMA 23 motors as the hotend for the ABCD axes because the hotend would be much heavier than an E3D V6 or Volcano. I also ended up submitting a pull request to the GitHub project to add support for the larger motors.

With the printer designed, I needed to figure out a way to make it, and I actually lucked out here. Since this was a club project, I could get space in the engineering department’s machine shop and use the machines there to make parts. The only catch was that all of the machines were manual, so making the heatsink and nozzle would be a challenge. With some care, and spending pretty much all of my free time in the machine shop, I managed to make all of the parts and put the hotend together. One of the difficult things was attaching the heatsink to the copper pipe, since good heat transfer between the two was very important. I ended up brazing them together, and this worked out very well. The heater block and nozzle both slid onto the copper pipe with some thermal compound and a few set screws. The frame was pretty simple, and mostly needed a lot of 3D printed parts. The 2x4’s were held together by printed brackets, and the motor mounts and gears were also printed.

Once all the parts were done, I started putting everything together. I won’t detail the build process too much since it wasn’t very different from the original hangprinter on GitHub. In a nutshell, I placed the ABC motors underneath the build platform, and the D motor on one of the angled 2x4’s so it was accessible. After that I measured out lengths of fishing line, spooled the lines, and tied everything together. After I wired everything, the only thing left to do was upload the firmware, make any necessary tweaks, and tune everything. I already had a fair amount of experience working with Marlin firmware, and had even written custom GCode commands for some of the printers at my high school a couple years back, so this wasn’t too difficult. Learning the nuances of the hangprinter specific features took time, but ultimately everything came together and I was able to print basic models. The nozzle had a 3mm bore, so high-detail wasn’t exactly this printer’s forte, but it made vases and scaled up models decently, as long as it didn’t run out of pellets.

By almost pure luck, I managed to finish the printer and get it working by Innovation Day. So that morning, a few of the club members and I took it apart, loaded the parts into a truck, and reassembled it on-site. We ran into a problem with the D axis motor during the event that hadn’t come up while testing the printer that caused the motor to become overpowered after the hotend moved above a certain height. The cause of this turned out to be imperfect calibration and some misalignment in the ABC axes after reassembly. After taking the printer back to the machine shop and diagnosing the problem, I decided to swap the motor for a larger NEMA34 that I had on-hand so this wouldn’t happen again in the future. This turned out to be a good decision, since the printer was later moved to the campus’ makerlab for events and long-term use.

The Second Really Big Printer

Alright, calling this an active work in progress is stretching the truth a little bit, but we all have a project we keep telling ourselves we’ll finish some day, and right now this is mine. Additionally, progress hasn’t always been lightning fast, since I’m the only person working on this. I’ve tried at various points to find people to help with the design and construction, but everyone I approached either didn’t have time, or didn’t think they could be much help. Not to mention, I had acquired some funding and support through a class at the university I attend, but after a year of work and not spending all the money they allocated, they pulled the plug on it. With that said, this project is not “finished,” and so because of that some of the information here might be left in a state before the relevant stuff was made.

Right off the bat let’s start with the things I wanted to improve from the first printer: the string buildup feature in the firmware wasn’t very reliable, the build platform was too heavy for reasonable springs to hold it up, the print head twisted a lot during and after travel moves (although this wasn’t a huge problem if the nozzle was centered well), the strings being fixed at the bottom of the printer made the build volume a weird hourglass shape, and the wooden frame wasn’t robust enough to be moved, taken apart, or put back together for events. Oh, and I wanted a better way to lift it, since to move the last printer we used the machine shop’s crane with some webbing to get it out of the high bay and onto a pallet jack.

Solving the Hourglass Problem

The first thing I wanted to work out was the irregular build volume. After a lot of thought and sketches, I decided to move the string anchors up with the toolhead so they would be parallel with the build platform. This introduced a few other problems though. The biggest one was making sure that the strings going through the anchors (is that even the right word if they move) were always in tension and at the correct height. To solve this, I decided to run the strings that control the ABC axes (let’s call these the control strings) to the bottom of the anchor carriages, and then use another set of strings on a separate axis to pull the carriages up to the correct height. With that solved, the smaller problem was giving the carriages a reliable path to move along. The easy solution was t-slot aluminum extrusion, and since that would also solve the frame’s robustness problem, I just went with it. In addition to the ABC axes pulling the toolhead around, I also needed to keep the D axis from the hangprinter, since no matter how much tension I put on the strings, unless the toolhead was also pulled up from the top of the printer, there would always be sag, which would introduce inaccuracy and mess up the whole kinematic model. To sum it up, I had ABC axes to pull the toolhead around, an F axis to make sure the ABC strings stayed at the right height and parallel to the printbed, and the D axis to keep the toolhead at the correct height (catenary curves are computationally expensive). A 5-axis motion system may be a bit over-complicated, but since it would provide a lot of reliability I decided to keep it.

Stopping the Toolhead from Twisting

This was a fairly easy one to solve. I was looking at a delta printer that I had, and noticed that each axis had two arms. I removed one of the arms from each axis, noticed how much it twisted, and then put them back to see that it barely twisted at all. I drew out a free body diagram, and solved for the moments on the toolhead for different spacings of parallel strings based off of the sizes of aluminum extrusions. I settled on a 35mm spacing between strings, with 40mm extrusion profiles.

Eliminating String Buildup From The Drive System

For anyone unaware how the motion system of a normal hangprinter works, there are strings wound onto spools, and the spools are driven by motors to pull a print head through 3D space. The problem with this is that as the strings build up on the spools, the effective circumference of the spools gets bigger, and the amount that the spools need to turn to pull or release a given length of string changes. There are some ways to try and limit the error that this introduces computationally, but in the hangprinter firmware, it was (it may not be anymore) done with an equation. The problem with that is that this equation had no way of knowing if the strings were spooled perfectly, which they often were not. So the goal to eliminate the need for this compensation was a big priority.

The first thing I did was separate the spools from the parts that pull the string (let’s call them string controllers). In order to keep the string controllers as compact as possible, they consist of a stepper motor connected to a worm/worm gear with a belt reduction. The worm gear directly turns a pulley that the string is guided onto, wraps around a few times, and then is guided off of. I calculated that the theoretical precision of this would be ~25um, and the maximum speed ~80mm/sec if the motor was limited to a maximum speed of 1000rpm. I added some bearings, a couple of shafts, a housing, and it was ready to prototype. During the first test, the string slipped on the pulley a few times, so I brushed on a thin layer of silicone rubber for another test and there was no more slipping.

After the string leaves a string controller, it needs to be spooled, and tension needs to be kept on the string to prevent it from slipping in the string controller. Basically, I needed a way to keep a constant tension while spooling string onto a drum of changing circumference (same problem as before). So between the string controllers and the spoolers, I put custom designed string tension sensors. These sensors were basically a box that the string would run through, and inside the box was essentially a bearing with a spring on one end pushing it down, and a magnet on the other end. The strength of the magnet’s field is measured with a hall effect sensor, and by using a conversion, the hall effect sensor’s reading can be read as something analogous to the string tension.

Finally, after the strings run through the tension sensors, they’re guided onto spools that are driven by DC motors. The motors are driven forward/backward to pull string in/let it out based off of the tension sensor reading, controlled with a PID loop.

Supporting the Build Platform

This one I’m actually really proud of. Long story short: I came up with a new kind of bolt for leveling the platform that wouldn’t deflect under load like springs. The basic idea came about from talking to a friend of mine about how it would be great if a build platform could be rigidly supported from the underside, be retained from the top to stop it from lifting, and have some kind of pins to prevent sideways motion. A spring solved this well enough for light platforms, but this platform weighted a lot, and if you printed something big on it, the weight could really be unmanageable for anything but a small die spring. My solution: put a bolt in a bolt. A bolt head on the underside of the platform would support it from sagging and wouldn’t deflect (so long as it was threaded into something sturdy), and by threading another bolt through the top of the first one, a pin for preventing lateral motion, and a retainer on the top would also be there. With a sketch in my notebook, I started making a prototype. To make it, I took an M20 bolt, drilled and tapped it through the center for an M8 bolt, and then threaded a set screw in through the bottom, and a flat head screw in from the top. To adjust the space for different thicknesses of build platform, just screw the M8 bolt in or out, and by jamming the set screw against the M8 bolt, you could turn the whole assembly by turning the M8 bolt, allowing you to level the platform. Add three of these, and you’ve got a fully constrained build platform that can easily be leveled.

Firmware and a Kinematic Model

I’ll start with the kinematic model. To recap, I need to move 5 axes that are non-orthogonal based off of a given set of XYZ coordinates, and the origins of each axis move as a function of the given Z coordinate. To make the math easy, I made the printer’s origin at the top of the build volume, and the carriages translate at a 60° angle relative to the build platform. With those constraints, I worked out an equation to determine the location of each carriage based on the Z coordinate, and then work backwards to calculate the required length of each set of strings. This only worked out the string lengths to move in the XY plane though, and there were still two more axes to figure out. For the F-axis, it was a pretty simple calculation, just multiplying the carriage’s distance from the origin by the arcsine of 60°. For the D axis, calculating the required string length only involved the pythagorean theorem, using the distance from the toolhead to the origin, and the XY coordinates.

The main hangprinter project now has support for RepRapFirmware on Duet boards, so I’m going to use a Duet board to control everything since it has more precision and runs faster, which will help offset the extra workload from all the sine and cosine calls needed to calculate the string lengths. RepRapFirmware also makes adding a new kinematic model fairly easy and straightforward. What wasn’t so straightforward was driving the motors. I planned to use the same motors as from the first printer, but wanted to use Trinamic drivers so I’d have access to their advanced features, like StealthCop and CoolStep, instead of the previous Toshiba TB6600 drivers. I chose the TMC5160 drivers, mostly because they offered high drive current and the features I wanted, along with the normal step/dir interface and SPI.