The Rack

IMG_1441Q.jpgRecently, I wrote about one of my designs in a “non-3d-printing” web forum. Since most people over there didn’t know anything about stuff like MakerBot or RepRap, I was asked a lot of questions on 3d printing lately.

One frequent type of question was about the stability and rigidity of printed objects.

Of course, there is the normally pitched answer “it’s the same stuff Legos are made of”. And (at least in case of ABS printing) this is certainly true. But almost anytime I give (or hear) this answer, I think: … well, it depends.

Although 3D printed objects are likely out of ABS, there is one huge difference between 3D printed objects and injection mold Legos: Printed objects are layered. So when it comes to rigidity, they are much more like wood than like “atomic” Legos.
That’s why I prefer to compare printed objects -regarding rigidity- with wooden parts instead Legos.
IMG_1455.jpg
In my experience, it’s quite important to consider the layer orientation of a printed part during the design process. When building wooden objects, a stressed span is less likely to fail if tension is applied along the grain, rather than across the grain.
The same is true when printing 3D objects.

Of course, sometimes you need to compromise in order to print a complex object in one piece. And this might be ok as long as the “against the grain” parts aren’t stressed too much.
But sometimes it is way better to split a complex object into two or more parts and bolt (or glue) them together after printing, in order to get the layers into the “best” orientation for each part.

One of many examples of compound objects (to gain more rigidity) is the Adrian’s geared Mendel extruder:
IMG_1443.JPG

Technically, it woudn’t be a problem to print the base plate, the stepper motor retainer and even most of the gear retainer as one single, complex object. But then you’d have to decide in which direction you’d print the object. Besides some restrictions due to overhangs, the main problem would be that either the base plate or the motor & gear retainers would loose a lot of their rigidity when not printed “with the grain”. By breaking down the complex object into 3 or 4 parts, the whole thing not only gets easier to print, but also the assembled full object gains a lot of stability.

However, I recently began to wonder, if I could do some test to measure the strength of similar printed objects, depending on the orientation they are printed in.

To measure the rigidity and strength of printed objects, I decided to print a basic shape in different print orientations and then use a rack to rip the objects apart, measuring the needed force.

IMG_1446.JPG

Given a basic “monolith” shaped object, there are three different ways to print:

1. laying down on it’s face:

IMG_1247.JPG

This would be the “natural” orientation to print such an object for most of us 3D printer operators. Besides much less problems with printing the infill, this orientation also puts the “grain” along the widest span of the object.

2. laying on it’s side:

Although this changes the order of layers, the grain still runs along the widest span. So (besides likely more problems with printing the narrow infill), the resulting object should be as rigid and stable as an object printed laying on it’s face (1.)

3. standing upright:

IMG_1245.JPG

Printing a tall object this way usually means trouble. Not only the longest side of the object will be against the grain (and thus more likely to chip off under load), it’s also harder to print thin, tall objects on a FDM printer like the Makerbot or Reprap for several reasons.

But sometimes there’s no good way around printing a tall object in upright orientation,…

IMG_1249.JPG

4.

And then there was a fourth way to print a tall object. I had this idea a while ago and really wanted to finally try it: The object is still printed in upright orientation, but using some kind of “interlock” between the infill layers. See the following cross sections:

Instead of using a normal infill like this:

normal-infill.png

… the infill would printed in an alterning pattern like this:

bonding-infill.png

As far as I know, this kind of layer-crossing infill isn’t supported yet by any slice’n'dice utility out there.

In order to generate Gcode for the test objects, I wrote a little Perl command line tool. This script generates Gcode for “2001: A Space Odyssey” style monoliths in three different types:

“Mode 0″ – The object is printed laying down on it’s face (see above “1.”) with a normal 100% infill.

“Mode 1″ – The object is printed in upright position with a normal 100% infill.

“Mode 2″ – The object is printed in upright position with the above described interlocking “bonding infill”.

If you’d like to play around with the script, you can download it from thingiverse: http://www.thingiverse.com/thing:5069

Calling the script without arguments, shows a short usage text:

zaggo$ ./monolith.pl
Usage: ./monolith.pl --mode <mode> --out <output path>
[--lw <layer width>] [--lh <layer height>] [--fr <feedrate>]
[--lenf <length factor>] [--depf <depth factor>]
[--heif <height factor>] [--preface <path to preface file>]
Mode: 0 = flat
      1 = high
      2 = bonded
