Introducing the Motate128 Stepper Motor Control System.
Primarily designed to drive 3D printers, such as RepRaps and MakerBots, as well as CNC milling machines and DIY laser cutters, it's truly capable of driving almost any project that is based on bipolar stepper motors. And it will always be 100% open source, software and hardware. I've also submitted it as an entry into the Open Hardware Scholarship competition.
Utilizing the ST L6470 chip, it's capable of 1/128th-step microstepping with speed and acceleration control (which is why I chose the model I did for the Acceleration mods to the MakerBot firmware), with minimal intervention of the microcontroller. It even supports sensorless skipped-step detection, so missed steps could be accounted for in real-time.
With a truly modular design, the Motate128 Stepper Drivers could be used in any number of other projects on their own.
Adding temperature measurement and MOSFETs to drive heating elements, DC motors, solenoids, etc, the Motate128 Shield sits atop an Arduino to drive up to six Stepper Drivers.
For compatibility there will be modified versions of both the MakerBot and RepRap firmwares to support the new hardware.
And finally, the Filament Caliper will use hall-effect sensors to precisely measure the filament width and speed as it enters the extruder, allowing unprecedented levels of accuracy depositing extruded plastic.
Update: Credit where it's due, this is inspired by a blog post on the Ultimaker site, and I would love to continue to collaborate on this with them or anyone else.
I’m able to print in 3mm PLA, finally. I’m not able to print in 1.75mm PLA without jamming unless I crank the volume up to 11, er, 111%. My best explanation for the latter is a mix of slightly-off pulley diameter with that size of PLA mixed and that it simply provides more pressure. Even at 111% it jams, it just takes an hour.
Nick Starno said…
Nick told me that he believes that acceleration of the filament to speed would work better than going directly to full power. I don’t know if he was speaking of this particular problem, but I think it’s a valid idea.
Also, I had some skipping because I set the feed-rate on bridges to 2*40mm/s. I really don’t think that that should be a problem.
As you can see from the image at the top of this post I’ve been doodling. I haven’t tried any of this yet, but here it goes.
Setup
Acceleration and deceleration are set independently and for each axis. They will be measured in mm/s/s. That can and probably will be translated to steps/s/s (in ReplicatorG, at least).
Direction doesn’t matter except for when switching directions, which means stopping first.
At all times the movement of all axes is to be synchronized.
Rules
Acceleration happens after a point that sets the speed.
The speed being accelerated to does not have to be achieved.
Deceleration happens before the point that sets the speed.
The speed being decelerated to must be achieved.
Switching directions implies a stop at the set-point that first goes the opposite direction.
All of the steps required to reach a set-point must be completed.
Implementation
TBD.
I plan on using the command queue to look ahead and determine the points where deceleration must start. I suspect I may have to implement a minimum speed that applies only to acceleration so that it doesn’t take all day to get moving from a dead stop.
Imagine that you have an Arduino Uno running as a web server and you want to open a serial connection to it. Or, you have a MakerBot or RepRap that has a Arduino Mega 2560 as a part of the motherboard, it’s building from SD card, and you want to pause it, get temperature readouts, etc.
Naturally you connect the USB cable, open a serial connection — and it resets! For the web server it might not be all that bad but for the MakerBot you might have just blown a 3 hour print 2.75 hours in!
Fix it if it nags you
So I have been doing firmware work on my MakerBot which requires updating the firmware a lot. Unfortunately MakerBot — in order to fix the more problematic of the two sides of auto-reset — decided to cut a trace on the Arduino motherboard to completely disable auto-reset. I like auto-reset when I upload a lot, but hate it when using the Arduino and it resets when I don’t want it to.
So, I decided to fix it.
Background
The newer Arduino Mega, the 2650, along with the smaller but more common Arduino Uno both use an ATmega8u2 USB-capable uC instead of the traditional FTDI chip. This is great for many reasons but for me it means it is reprogrammable.
Locate the problem
The auto-reset is triggered on connection from OS X and Linux by the DTR line (old-time modem control line speak for a flag getting sent over USB) getting raised during connection and dropped on disconnect. This doesn’t happen on Windows normally, but avrdude and the Arduino software both do it manually.
During programming, the DTR is raised for about 1 second, lowered, then raised again to start the programming communications.
I added a check to the USB serial firmware that resides on the 8u2 that checks for that specific timing before performing the reset. I have tested it on OS X and it works: reset doesn’t happen during repeated connect/disconnects, but does for programming from the Arduino environment.
Try it, you might like it
You can download the firmware .hex file for either the Mega 2560 or the Uno from GitHub. The source code is available too, of course.
Instructions for installation are here and doesn’t require any special tools.
Please leave a comment and let me know either way how the testing goes.
I set the Packing Density to .9 and was able to make a test cube using 1.75mm PLA without jamming.
But it appears that smoking out my bot for the fume filter test (video below) was probably not the best idea.
I’m getting skipped steps in the Y axis. I re-oiled, but will probably need a more thorough cleaning. It’s always something…
Update: That's not right. Setting Packing Density lower should make it output more plastic, not less. But a quick visual inspection indicated that it's making it output 90% as much plastic, not 111%. I'm looking into it...
I recently read Nophead’s most recent article, and it was very interesting.
History
I’ve been working on Volumetric 5D, mainly to fill a need I see, and several people have been either helping me or happened to be thinking along similar lines. We all noticed that when we extruded at what, volumetrically determined, would be ~85% fill of plastic it would yield about the best looking objects.
A couple of people then tried to measure the unwieldy extruded filament and it looked like it was losing volume. I hoped it was wrong.
Nophead said we were wrong
Early on hophead was saying we were wrong. Dave Durant posted a profile-creating program on thingiverse, and in the description Dave mentioned the 15% loss theory. Nophead commented that he felt that that wasn’t the case.
At that point I still wasn’t firm on a theory of what’s going on, but Enrique had already added changes to Skeinforge based on the math that I had been working on with an 85% “packing density.”
Feeling better, bad timing
So now that Skeinforge 40 is out with the new math in it Nophead does some experimenting to disprove that the density loss theory. I welcome the disproval, really, but couldn’t it have been sooner?
Anyway, on IRC Dave and I had just been discussing how the math goes funny with layer heights around .2mm and lower. We were both seeing too much plastic with ABS. We had both come to the conclusion that the “corners” were not filling in — that surface tension or something was keeping the ABS from filling in every void there was.
It wasn’t until Nophead’s blog post that I realized that most or all of the “packing density” we were seeing is because of this. <facepalm>
What’s going on again?
Well, basically the filament is laid down with rounded edges, like icing being piped onto a cake. Then the extruder comes back along one side of that extruded filament for the next pass and is trying to fill in all of the gaps between the two passes.
For PLA — a very pliable and rubbery plastic at melting temperatures — this mostly works. The PLA easily deforms and allows the new filament to fill in the spaces.
ABS hardens so fast and has such viscosity that — as Nophead put it — to fill in all the gaps would be like injection molding. I think it’s slightly worse because we’re dealing with very tiny places to fill and we would require tremendous pressure to fill them. Way more than we can expect from our current range on extruder designs, at least.
I do feel better about this theory. I do wonder if there is a certain minimum radius we can expect the filament to fill in. Knowing that would help us more accurately determine how much volume to output to get as reasonably close to 100% fill as we can.
Headaches
ABS fumes have started to make my head hurt, so I switched back to PLA. However, I already had a Mk6 all geared up for thin filament so I wanted to make that work. I ordered some 1.75mm PLA from MakerGear and started printing right away.
And immediately started to get jams.
I suspected that the PLA was liquifying in the tube because it was overheating. I also blamed the rapid-reversal ooze-prevention I was using, but turning it off didn’t really help. I tried removing some tube to stop thermal transfer inward:
That didn’t work:
So I ordered a MakerGear hot end and stepper setup, and am getting similar results.
But, thinking about this new theory about filling the gaps in: I wonder if it’s simply too much back-pressure in the nozzle from using it as an injection molder?
I decided to do an extreme test of the stepper-driver extruder and the volumetric math. In reality, most of this is testing Skeinforge.
Volumetric 5D Update
I contacted Enrique, creator and maintainer of Skeinforge, about my Volumetric 5D testing, and he liked enough to add it to the Dimension plugin of the latest beta of Skeinforge! (I’m guessing that it will be in version 40, but I’m not sure. It’s in the latest downloads available here.)
We had a slight disagreement about the exact method it should be implemented, but that’s really small potatoes. This is, as far as I’m concerned, a huge step in the right direction.
I’ve been making several different types of test prints, and I’m very happy with the volumetric math so far. I’m completely puzzled that I haven’t seen mention of this 15% volume loss in ABS printing until very recently, but it’s definitely the case. I suspect it may actually be a little more, like about 16% loss since I occasionally get very tiny gaps in solid horizontal surfaces. It’s very close, however.
Back to the Tilted Cube
That’s how it skeined. I had to set the Support Minimum Angle to 15 to get it to build support up near the edges of the cube. This wasn’t for support of vertical movement, as you usually use support for, but for horizontal movement of the cube since it’s on such a small base. It still moved somewhat and left on odd indention on a edge.
I didn’t thing that that shape would end up as a cube, but it did.
I didn’t get the whole print on video, but the end started seeming so fun I started to shoot video, and here’s what I got:
And, here’s the result:
Compared to the same STL file of a cube, normally oriented:
That’s with Layer Thickness at 0.3mm, Perimeter With over Thickness (ratio) of 2, giving a Perimieter Width of 0.6mm. Speed feed rate and flow rate were set to 40mm/s. I had Cool turned on with the Cool Type set to Slow Down and Minimum Layer Time was set to 20 seconds. That made for a very interesting situation as the top corner needed to take 20 seconds, as you can see in the video. I did not use a fan, but I plan on trying a fan with a funnel on it to aim the air more precisely.
I’m using the latest Dimension plugin that includes the volumetric math to scale the E value based on how thick the incoming filament is. This assumes that your firmware/software is configured so that an E change of 1 will result in precisely 1mm of filament entering the extruder. (If you’ve scaled your E_STEPS_PER_MM in the RepRap firmware, undo that first!) With Dimension, it assumes that your feed rate is the same as your flow rate. You really should always make those the same. If you find that you need that changed then something else needs adjusted, such as E_STEPS_PER_MM (RepRap) or axis … scale= in RepG for a makerbot. (My scale, or steps-per-mm, is 50.235478806907409 for a standard MakerBot Mk5 “pulley.”)
The biggest new feature of the new Dimension plugin is that it takes a Filament Diameter parameter. This needs to be precise, and measured before every skein, possibly every print, with a caliper. It also takes a Filament Packing Density, which should default to 0.85 for ABS and 1 for PLA.
You can see in the above photo that it left a gap on one side, but the opposite side was
Apparently, in Skeinforge, the Raft / Support Gap over Perimeter Extrusion Width (ratio) is assuming that the extruder will ooze plastic out over that gap. Since the ooze is pretty well under control now, I set this to 0. It still left a gap of one perimeter width (0.6mm) but that worked most of the time. I had one spot (the most horizontal of faces) where the support required a knife to remove, and it most likely due to some amount of drooping. Perhaps a setting of 0.1 might be better.
Here you can see the odd ripple on one edge where the upside-down pyramid moved horizontally while it was printing:
The raft pulled right off, and most of the support ripped off with a small screwdriver.
Conclusion
Printing with a stepper-based extruder is insanely better than with a DC motor. Adding volumetric math to skeinforge means that changes in the filament won’t require ugly changes to firmware, flow rate, or worse, feed rate. Support structures in Skeinforge obviously aren’t optimized to handle this type of overhang on all sides, but it’s an odd case to be sure.
Next Steps of Volumetric 5D
I’ve noticed that with 90ยบ or sharper corners a little bit will flip up, and at first I assumed it was pulling it back up as it drug back across what it had already printed. However, which printing thinly sliced objectes (0.2mm for example) it’ll actually build up too much plastic. I had considered that the math might be off, but on horizontally flat surfaces and perimiters wil few curves or sharp corners the problem doesn’t show up.
I then realized that it really is going over that same place twice when it turns a corner. If you think of the filament pushing out and filling the space along the leading half-circle of the nozzle as it moves, as soon as it turns the half-circle overlaps with already placed plastic on the same layer, and on corners that overlap ends up getting pushed out to the corner as it vacates that space but holds down where the actual overlap occurs.
As you can see, the darker colored area is where there’s twice as much plastic deposited as needed. The sharper the corner, the worse it is. With a part with a lot of curves or sharp corners, especially if that’s on a small layer, you’ll see a buildup of too much plastic pretty quick.
I have an idea of how to fix it, but I’m almost out of battery. It’ll have to wit for the next post. :)
PLA is very difficult to work with. At first I thought it was actually expanding in volume, but then I determined it just has a nasty die swell that is different based on the rate at which it’s extruding. The volume doesn’t change, but you have to slice your prints differently based on how fast your going to print them.
ABS is much easier to work with, but shrinks about 15% when it’s extruded.
