I finished my thing that lets you attach your iPhone to your Prusa Mendel for easy time-lapse movie creation:
It slips onto your threaded rods and attaches to PrintTo3D’s iPhone stand with a printable peg. It took several iterations to get it right. Here are all the versions, first try on the left and final copy on the right:
The first one was simply too short, so I lengthened the front for the second draft. But as you can see, the hole that that the pin goes into wasn’t reinforced enough, so it broke. Version 3 reinforced the hole area, but once I attached the clip to my machine, I realized that it held the phone so close that the build platform could bump into it. Oops. versions 4 corrected that with a longer neck, but then I discovered that the angle I’d chosen for the pin hole resulted in the phone being awkwardly rotated. Version 5 fixed that, but at this point I realized that the hole was too wide and the pin wasn’t snug enough to hold the phone totally stable. Finally, version 6 all the way on the right is what I uploaded to Thingiverse.
Without further ado, here’s a time lapse movie this thing helped me create, of the ubiquitous Pink Panther Woman:
One final note is that you really need a dedicated app for time-lapse movies. I tried taking a video with the camera and speeding it up in iMovie but this got old real fast because the video was huge so it took forever to copy and alter. I like OSnap! Ultimate Time Lapse, which goes for a measly $2.99.
So about that time I blamed Marlin for a printing problem… yeah…
Turned out to be a good ol’ case of PEBKAC: I was printing the model too large, so when the printer tried to move the extruder to a location that would be outside the printable area, the motor (logically) stopped moving it in that direction once it hit the edge. But that meant that the extruder was out of sync with where the printer thought it was, so when it moved back in the other direction, it went too far and the layers became skewed. The problem’s reproducibility came from the fact that it was the same layer every time that had a part of it dangling outside of the printable area. Solution: move the piece back inside the printable area or scale it down a bit. And of course, when I do my part, the printer does likewise. And now, finally, days later, I’ve been able to complete this large print:
The model was designed by my friend Rust This World, and it looks pretty darn cool mostly-assembled:
While I was investigating the peculiar problem that was afflicting my latest large print, I ran into a recurrence of an old problem: starting from the very beginning of the print, each successive layer was slightly offset in one direction from the one beneath it. This turned out to be a fairly simple issue: the Y-carriage timing belt was scraping against the fender washer that prevents it from slipping off its bearing, and while staying on the bearing is certainly preferable, the extra friction was not.
So the Y-carriage was binding as it moved back and forth, causing the characteristically misaligned layers. A good solution to this problem has already been designed by triffid_hunter: a grooved cylinder that slips over the bearing to keep the belt centered:
Unfortunately, because this slips over the bearing, the bearing can’t already have a rod stuck through the middle of it. So what if you don’t want to have to spend two hours disassembling half your machine just to put spacers on two ball bearings? Then you need a flange on your motor pulley to keep the belt centered to begin with. Even though a groove on the bearings to constrain the belt is a good idea anyway, the the root cause of the misalignment in the first place is that the standard printed RepRap pulley has no constraining flange, so as it rotates, the belt slides up and down its length. Most RepRaps use belts that are 5 millimeters wide, so a flange about 6 mm away from the hub would be good. For a variety of good reasons, I don’t use printed pulleys, though; I bought some precision manufactured ones. Unfortunately, while my pulleys already have constraining flanges, they’re too far away to do any good!
Being the lazy bum that I am, I decided that designing and printing a spacer for my motor pulley would be easier than taking apart the whole machine to put triffid_hunter’s guides on the bearings. So that’s what I did:
Update: This was a case of PEBKAC. The problem had nothing to do with Marlin in the end.
I’d been merrily printing things at blazing speed (such as this SimCity 2000 building) and I’ve been really happy with Marlin’s ability to not only print faster, but smoother at the same time. Unfortunately, I’ve run into what I believe to be a reproducible bug in the firmware. I have a 3 or so hour print, and after a while, the printer abruptly starts printing each layer farther off to the right:
I’m using Replicatorg of course, and after printing the same model three times (second and third printed with a different gcode file after re-skeining), the same thing happens in the same place at the same time. I checked out the gcode in Skeinlayer and it’s fine; it’s definitely not telling the printer to make the mess shown above!
I’ll mention at this point that I changed Marlin’s baud rate to 115200 to get it to work with Replicatorg. Yeah, yeah, I’m a bad person and all that. I decided to try printing the same gcode file with Pronterface, keeping the 115200 baud rate to see if it was my fiddling with the baud rate or Replicatorg. With Pronterface, it exhibited the exact same problem, albeit it started messing up immediately rather than waiting two hours (how considerate!). I then returned the baud rate to the normal 250000 and printed the same gcode file with Pronterface once again and got the exact same result as when I printed that file at 115200 baud. So it’s definitely the firmware’s fault.
I’ve asked the Marlin devs for help, but in the meantime, it’s back to Sprinter once again…
It turned out that getting Marlin to work with Replicatorg was drop-dead simple. All I needed to do was change the baud rate in the firmware to match the baud rate listed in the reprap.xml config file. Duh! In the past I tried changing the baud rate in the config to match what was in the firmware, but that didn’t work for some reason. Altering the baud rate in the firmware is the way to go. And that’s it; it just works. And the result?
It’s a goddamn print monster.
My Prusa is now buttery smooth. There’s just no other way to describe it. No more jerky movements; no more bubbles on corners; Marlin makes your extruder carriage seem like it’s floating on a cloud. The printer’s every movement becomes not only more graceful, but quieter. My Prusa is truly near silent now. While playing music at a low volume, I literally can’t hear the printer when it’s printing not 18 inches from my head. The loudest noise now is the faint squeak of threaded rod against M8 nut when it changes layers.
Don’t take it from me; see for yourself:
You’re gonna have to turn up the sound to hear anything, even with the camera about 8 inches away. That’s a Weighted Storage Cube being printed at 50 mm/sec for perimeters and 100 mm/sec for infill. I’m sure in practice it’s not quite reaching those speeds due to the small size of the object, but just look at that extruder zip around!
For even more awesome, grab this improved reprap.xml file for Replicatorg, made by ccotter247. Apparently, there was an easier way to get the extruder motor controllable from the Replicatorg control panel: remove the steper_axis variable from the machine config. Between that and my fix, this should Just Work™ in the future.
That’s right, a Y-carriage, designed by tommyc. It’s a truly excellent piece, full of clever and well-thought-out features. Before today, my print bed was attached to a piece of MDF with four LM8UU bearing holders screwed to it, but this was a poor solution because:
The bearing holders attached with two screws, locking their rotation. Coupled with the fact that I didn’t make sure enough that they were straight, my Y-axis had too much resistance, forcing the motor to work too hard. I suspected that this was part of my layer alignment problem.
There was a lot of wasted open air between the bottom MDF sheet and the print bed due to the unnecessarily tall belt tensioner I chose.
The (probably fairly low quality) Chinese LM8UU bearings were touching the mounting screws for the bearing holders, causing them to rust. Stainless steel these things ain’t.
Today I replaced that whole problematic assembly with this printed part, and doesn’t it just look smart, waiting for me to attach a print bed:
Among its nice features are the built-in belt tensioner, which is more compact than the one I was using before, and I managed to wriggle another 10 millimeters of build height out of my machine. Score! But the bigger win is that it attaches to the print bed in four places, not three. You might think this is unnecessary or even a downgrade, but that whole only-need-three-points-to-define-a-plane thing only works if you’re actually defining a plane. My jigsawed MDF sheet isn’t exactly precision engineered, and I soon unhappily discovered that with three attachment points, even when the bed was level at those points, it wasn’t level the farther the nozzle got from them. Clamping the bed down at all four corners blew the crap outta that problem.
Finally, I also took the opportunity to use a more secure attachment mechanism. The last time I attached the build platform to the bottom MDF sheet, I used long M3 bolts and springs without enough tension for the length. As a result, the top platform was attached, but could wobble and vibrate around, especially when doing the infill in thin areas. I substituted M4 bolts and a more secure attachment method:
The spring is compressed more, giving it greater resistance. Also the M4 bolt is held in place by nuts on both sides of the attachment point, which not only keeps the bolt from wobbling, but it also let me lock it down once the bed has been leveled.
The results: the smoother travel and the non-vibrating print bed caused my layer alignment problems to be TOTALLY ELIMINATED:
Words cannot contain my joy over how beautifully aligned those layers are. A vibrating print bed will really mess up your prints. Take it from me and lock that sucka down!
I submitted my first patch (or “pull request” in git-parlance) to Replicatorg to fix issue #4 that I wrote about in this earlier post. As usual, the most challenging part was actually figuring out what part of the code was being called where, i.e. just what in the heck is going on. Once I got a handle on the flow, it was really quite a simple fix; in fact, somebody had even left a comment in the code basically saying “hey, I think this will break things”:
// TODO: Reverted to separate commands for enable + extrude + disable. This probably breaks 5D
machine.runCommand(new replicatorg.drivers.commands.EnableMotor());
machine.runCommand(new replicatorg.drivers.commands.Delay(extrudeTime*1000));
machine.runCommand(new replicatorg.drivers.commands.DisableMotor());
Yeah, you’re darn right it breaks 5D! That’s the driver used for RepRap machines, so of course the functionality didn’t work. I special-cased in working behavior for the 5D driver, since no other drivers seem to exhibit the problem:
// Reverted to one single command for RepRap5D driver
if (machine.getDriver().getDriverName().equals("RepRap5D")) {
machine.runCommand(new replicatorg.drivers.commands.EnableMotor(extrudeTime*1000));
} else {
machine.runCommand(new replicatorg.drivers.commands.EnableMotor());
machine.runCommand(new replicatorg.drivers.commands.Delay(extrudeTime*1000));
machine.runCommand(new replicatorg.drivers.commands.DisableMotor());
}
I think this change will really benefit RepRap users. Replicatorg will be a real first-class host app lacking no major functionality.
Turns out there’s a relatively easy solution to Marlin’s connectivity problems on Sanguinololu boards: in Marlin.pde, change BUFSIZE from 8 to 4. Now it works like a charm and you can turn your perimeter federate back up to 50 mm/sec and your infill feed rate basically as high as you want. I’ve only gone as high as 100 mm/sec but it looks like it go even higher. Now my next step is to get Replicatorg to support Marlin so I can use it for my stable setup…
Bluebot’s Ultimaker prints are just amazing. I mean, just look at this thing! I decided to have a go myself and printed the devil head with very similar settings to the ones I printed my Star Destroyer with: a 0.2 mm layer height, 25 mm/sec perimeters, and 60 mm/sec infill/extra shells. Here’s the result:
I’m pretty regularly getting nice results with that 0.2 mm layer height, which is pretty small for RepRap printers. I think my next step is to halve the layer height and see what happens. Trouble is, I’m starting to bump up against long print times due to the need to go slow for the perimeters because of this annoying bug in the Sprinter firmware. Maybe I’ll work on adding support for Marlin (which has fixed this problem) into Replicatorg…
This was by far the most fun thing I’ve ever designed, because it combined several endorphin-generating interests of mine: 3D modeling, 3D printing, and Star Wars. Talk about a nerd high!
I find designing for 3D fabrication so much more rewarding than designing in a vacuum, for print, or for video games. Unlike print, you wind up with an actual object you can interact with, and unlike video games, you can create your model with a nearly arbitrary amount of detail, because the printer can handle any level of it.
For example, see the Yoda and Devil heads on Thingiverse that are rapidly becoming the benchmark for maximizing your print resolution. I mean, just look at this incredible Yoda head by BlueBot:
Incredible. It’s hard to believe this was printed with a sub-$2,000 3D printer kit. I’m not quite there yet with my $500 Prusa, but I’m getting closer all the time.
That said, there are still two quirks that you need to keep in mind when you’re modeling something you intend to print:
Some part of each piece must touch the build platform. In the case of this model, that meant that I couldn’t print the star Destroyer in one piece because the bottom is a wedge shape, not a flat plane. This was pretty easily satisfied by cutting it in half and printing the top and the bottom beside each other:
Supported overhangs can be tricky. By far the two most troublesome parts of this model were the command bridge and the engines. In the end, a reasonable solution presented itself for the engines: another separate piece printed flat on the build platform that you glue to the back.
The bridge proved a little trickier. In the beginning, I tried separating and printing it flat later, but there was always an ugly gap when I reattached it to the neck. I played around a lot with Skeinforge trying to generate support material and in the process discovered something awesome that I didn’t know about before: a plugin called Skeinlayer allows you to visualize the movement of the extruder before you print. It’s right there in Skeinforge’s interface under the Analyze tab that I bet you never clicked on before (me neither!). This is a great boon to us Replicatorg users, since the program’s interface doesn’t have this feature built in the way Pronterface does.
After a few tests analyzed with Skeinlayer, I found a good combination of settings that resulted in perfect support material and makes the bridge print okay. Here are the settings in the Raft plugin that I used to generate support material:
Support Cross Hatch
False
Support Flow Rate over Operating Flow Rate (ratio)
0.7
Support Gap over Perimeter Extrusion Width (ratio)