Size: lenf/depf/heif are factors of layer width
Defaults are 10 x 40 x 90 (1:4:9)

There are two mandatory attributes:

–mode defines the orientation of the object on the build platform and the infill algorithm.

–out sets an output file for the generated gcode.

So the simplest way of using the script is like this:

./monolith.pl --mode 1 --out outfile.gcode

This would generate a file (“outfile.gcode”), containing the gcode for the default monolith, printed in upright orientation with a normal 100% infill.

You can easily adjust the gcode for your needs (or your printer’s specific extruder specs) by using the optional arguments. For instance, use –lh to set a custom layer height (default is .45mm) or –lw to set a custom layer with (in mm! If not set, the script automatically calculates the layer width by multiplying the layer height by 1.4).

Since the script doesn’t generate any startup code or temperature settings, you probably want to use the –preface argument to insert custom preface gcode at the beginning of the output file. I simply use the standard preface gcode file, I also use as preface in my Skeinforge settings.

I started with objects in the default dimensions of the script and a simple unmotorized version of the rack. But it turned out, that the printed objects were way too stable for the tests and that using the rack with a wrench was really time consuming.

The pocket balance I use to measure the pulling force has it’s maximum at 25kg (about 56 lbs). During my first tests, the Mode 0 monolith chipped off at 20kg.

The Mode 2 monolith was even more stable: I was able to crank the rack up to it’s 25kg limit without breaking the monolith (with it’s grain across the pulling force!). I let the whole setup sit for a while, just to check if the monolith would withstand the pulling force for longer than just a few moments.

IMG_1305.JPG

After about 5 to 6 minutes the rack finally snapped. But it wasn’t the monolith that cracked, it was the wooden base, holding the monolith…

IMG_1371.JPG

So I printed the monoliths a little bit thinner (using the –depf argument).

Because of the thinner shape (and the resulting issues with still hot ABS in lower layers), the printed objects had slightly different dimensions (although the gcode used the same dimensions). I decided to adjust the –depf argument for each mode, so the resulting objects had the same dimensions after printing. On my Makerbot, this resulted in printing the Mode 0 monolith with –depf 8, the Mode 1 monolith with –depf 6 and the Mode 2 monolith with --depf 5.

With these settings, I got the 3 types of monoliths, all with the same thickness of 4.6mm.

IMG_1255.JPG

I also improved the rack by using an electric screwdriver as motor:

IMG_1452.JPG

The monoliths were clamped to the other end of the rack:

IMG_1448.JPG

With the thinner monoliths and the motorization, the rack worked much better and smoother:

IMG_1429.JPG

IMG_1431.JPG

IMG_1433.JPG

Here are the results of my tests:

Mode 0: 14.5kg

Mode 1: 8.5kg

Mode 2: 12kg (!)

As expected, the Mode 0 object was the sturdiest.

I’m still surprised, how stable the upright printed object (Mode 1) was. I guess, using more common infill rates (like 15 or 20%) lowers the rigidity of such objects immensely and the results would be much more than I expected. Printing the objects with an 100% infill seems really to make sense if you need a maximum of stability. I guess it would be great if there was a way to manually define parts of an object to be printed with a higher infill rate than the rest of the object.

A great success was the test of the Mode 2 object. Interlocking the infill really seems to make a big difference. The object was much closer to the stability of the Mode 0 object than the Mode 1 object. Maybe there will be a way to generate such type of infill with Skeinforge in the future…

During my tests, I ripped apart a lot more monoliths than just the three above. Although the other objects weren’t all the same size and thickness (and thus not easily comparable to the above standardized objects), the reults of the other tests went all in the same direction (Mode 0 strongest, Mode 1 weakest, Mode 2 much stronger than Mode 1).

I’ll probably try some skeinforged monoliths, with different infill rates, in the future…

Finally, here’s a short video of my tests:

Finding home

In view of my upcoming 3D printing talk at the Macoun Developer Conference in Frankfurt/Main in a few weeks, I thought that my Makerbot could use a little bit refurbishment.

Since a while it rattles a lot during printing, so at least I wanted to remove the X/Y stages from the bot, in order to clean the rods and to tighten all bolts.

I also wanted to find a better solution for the heated build platform’s cables. Until now, they somehow dangled in the back of the Makerbot on their way up to the extruder controller board.

After removing the X/Y stage from the bot, I saw another problem which needed to be solved:

