DIY 3D printer project

leftangledview-600

Frank documented a 3D printer build, called Hephaestus:

I finally did it, I designed and built my own 3D printer. This is in no way “the best 3D printer”. Instead, this was an epic and nightmare project that exercised my ability to engineer and build my own CNC machine. Along the way, I figured out what I did well and what I did badly, mistakes were made and sometimes fixed, even ignored.

You can find the build log on Eleccelerator project page.

Ultra MegaMax Dominator (UMMD) 3D printer

new extruder carriage

has a nice write-up about building his Ultra MegaMax Dominator (aka UMMD) 3D printer:

Ultra MegaMax Dominator (aka UMMD) is my third 3D printer design/build.  I used much of what I learned from its predecessors, and tried a few experiments, resulting in a very high quality machine that produces very high quality prints.  Time will tell if it meets my reliability goals.

See the full post on Mark Rehorst’s blog.

Ardu McDuino Plays the Bagpipes

To “pipe in” the new year, [John] decided to build a bagpipe-playing robot. Unlike other instrument-playing robots that we’ve seen before, this one is somewhat anatomically correct as well. John went the extra mile and 3D printed fingers and hands to play his set of pipes.

The brains of the robot are handled by an Arduino Mega 2560, which drives a set of solenoids through a driver board. The hands themselves are printed from the open source Enabling the Future project which is an organization that 3D prints prosthetic hands for matched recipients, especially people who can’t otherwise afford prosthetics. He had to scale up his hands by 171% to get them to play the pipes correctly, but from there it was a fairly straightforward matter of providing air to the bag (via a human being) and programming the Arduino to play a few songs.

The bagpipe isn’t a particularly common instrument (at least in parts of the world that aren’t Scottish) so it’s interesting to see a robot built to play one. Of course, your music-playing robot might be able to make music with something that’s not generally considered a musical instrument at all. And if none of these suit your needs, you can always build your own purpose-built semi-robotic instrument as well.


Filed under: musical hacks

Where There’s Smoke, There’s a Knockoff 3D Printer

These days, it’s possible to buy clones of popular 3D printers from China for satisfyingly low prices. As always, you get what you pay for, and while usable, often they require some modification to reach their full potential. [g3ggo] recently laid down €270 for a clone of the Prusa i3 by Geeetech, knowing it would require some modifications for safety and performance.

First on the bill was a wobbly Z-axis, which was dealt with by printing some new parts designed to fix this issue which have already been developed by the community. Forums are your friend here – often an enterprising user will have already developed fixes for the most common issues, and if they haven’t, you can always step up to be the hero yourself. There was a darker problem lurking inside, though.

[g3ggo] began to wonder why the MOSFETs for the hot end were running so hot. It turned out to be an issue of gate drive – the FETs were only being driven with 5V, which for the given part, wasn’t enough to reach its lowest R_DS(on) and thus was causing the overheating issue. It gets worse, though – the heatsinks on the MOSFETs were bolted on directly without insulation, and sitting fractions of a millimeter above traces on the PCB. Unfortunately, with a small scratch to the soldermask, this caused a short circuit, destroying the hot end and MOSFETs and narrowly avoiding a fire. This is why you never leave 3D printers unattended.

The fix? Replacing the MOSFETs with a part that could deal with a 5V gate drive was the first step, followed by using insulating pads & glue to stop the heatsinks contacting the PCB. Now with the cooler running MOSFETs, there’s less chance of fire, and the mainboard’s cooling fan isn’t even required anymore. Overall, for a small investment in time and parts, [g3ggo] now has a useful 3D printer and learned something along the way. Solid effort!


Filed under: 3d Printer hacks

Derek Schulte: Path Planning for 3D Printers

[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.

The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)

The Problem

spaghettiPath planning goes on inside the 3D printer itself. It’s what the 3D printer’s firmware does with the received G-code that turns it into the physical motion of motors along the X, Y, and Z axes as well as the extruder. While G-code is universal, it’s also unrealistic: it specifies a series of points in 4D space (the extruder, remember?) and the speeds that are needed to get there. Path planning blends knowledge of the physical printer’s motion control abilities and tries to make the end result match the G-code as much as reasonably possible, without taking forever. Being the interface between idealized G-code and a real printer, the planning firmware needs to take the design of the printer itself, with all its physical limitations, into account.