Not only the acrylic build surface looks like reaching its end of life (it’s still the very first one, which came with the Makerbot kit more than a year ago), the main problem is that the whole platform has far too much play. Although my heated build platform is rather heavy (6mm aluminum + 3 big power resistors), I remember that this was also a problem with the original, unheated, wooden build platform.

I decided to bolt the aluminum plate directly to the Y stage with one central screw:

IMG_0813.JPG IMG_0814.JPG

In order to be able to easily remove the print stage, I got rid of the acrylic build platform (bolt to the aluminum plate before). Instead I tried three different “interface” sheets.

The first try was a aluminum cover for the build platform. I folded the cover out of .5mm aluminum sheet with Kapton tape as surface:

IMG_0817.jpg IMG_0821.jpg

To cut a long story short: It didn’t work. The cover wasn’t easy to install and remove from the build platform and it was impossible to get a good, leveled surface.

Next, I tried a piece of transparent LDPE. I had some leftovers of this from building the second filament box. I attached the LDPE with some foldback clips to the heated build platform.

It worked relatively well. However, the LDPE degenerates rather quick:

IMG_0863.JPG

Also I have the problem that there are only very few spots on the build platform where foldback clips can be used without blocking the build platform’s movement. Since LDPE heavily warps when heated, there just weren’t enough clips to hold it down to the flat aluminum.

Finally, I cut a sheet of thin glass (from a cheap picture frame) to 10x10cm. Like the aluminum sheet, I used Kapton tape as “interface” material for the ABS. So far, this build surface seems to work great. The glass is nicely flat and leveled and keeps it that way when heated. And two foldback clips are enough to securely attach the surface to the aluminum plate:

IMG_0859.JPG

Now, with the aluminum platform bolt down to the y stage, I was able to use a piece of ribbon cable to connect the cables from the platform with the x stage:

IMG_0824.JPG

There was a connector on one end of the ribbon cable (it used to be a part of an old PC’s RS232 access), I glued this end of the cable to the y stage. After soldering a compatible connector to the platform’s wires, I was able to connect the heated build platform in a way which allows easy removal if needed.

IMG_0823.JPG

Up until half way, I glued the ribbon cable to the x stage’s edge. Then the cable runs inside the drag spring from the x stage to the outside of the Makerbot. I already had the drag spring installed about a year ago to guide the y stepper motor’s and the y end stops’ cables.

Here’s a short video of the ribbon cable during a print:

It works great!

After playing around with my Mendel for a while, I very much like the autohoming feature of it’s firmware.

When I browsed the current Makerbot firmware, I was surprised to find support for automatic homing, ready to use. As far as I know, this code is currently not used by ReplicatorG, right?

Anyway, having endstops installed for the X and Y stage, it’s no problem to autohome these stages with the current firmware.

Just send the G-Codes G28, G161 or G162 with information on the axis to the Makerbot:

G28 is the “normal” ‘return to home’ G-code, also used by the RepRap firmware. However, in the Makerbot firmware, there are two more variants of the homing functions:

G161 is ‘home negative’, which means, that the respective stages are moved in direction of the MIN endstop until they reach the end of the line. Currently, G28 and G161 are exactly the same in the Makerbot firmware.

G162 is ‘home positive’, which means, that the respective stages are moved in direction of the MAX endstop until they reach the end of the line.

Concerning the X and Y stage, you might use either of them to bring the Makerbot into a “well known position”. If you have installed all four MIN/MAX endstops for the X&Y stages, that is.

In case you have only one endstop per axis you should call G161 for those axes with a MIN endstop and G162 for those axes with a MAX endstop.

My Makerbot, for example, has only one endstop per axis: MAX on the X axis, MIN on the Y and Z axes. So in order to home my Makerbot, I’d send

G162 X
G161 Y Z

The Z-axis endstop isn’t as easy to install as the X/Y endstops. Depending on the build platform and/or extruder or frostruder you’re using, the Z-axis endstop needs to be adjusted for the correct height.

Quite a while ago, I already tried some possible solutions on my Makerbot. Back then, I designed the Z-stage endstop trigger (my very first published thing on Thingiverse!). I also designed  a X-stage endstop trigger and an adjustable Z-stage endstop trigger. But since I wasn’t too happy with the results, I never published these.

IMG_4266.JPG

I always thought, that the best way to do homing of the z-stage would be a probe as near as possible to the nozzle, sensing the actual build surface.