simpleYou can make your own, one-off, 3D printer out of unobtainium, dragon scales, and the unbilled labor of a year’s worth of weekends. But if you want to make a product to sell to the general public at a reasonable price, it’s got to be built using commodity parts and work robustly. This is what drove [Derek] to use a DC motor with an encoder instead of the ubiquitous, heavy, and relatively expensive stepper motors that most other 3D printers use. Driving DC motors in open-loop feedback meant that none of the “standard” printer firmwares were going to work — he needed to roll his own. And that’s how we have this talk, about getting from A to C, around the corner in B, as quickly and accurately as possible.

Trapezoids, and the KISS Principle

There are a few ways to turn a piece of G-code that says “go north at 50 mm/sec and then go west at 50 mm/sec” into machine movement. One is to go north at full speed, slam to a stop, and then jerk off west at full speed. This is what the earliest versions of DIY 3D printer firmware did — and the result was noise, and vibration of the print head, and degradation in print quality. These were ugly times.

trapezoid[Derek], and the path planner in grbl, chose the next most complicated solution — moving at constant acceleration for each segment of the path, resulting in trapezoidal velocity profiles. This turns out to work decently well in practice and be easy to compute. [Derek] added corner rounding to the routine: where the G-code said to make a sharp corner, the firmware would take a curved corner that’s close enough that it wouldn’t look bad, but also doesn’t require the nozzle to slow to a stop. Combining the two is basically the simplest solution that can work well.

Connecting a few segments together is the next step, but it lets the printer eventually come to a stop, whether at the end of the path or because a user pressed the pause button.

Closed-loop Control

Most stepper-driven 3D printers operate in open-loop control mode. The firmware tells the stepper motor driver to take ten steps forward and hopes for the best. When a printer loses steps, layers get de-aligned from each other, and if you’ve had this happen catastrophically in the middle of a print, you know why this can suck.

stall[Derek]’s printer runs in closed-loop mode, meaning that if the printhead is too far south of where it should be, the firmware can tell that this is the case and apply more power to a motor to get it back right. Again, [Derek] chose one of the simplest methods that could work: PID control with feedforward. Of course, this means calibrating the algorithm to the machine, but a well tuned PID algorithm is a joy to watch.

And the closed control loop provides additional benefits. Where stepper motors have to be way overspecified to avoid the dreaded missed steps, closed-loop DC motors can get by on lower torques. The coolest trick that [Derek] plays with the feedback, however, is in using the ability to detect motor stall to home the printer. There are no limit switches on the three physical axes. Instead, when the motor hits the end of its ability to move, the firmware detects the stall and uses this to zero the coordinate axes. This reduces parts and simplifies the device. We’re all for that.

Conclusion

kiss[Derek] designed his motion planning routines on the same tools that we all use, and used basically the simplest possible algorithms that would work well, avoiding “academic” complications for their own sake. In the end, this allowed him to optimize for speed, look fifteen steps ahead, include some necessary special tweaks like logic for dealing with very short segments and get the product out the door for a reasonable price. Motion planning and control in a closed-loop system is never simple, but “apply the KISS principle as far as possible and then tweak for performance later” is something that all of us hackers could stand to get tattooed on some suitably long part of our bodies. Better still, let’s just thank [Derek] for the reminder and exemplification!


Filed under: 3d Printer hacks, cons, Hackaday Columns

Derek Schulte: Path Planning for 3D Printers

[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.

The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)

The Problem

spaghettiPath planning goes on inside the 3D printer itself. It’s what the 3D printer’s firmware does with the received G-code that turns it into the physical motion of motors along the X, Y, and Z axes as well as the extruder. While G-code is universal, it’s also unrealistic: it specifies a series of points in 4D space (the extruder, remember?) and the speeds that are needed to get there. Path planning blends knowledge of the physical printer’s motion control abilities and tries to make the end result match the G-code as much as reasonably possible, without taking forever. Being the interface between idealized G-code and a real printer, the planning firmware needs to take the design of the printer itself, with all its physical limitations, into account.

simpleYou can make your own, one-off, 3D printer out of unobtainium, dragon scales, and the unbilled labor of a year’s worth of weekends. But if you want to make a product to sell to the general public at a reasonable price, it’s got to be built using commodity parts and work robustly. This is what drove [Derek] to use a DC motor with an encoder instead of the ubiquitous, heavy, and relatively expensive stepper motors that most other 3D printers use. Driving DC motors in open-loop feedback meant that none of the “standard” printer firmwares were going to work — he needed to roll his own. And that’s how we have this talk, about getting from A to C, around the corner in B, as quickly and accurately as possible.

Trapezoids, and the KISS Principle

There are a few ways to turn a piece of G-code that says “go north at 50 mm/sec and then go west at 50 mm/sec” into machine movement. One is to go north at full speed, slam to a stop, and then jerk off west at full speed. This is what the earliest versions of DIY 3D printer firmware did — and the result was noise, and vibration of the print head, and degradation in print quality. These were ugly times.

trapezoid[Derek], and the path planner in grbl, chose the next most complicated solution — moving at constant acceleration for each segment of the path, resulting in trapezoidal velocity profiles. This turns out to work decently well in practice and be easy to compute. [Derek] added corner rounding to the routine: where the G-code said to make a sharp corner, the firmware would take a curved corner that’s close enough that it wouldn’t look bad, but also doesn’t require the nozzle to slow to a stop. Combining the two is basically the simplest solution that can work well.

Connecting a few segments together is the next step, but it lets the printer eventually come to a stop, whether at the end of the path or because a user pressed the pause button.

Closed-loop Control

Most stepper-driven 3D printers operate in open-loop control mode. The firmware tells the stepper motor driver to take ten steps forward and hopes for the best. When a printer loses steps, layers get de-aligned from each other, and if you’ve had this happen catastrophically in the middle of a print, you know why this can suck.

stall[Derek]’s printer runs in closed-loop mode, meaning that if the printhead is too far south of where it should be, the firmware can tell that this is the case and apply more power to a motor to get it back right. Again, [Derek] chose one of the simplest methods that could work: PID control with feedforward. Of course, this means calibrating the algorithm to the machine, but a well tuned PID algorithm is a joy to watch.

And the closed control loop provides additional benefits. Where stepper motors have to be way overspecified to avoid the dreaded missed steps, closed-loop DC motors can get by on lower torques. The coolest trick that [Derek] plays with the feedback, however, is in using the ability to detect motor stall to home the printer. There are no limit switches on the three physical axes. Instead, when the motor hits the end of its ability to move, the firmware detects the stall and uses this to zero the coordinate axes. This reduces parts and simplifies the device. We’re all for that.

Conclusion

kiss[Derek] designed his motion planning routines on the same tools that we all use, and used basically the simplest possible algorithms that would work well, avoiding “academic” complications for their own sake. In the end, this allowed him to optimize for speed, look fifteen steps ahead, include some necessary special tweaks like logic for dealing with very short segments and get the product out the door for a reasonable price. Motion planning and control in a closed-loop system is never simple, but “apply the KISS principle as far as possible and then tweak for performance later” is something that all of us hackers could stand to get tattooed on some suitably long part of our bodies. Better still, let’s just thank [Derek] for the reminder and exemplification!


Filed under: 3d Printer hacks, cons, Hackaday Columns

RooBee One, an open-source SLA/DLP 3D printer

[Aldric Negrier] is no stranger to the 3D printing world. Having built a few already, he designed and built an SLA/DLP 3D printer, named RooBee One, sharing the plans on Instructables. He also published tons of other stuff, like a 3D Printed Syringe Pump Rack and a 3D Scanning Rig And DIY Turntable. It’s really worth while going through his whole Instructables repository.

This open-source 3D printer was inspired by the Cristelia – SLA/LCD 3d printer and the Vulcanus MAX 3D printer (that he designed). RooBee One has an aluminium frame and an adjustable print area of 80x60x200 mm, with up to 150x105x200mm build volume using an ACER DLP projector. In addition, a fan on top of the printer was added to extract the toxic vapours outside and away from the printer operator. The electronics are based on the Arduino MEGA with the RAMPS 1.4 shield and one NEMA 17 stepper motor. As for the Arduino Mega firmware, [Aldric] choose to use Repetier, which he usually uses in his other printers.