I also did some test on this back a year ago, but again the results weren’t too promising:

IMG_4162.JPG

The main problem is, that the probe needs to be retractable during the print process. A year ago I tried to solve this with a manual retraction mechanism. But it didn’t work reliably. Also, adjusting the probe wasn’t very easy.

More than a year later, I learned a lot about electronics, microcontrollers and embedded systems programming…

So here’s what I came up with:

IMG_0846.JPG

The Z-Probe

This new design contains a standard endstop PCB and a needle-like sensing-probe. The head of the sensor is motorized retractable with help of a standard servo.

IMG_0852.JPG

The Z-Probe is designed to be mounted behind/under the extruder on the z-stage:

IMG_0855.JPG IMG_0856.JPG

That way, the Z-Probe is able to sense the build platform only 1-2 cm from the nossle.

The servo, lowering and rising the sense-pin, is controlled by the extruder controller board. There are two digital pins on the extruder controller board v2.2, currently unused on a Makerbot (D9 and D10).

These pins are ready to use with a servo. Just plug the servo connector to the 3 pins of D9. Make sure to put the black wire (GND) on the pin marked with “-”:

IMG_0865.JPG

Of course, some firmware/host software changes are needed in order to drive the Z-Probe.

The D9 and D10 pins are even PWM enabled. So usually it’s quite easy to add support for servos on an Arduino controller.

Unfortunately, since v2 of the extruder controller firmware Adam from Makerbot Inc. decided to move away from the Arduino IDE and API. The firmware is now “native AVR”, i.e. no more access to the Arduino libraries. Of course, there are several valid reasons to abandon the Arduino IDE, especially when projects grow and get more complex. But this also makes it harder  to “hack” the software.

What’s even worse: The current firmware already uses the hardware timer of the ATMega, which ususally drives the PWM pins D9 and D10. So I needed quite a while to understand how to solve these problems.

I think, I’ve found a way to solve the problem with the timer. The current firmware uses this timer for a general software interrupt routine. So I hooked the servo driver for the z-probe into the same interrupt routine.  So the servo PWM signal now is created by the CPU in software (and not by the hardware PWM driver). I tried some other ways around this timer conflict, but this was the only way both, the servo and the rest of the firmware, are working. I guess it’s not the best idea to mess around with one of the firmware’s central timers…

After solving these problems, I was able to extend the firmware with a new class “ZProbe”. This class handles the lowering and raising of the ZProbe hardware.

The upper and lower positions of the ZProbe are configurable in the extruder’s EEPROM preferences (well, they will be, as soon as I’ll find the bug which currently prevents the firmware to write new values to the preferences…).

In order to control the Z-Probe from within Replicator-G and -even more important- from within G-Code files, I added some new “M-Codes” to the GCode-Parser: M140, M141 and M142

M140 “Engage Z-Probe”: This M-Code lowers the Z-Probe into working position.

M141 “Disengage Z-Probe”: This M-Code raises the Z-Probe into parking position.

M142 “Adjust Z-Proble Angle”: This M-Code takes a S argument and moves the Z-Probe’s servo int the given angle (e.g. M142 S45 moves the servo to 45°). This code is intended for internal use only.

One thing to keep in mind is, that the zeroed Z-stage with engaged Z-Probe mustn’t be moved in X or Y direction. Since the Z-Probe pin touches the build surface in this case, moving the build platform could cause scratches in the build surface or -worse- damage of the Z-Probe itself. So always either disengage the Z-Probe or raise the Z-stage a little before moving the X/Y stage.

Here’s the G-Code for a complete autohome sequence on a Z-Probe equipped Makerbot:

G21 (Metric FTW)
G91 (relative positioning)
G0 Z7.0 (move up the z-stage for security)
M141 (Disengage Z-Probe)
G90 (Absolute Positioning)
G162 X (home positive)
G161 Y (home negative)
G92 X0 Y0 (Reset reference position)
G0 X-55.0 Y20.0 (Center ** Z-Probe-Pin **)
G92 X0 Y-25 (Reset reference position)
M140 (Engage Z-Probe)
G161 Z F500 (home negative [fast])
G92 Z0 (Reset reference position)
G0 Z2.0 (Back up z-stage 2mm)
G161 Z F25 (home negative [slow])
G92 Z0 (Reset reference position)
M141 (Disengage Z-Probe)
G1 F150 (Reset Z-speed)
G0 Z1 (backup Z for Y move)
G0 Y0 (center Y *** Nozzle ***)
G0 Z0 (return Z to zero)