The SLA resin he used is the Standard Blend Resin from Fun to Do Resins. These resins tend to release toxic airborne particles, so extra care should be taken to ventilate the area while printing and also do a proper cleaning afterwards.

You can get a glimpse of the printer making a small gear come to life in the following video:

We’ve contacted [Aldric] and he says that if you are not willing/able to make one with the Instructable, RooBee One will soon be on sale in his shop at RepRapAlgarve for 599€.

 


Filed under: 3d Printer hacks

IKEA Table 3D Printer

In this Instructable, [Wayne Mason-Drust] shares the step by step guide on how to make a cool, good-looking, 3D printer based on the Ikea LACK table. From an Ikea lantern weather station to a fully printed CNC based on an Ikea table, it’s almost safe to say that a 3D printer Ikea hack was overdue.

The idea to use a Ikea table as a base for a 3D printer first came to [Wayne] as he used this table to support other 3D printer he had working in his business. He realized that, even after five years of use, the table showed no signs of wear or distortion. So he decided to start to work on a 3D printer based on this precise table, the one that used to hold the printer.

[Wayne] stacked two together and named it Printtable (pun intended?). This open source, cartesian rep-rap 3D printer looks pretty slick. With a build area of 340mm X 320mm and 300mm on the Z axis and a price tag for the parts starting as low as $395, seems like a pretty decent 3D printer. With some work sourcing the parts, maybe it can be even lower.

Or we can just wait until Ikea starts selling them.

You can watch a working Printtable here, printing and looking good:

[Thanks Quick] [via IkeaHackers]


Filed under: 3d Printer hacks

3D Printed Greeting Cards

T’is the season to hack, and the maker brigade won’t disappoint — there’s no better way to crank out a few cute holiday tchotchkes than to fire up the 3D printer. [Niklas Roy] has released gDraw, a software package that creates G-code to print out 2D drawings on your 3D printer.

The interface is simple, allowing the quick and easy creation of basic vector drawings. The program then converts the paths in the drawing to a G-code representation that your printer follows to squirt them out in plastic. Think of it as the 3D printed equivalent of the “Stroke Path” tool in Photoshop.

[Niklas] chose to demonstrate the software by creating some interesting greeting cards that Big Christmas is sure to rip off next year and sell for $30 a pop. The printed plastic drawings give a fun 3D effect to the cards, and we’d love to see more examples of art created with this technique. The software was designed to work with the Ultimaker 2, but with tweaks, it should be able to generate code for other printers, too.

We’ve seen plenty of great festive hacks over the years — like this awesome laser projection setup.


Filed under: 3d Printer hacks, Holiday Hacks

Inside the Printrbot Printrhub

A new version of the Printrbot Simple was released this summer, and this sleek new model includes a few highly desirable features. The metal enclosure was improved, linear rails added, a power switch was thrown in, and the biggest feature — a touch screen — makes headless printing easy.

Adding a usable display and achieving reliable WiFi are big engineering challenges, and thanks to the Internet of Things it’s only going to become more common to expect those features. How did the Printrbot team implement this? [Philip Shuster] recently released a write-up of how the Printrbot Printrhub came together.

The story of the display and WiFi module in the newest Printrbot begins about a year ago with a post on Hackaday. [Philip] built the Little Helper, a little electronic Swiss Army knife capable of basic IO, sending out PWM pulses, sniffing I2C, and a few other handy features. The Printrbot team reached out to [Philip], and after a few conversations, he was roped into the development team for the Printrhub.

Departing slightly from the Little Helper, the Printrhub features the same microcontroller found in the Teensy 3, a 2.8 inch TFT display, capacitive touch sensor, microSD card slot, and an ESP-12 module to handle the WiFi connection. The display system was tricky, but the team eventually got it working. Using an ESP8266 as the WiFi module for a printer is more difficult than you would think, but that works too.

One of the more interesting challenges for 3D printers in the last few years is the development of a good printer display with wireless connectivity. Yes, those graphic LCDs attached to an Arduino still work, but a display from 1980 doesn’t sell printers. In just a few months, the Printrbot team came up with a relatively simple, very elegant display that does everything and they’re releasing all the hardware as open source. That’s great news, and we can’t wait to see similar setups in other makes of 3D printers.


Filed under: 3d Printer hacks