Of course, this G-Code would need to be adjusted if the Makerbot has an other endstop configuration than mine. Also the ‘move to center’ distance is likely different on each Makerbot.

Here’s a video, showing my Makerbot while running the above G-Code:

As you can see, the Z-Probe just works, even if the height of the build platform was changed. No manual adjustmens needed. This is not only a nice feature for operators using differnt types of build platforms or surfaces, it also might be quite useful for people using the brand new Automated Build Platform.

You want?

First and frontmost: This is all still in a very early stage, both hardware and software.

I released the printable parts for the Z-Probe on Thingiverse: http://www.thingiverse.com/thing:4093

The design is for use with a Futaba servo S148. That’s the servo I found in my junk box. I guess each servo has a different size. So the design might be more a draft for your own design. I plan to try the same thing with a smaller (and cheaper) “micro servo” in the future. I hope I’ll find the time to create a parametric OpenSCAD design until then.

Since it’s still a prototype, the servo is currently glued to the base plate with some hot glue.

Both, the new extruder firmware as well as the extended ReplicatorG host software, are available on GitHub. I forked both projects from Makerbot:

G3Firmware: http://github.com/zaggo/G3Firmware

ReplicatorG: http://github.com/zaggo/ReplicatorG (ZProbe branch)

Please remember: This is all beta (at best). As mentioned above there’s still a known bug with saving the Z-Probes EEPROM settings.

Feel free to improve!

Test Drive

IMG_0639.JPG

As you know, I’m working on the long term project, using Mecanum wheels for a robot with omnidirectional driving capabilities.

Today, I received the gear motors for my Mecanum wheel chassis prototype:

IMG_0645.JPG

These are 12V gear motors with a 1:50 gear reduction. The spindles are running at approx. 104 RPM.

To drive these motors from an Arduino Duemilanove, I use the motor shield from ladyada.net (at least for the prototypes).

IMG_0646.JPG

Here’s a short video of testing the controller/motor setup:

Already having printed all 4 Mecanum wheels, I thought I would be nice to assemble the whole shebang and give it a test drive.

All combat takes place at night, in the rain, and at the junction of four map segments.

Robert De Niro in “Wag the Dog”

Well, there were some bumps on the road.

When designing the Mecanum wheel, I planned to use them with stepper motors. Although it’s generally nice to have exact control of the (stepper) motors’ RPM, I’m sure that the wheels’ slipping on the ground is quickly killing this advantage. Because of the much simpler controller electronics, I switched over to the above mentioned gear motors.

The main problem here: The stepper motors have a 5mm spindle, the gear motors have 6mm spindles. Thus, I ended up with 5mm bores in the wheels for the 6mm gear motor spindles.

I re-drilled the center bores in the Mecanum wheels with a 6mm drill. After that, the wheels fit on the motor spindles but -of course- now the captive M3 nuts for the spindle set screws didn’t fit anymore.

To solve this problem, I needed to file down 4 M3 nuts to about half their height:

IMG_0649.JPG IMG_0661.JPG

Although this solved the problems with the changed spindle diameter, the whole process most likely didn’t enhance concentricity of the wheels. Printing a new wheel (without the rollers), takes more than an hour. Cleaning up the printed object, glueing in the ball bearings and assembling the rollers takes at least another hour. Since it’s a prototype anyway, I  chose to go with the fast, easy and maybe less precise solution.

I mounted the four motors with some quick and dirty printed clamp assemblies to a plywood base plate.

IMG_0655.JPG

The clamps were printed relatively quick and they give me some freedom in (re-) adjusting the motor/Mecanum wheel positions. However, this sort of mount mechanism might not be ideal for long time use.

And here’s what the first prototype looks like:

IMG_0653.JPG

The black Mecanum wheel in the front right is the first I printed. I had no liquid rubber then and I didn’t find the time and mood to completely disassemble the wheel in order to apply the liquid rubber to the rollers, yet.

The Arduino controller runs a pretty simple test sketch in the following movie, to test the four general drive modes (forwards, backwards, left, right):

Now I need to beef up the robots sensors and firmware. I really like the idea to add a gyroscope to recognize wanted and unwanted direction changes. And, of course, the thing definitely needs some kind of collision sensors…