tinkerin.gs

What is Motate?

2012-09-02T23:53:00.000-05:00

I haven’t been updating this blog for a while. Sorry about that. I have been very busy, however.

The Motate system has changed in scope and purpose since I first announced it here about a year ago. Primarily, it is no longer intended only as a 3D printer electronics kit.

It is now a system of hardware and software for high precision and high performance motion control, all programmed from the Arduino IDE.

What that means is that the Motate system will provide an approachable means of making various projects that, currently, are difficult to get started on. It will be Arduino compatible in software, and similar to Arduino hardware. Most of the libraries available for Arduino hardware will work with little to no modification on Motate hardware. It will also, by default, be programmed in the Arduino IDE. It will not, however, be compatible with Arduino shields, since the Motate hardware is a different size and shape than Arduino hardware.

All of the Motate libraries will work on Arduino hardware, but you may need additional circuitry for certain features.

One common use would be CNC (computer numeric control) devices such as 3D printers, laser cutters, pen plotters, milling machines, and computer-controlled routers. These devices all use similar techniques and technologies to provide motion. In particular they often use stepper motors, and have very complex acceleration profiles to stay within the laws of physics and the rules of the particular materials and methods they are working with.

Hardware

The hardware is still in development. (There are working prototypes, but the final feature set is still undefined.)

Software

I determined that one problem I keep running into with Arduino/AVR projects is that of the vast array of libraries available, many of them seem to be either high-performance or approachable and intuitive, but rarely both.

I want the Motate libraries to be both. For motion-based projects, real-time response is vital, and there’s very little room for resources to be wasted.

I also feel strongly that it’s completely possible to have libraries that have an intuitive and usable interface, but still have high performance and reasonable binary size.

So, I decided to see what I could do about it. So far, the results are quite promising.

Motate::Pin

(See full usage instructions and download the libraries on GitHub.)

Instead of digitalWrite() and digitalRead(), you use variables of type Pin*N*:

// create the led Pin object, setup as an output
Pin13 ledPin = Output;

Also as a convenience you can use the predefined objects pin*N* (lowercase p).

pin13 = Output;

// Output
pin13 = HIGH;

// Input
if (pin13) {
    // something
}

It’s easy to use, but more importantly it’s fast and small. It’s smaller: digitalRead() takes 166 bytes + 6 bytes per call, and digitalWrite() takes 168 bytes + 8 bytes per call. Motate::Pin objects use 2 bytes to write and two bytes to read, each in a single machine language operation that takes two clock cycles.

For a visual of how fast it runs, here’s digitalWrite() in a tight loop, making a 126kHz square wave:

Same loop, but with Motate::Pin code setting the pins, making a 1MHz square wave:

Full library code available on GitHub. It installs easily into the Arduino IDE. Use it in your projects today!

More coming

The Motate::Pin library is just the beginning. Over the next few weeks I’ll post about Motate::PinHolder, Motate::LCD, and Motate::TWI. I’ll also post tutorials on how to make high-performance code for the AVR and Arduino.

-Rob

Motate128

2011-09-14T12:21:00.007-05:00

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.

Acceleration/Deceleration

2011-04-04T09:10:00.001-05:00

It’s really stopping that’s the hardest

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.

What do you think?

-Rob

Posted via email from tinkerin.gs' posterous

Arduino Auto-Reset Software Fix

2011-03-26T18:35:00.001-05:00

Here’s the scenario

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.

-Rob

Posted via email from tinkerin.gs' posterous

Back-pressure update [updated]

2011-03-23T02:34:00.002-05:00

It works!

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...

Posted via email from tinkerin.gs' posterous

Back-pressure

2011-03-21T10:59:00.001-05:00

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 hope I can test this tomorrow…

Posted via email from tinkerin.gs' posterous

Tilted Cube (Test Print)

2011-02-05T19:37:00.001-06:00

Will it print?

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. :)

-Rob

Posted via email from tinkerin.gs' posterous

Volumetric 5D testing continues

2011-01-22T08:17:00.001-06:00

Testing is going well

PLA test

ABS test

Notes

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.

See the comments on this thing by Dave Durant and on this Google Group to see more details about the ABS shrinkage and PLA expansion.

Posted via email from tinkerin.gs' posterous

What is 5D?

2011-01-16T00:59:00.002-06:00

5D

As I mentioned in my last post I’ve started work on what I call Volumetric 5D, which is an extension to 5D. I realized, however, that I wasn’t even sure of what 5D was.

I did some research before getting started but couldn’t find a good definition of “5D.” I found in the code for the Dimension plug-in of Skeinforge a reference to this article by Adrian Bowyer on the RepRap blog about “4D,” but there was no mention of a 5D.

I still haven’t found a non-code explanation of 5D.

What is 5D?

First, 3D: X (left and right), Y (front and back), and Z (up and down).

Then, as explained in the article on the RepRap blog, 4D: 3D + E (filament to extrude).

So, what’s the 5th D? I can’t tell you for sure — I couldn’t write the Wikipedia article on it because I only have circumstantial evidence and no references — but I believe it’s F (feed rate).

I had to look at the RepRap 5D firmware to get that. It makes sense when you look at GCode, kinda, but it didn’t really make sense until I saw how it’s implemented.

Feed rate is how fast the head is traveling in relation to the build platform. In the 5D firmware it’s implemented as a virtual stepper where the current position is used for how long to pause between steps of the syncronized movement of all of the stepper motors.

As the movement continues toward the destination (in physical space) the pause is also moved along a linear path from the previous speed to the destination speed. The end effect is an acceleration or deceleration from one feed rate to another providing a (theoretically) less jarring switch from one feed rate to the next.

So, there you have it, all five Ds.

-Rob

Posted via email from tinkerin.gs' posterous

Volumetric 5D

2010-12-26T22:42:00.002-06:00

5D

So, the time has finally come for us Makerbot folks to catch up with the RepRap crew and put stepper motors on our extruders. (Seriously, has anyone seen a RepRap with a DC motor from that last year?) This is a good thing. It’s spectacularly good, except that the software isn’t ready.

Oh, it’s close. I’m even helping to get it there, but it’s still in need of work. The RepRap project has been using something called “5D GCode” for a while now. (It seems to have started out as “4D,” and was outlined in this post. Some more info on it’s current usage can be seen on this page about Erik de Bruijn’s conversion script.) It’s a simple addition to the GCode that Makerbots use: instead of “start extruding at xxx power” it treats the extruder as a 4th (or 5th) axis, telling it to extrude N mm of filament for this movement. This extra axis is expressed as an E code, like this:

G1 X1.0 Y1.0 E1.4142

This is really slick because the movements will be synchronized with the other axes and the filament will be put down in an even amount.

There’s still a huge problem that’s not covered in this scenario: how much to move? Is a mm of filament before or after the extruder and nozzle? How do you compensate for … well, anything? There’s a lot of factors being ignored here: filament thickness, extruder “pulley” diameter, nozzle size, and plastic expansion/contraction are just the ones I’m aware of that matter. Relative humidity, ambient room temperature, filament manufacturer, and filament color (and the fillers that are required for those colors) may matter as well.

In the various means I’ve seen the solution is to simply scale the E axis by some amount, and the operator is apparently supposed to fiddle with that amount until you end up with something that “looks good.” I don’t think that’s good enough.

I’ve been working on a way to take at least some of the predictable factors into account and eliminate most of the tuning, leaving only fine tuning. The clearest way I can think of would be to include the expected output volume per mm of travel in the gcode, and then determine the correct math and methodology to make the machine provide that expectation as closely as possible.

To determine how much volume we want out is easy: layer height x thread width x mm/s gives us the volume per second in mm3, or uL. I’m hopeful that this will eventually come from Skeinforge. I’m thinking of using the M108 code with an L subcode, like this:

M108 L0.23

The hard part sounds easy: figure the volume of the filament going in per motor rotation (and thus per step of the motor) and that should be how much plastic comes out, right? It turns out that the answer is no. Thanks to Dave Durant providing good, reliable numbers, I’ve been able to determine that that’s not the case. (Dave had come to the same conclusion separately.) I believe it’s due to a phenomenon called “linear mold shrinkage,” which basically means that when you heat the plastic and force it into a small space it breaks down a little and occupies less space afterward.

Whatever the cause, it appears to be linear, meaning if we put in N amount of volume, we will get N * M amount out. M appears to be somewhere around 0.85 for ABS. I haven’t had a chance to test this myself, and am curious to see how PLA does and how other factors effect it. Regardless, we can now figure that for L mm3/second we need R revolutions per minute of the extruder motor.

This should yield extremely higher quality prints with minimal effort, no hardware change (aside from the stepper motor driven extruder), and minimal software change.

Math

D is pre-extruded filament diameter (precisely measured)

C is the circumference of the pulley where it pushes the filament

L is the mm3/mm to extrude P is rotations per minute

R is mm3/rotation

f is the linear mm of travel per second

h is the layer height

w is the thread width

S is the shrinkage factor, which is volume out / volume in

Measurement

I believe, but haven’t tested, that you could make simple gcode that, if given D, C, an the diameter of the extruded filament (which is the nozzle size with die swell, not just the nozzle size) it would move the extruder up 100mm, then extrude enough filament that it should just touch the platform. The amount that it’s wrong could be used to adjust S to the correct value.

Implementation

For now this could be used to calculate the correct RPM for a given feed rate.

If testing proves this to be valid, I’d like to see this implemented in the Makerbot and RepRap firmware along with a Skeinforge plug-in.

Posted via email from tinkerin.gs' posterous

One "Z" Endstop...

2010-12-08T01:23:00.001-06:00

Find out how you can make you very own magical green light switch that makes the ’bot start printing at the right height every time: http://www.thingiverse.com/thing:4762

Posted via email from tinkerin.gs' posterous

Video of Wintermute and it's hacks

2010-12-05T01:19:00.001-06:00

Please excuse the deep geek accent.

-Rob

Posted via email from tinkerin.gs' posterous

Yum!!

2010-09-22T18:36:00.001-05:00

Posted via email from tinkerin.gs' posterous

MakerBot, Past and Future

2010-09-08T16:27:00.002-05:00

Present

Yesterday Makerbot Industries announced that they were going to have an open house today to discuss what everyone thinks they should focus on.

Since many, er, most of those interested won’t be able to make it to NYC with 24-hours notice, a wiki page was started so that everyone could share their thoughts remotely.

I like most of those ideas. I agree with most of them. But, if the question of the day is to determine the roadmap, I think that simply citing specific bot upgrades or hardware/software changes is too specific. Not worthless, but we need a little bit of Big Picture too.

I read an article on the Technocratic Anarchist where Forrest Higgs muses about how (as I interpret it) people are getting caught up on things like infill, heated build platforms, and support material when they really should design to the strengths and weaknesses of the medium instead of constantly fighting it. It made me think about hearing Michael Curry talk about his Gothic Cathedral design that is very popular on Thingiverse. He designed a model of a cathedral for printing on a Cupcake CNC. The cathedral that he chose was designed to overcome a common problem of the time where horizontal overhangs were hard to make with stones stuck together with mortar. This is a great fit for the Cupcake because it has the same problem of horizontal overhangs with no supports, and demonstrates how the old solution is perfectly applicable to a modern problem.

Past

As I understand, the Cupcake was conceived as a RepStrap. And I think it has been wildly successful. Many Mendels have been made with Cupcakes. There has even been a Cupcake made by another Cupcake!

Then it became more than that. The popularity and lowering of the barriers of entry made it, in some ways, better than a RepRap. It was becoming a viable commercial product. Over time and batch after batch, in order to meet demand, the parts that were part of the cupcake kits and were printed on cupcakes, in the spirit of the reprap project, were replaced with off-the-shelf parts made in traditional factories. It became apparent that these were no longer just RepRaps. They were becoming serious competition for $20,000 rapid prototyping machines.

Present (again)

I’ve been months getting my Cupcake (Wintermute) in working condition enough to start printing it’s first child. It’s not just fiddling with temperatures and tightening bolts, but getting the dizzying array of software parameters figured out and tuning them. Most of this is in Skeinforge.

There are a few things that the Cupcake is missing. It’s not closed loop, meaning that it doesn’t really know where it’s parts are. You just have to start the build platform and extruder in the right places so that it won’t drive one into the other or the build platform into the side of the bot, etc. It’s very good at driving blind, but a little perception would go a long way. But then you have to support it in software. Once you support that in firmware, you need to hack on Skeinforge.

Skeinforge is a hack with hacks added to it. It’s a great hack. It’s very capable. But it’s still a hack. And it’s the single largest point-of-failure for anybody operating a Cupcake. No amount of hardware changes will make that right.

I was at the KC Mini-Maker Faire answering questions about MakerBots, and kept hearing myself referring to it as a hobby, “basically like hot-rodding a car.” “You spend a lot of time with parts all over the floor and messing with this and that to get it just right. It’s definitely not for XYZ yet, because you would be spending most of your time fiddling and fixing.” I attribute 90% of that to Skeinforge and 9% to stuff that was just fixed by the MK5 or about to be fixed by Gen4 electronics. The remaining 1% is yet to be determined.

Future

I think that MakerBot needs to have a goal. That goal shouldn’t mention the how, and maybe not even the why, just the what. I think a simple goal of making a 3D-printer that is affordable, of reasonable quality and capability, and that has a pleasant, approachable user experience.

Of those three, the first two are complete but the last one is totally missing. The community surrounding MakerBot is excellent, and it the only thing that makes that missing element excusable so far. But to move forward there needs to be a lot of cleanup. I don’t think this will require anything drastic, really, with the possible exception of replacing Skeinforge.

One major assumption that is made with the Cupcake kit is that the user has a technical background, but that’s not necessarily a very clear assumption. Does that mean they can solder and know what a capacitor does? Or does that mean they are comfortable with a command line? Does that mean they know how to make a Bézier do their bidding or even what a Bézier is?

Any of those assumptions may be wrong, and worse, requiring that knowledge means that using the bot will be more hassle than it needs to be. Since it’s a kit, the only real requirement should be the ability to follow instructions and what they entail, and how to download and print 3D files from Thingiverse or elsewhere. Anything outside of that should not be required for making objects out of a loop of plastic. Anything else should be left as an exercise for us hobbyists.

-Rob

Posted via email from tinkerin.gs' posterous

Bluetooth Makerbot

2010-08-10T09:38:00.003-05:00

Wintermute is a Bluetooth Makerbot!

I have actually had this setup for a while but forget to post about it.

I connect to Wintermute, my Cupcake CNC, over Bluetooth using a Sparkfun Bluetooth Mate. It has the same pinout as the FTDI cable usually used to control the Cupcake. This is great except the VCC pin on the Cupcake motherboard is not connected. (This is smart … So you don’t accidentally try to power the whole ‘bot off of your USB port.)

So, I used jumper wires (I think these from Adafruit would work great too) to connect to the normal port, except I used the power pin (bottom left) from the ISP port directly below it. (Click on the photo above to see a larger version.)

Here’s an article where they used a BlueSMiRF Gold module from Sparkfun. It’s a very similar module, differing mostly in the pinout. In that article they did a little more surgery than I’d prefer in order to get to the power, but it’s a good solution nonetheless.

I left off the control pins (RTS & CTS) because they don’t really do much but goof up communications anyway.

Software setup

First you pair your OS with the BTMate. This will be different for every OS. (Hint: The default code is ‘1234’.)

I’m on OS X, so I connect via the screen command in Terminal.

screen /dev/tty.FireFly* 115200

Once connected, type (hit return at the end of each line, the last one is optional):

$$$+
SU,38
SQ,16
SN,Wintermute

If you're using screen, disconnect by typing Ctrl-a, then ‘k’.

You should now be able to start RelicatorG and choose the BT module. (Note on OS X: the cu.* and tty.* forms are functionally equivalent, so use either one.)

I haven’t had any luck with printing directly over the Bluetooth connection, the latency is just too high and rounded corners become huge blobs. However, warmup, noodling, and starting a print-from-SD works great.

Good luck!

-Rob

Posted via email from tinkerin.gs' posterous

LED Board Connector

2010-08-08T17:44:00.002-05:00

So I etched the controller board for Wintermute's LEDs. I wanted to connect it directly to the power source, which is a standard PC power supply, so I did a litle carving and came up with this design.

I'll do a full post on the controller board later.

iPhone drawn concept: “Swiper”

2010-08-08T17:40:00.001-05:00

I sketched up a quick idea for a mechanical oozebane. This sketch is obviously not dimension or positional accurate.

The concept: Have a arc of very thin, rigid metal (or other material that can handle a lot of heat) that covers the end of the extruder nozzle of a Makerbot Cupcake CNC, a Reprap, or any other plastic-extruder-based CNC machine. The metal will get hot with the extruder and hold the molten plastic in and molten.

It works like this:

Before the extruder starts to extrude, the electromagnet will charge pulling the swiper around and out of the way of extrusion.

When the extruder stops, the magnet will be shut off and the springs will both cut the filament and stop the oozing.

The common solution to this is to run the extruder backwards for a small period of time after stopping. This works a lot better if you have a stepper motor or other means of precisely controlling the motor, but still has a few drawbacks:

The first is that the filament still has a string out of the nozzle that is dragging more of the molten filament out the further you get from the stopping point. Since the motor is off, this molten filament won't be completely replaced and will cause a gap the next time the extruder starts.

The second is that the filament will have a small portion that is exposed to cool air, making a hardened “booger” that will be dropped as soon as the extruder starts again. There's also a widening bubble of air between where the last of the filament hits the melting zone and that is falling slowly. These two things will make a lump followed by a gap after every stop/start of the extruder.

So, this swiper aims to solve both of these. First by cutting the filament off clean and second by keeping the filament hot and ready without forming a bubble.

I am yet to make a prototype, but I think I'm close. I'm totally open to any ideas.

-Rob

Sent from my iPhone.

Posted via email from tinkerin.gs' posterous

This is indoor, with central air that is working:

2010-07-23T21:49:00.001-05:00

Posted via email from tinkerin.gs' posterous

The Amazing Technicolor Makerbot

2010-07-18T17:15:00.000-05:00

I decided the Wintermute needed some LEDs, but I didn't like the thought of doing static LEDs, so I'm working on adding LEDs all over. Some will be RGB and vary color based on various criteria, some will be single color and come on at certain times, and some will be single color and always on.

To get started, I needed a way to hold the LEDs. I wanted them to be small, so I wanted surface mount LEDs. So I designed and etched a board for the LEDs:

(I'll put this on Thingiverse once I feel like it's usable. Leave a comment if you're interested.)

You can see in the photo some of the magnet wire I used to wire them together. (BTW: I'm not affiliated with any of these links, so I'm just letting you know what I used. I'll let you know if there's an affiliation at any point.) This turned out to be more like sewing than soldering, but it was kinda fun too.

Soldering the single-color LEDs isn't too hard. They're small, so you have to have a steady hand. I solder them by putting a small blob of solder on one side, holding the LED in place, and then melting the blob with the soldering iron so that the LED sinks in and ends up flush to the board. I'm not sure where I learned this, but it was on the Internet. It was probably on Sparkfun. Here's a Youtube video made by Sparkfun:

Here you can see some the right column is soldered in place, and the solder blobs on the left half of the other items:

One note about design: I designed the RGB LEDs with the resistors in place, but for the individual LEDs I didn't put resistors on the board. This was partially a mistake (forgetting to make room for some resistors) and partially experience. The RGB LEDs are very sensitive. (I blew out two of them and had to remove them and put new ones in their place.) The single LEDs I'm using are fairly robust (it took 12v to blow them out ;-), and so I'm using a single (PTH) resistor for a string of three, with the three in parallel. Like this:

Once I have a row or column soldered up, I use scissors to cut them off of the board and solder them together using the magnet wire. Here's the RGB LEDs and resistors soldered up, with the right column of single-color LEDs cut off:

And then cut out:

I'm still working on the control circuitry, which will control the colors based on one of several criteria. I'm thinking right now the most useful will be temperature of the nozzle and heated build platform.

Here is my current state of progress:

I have blue LEDs in the "floor" and white LEDs below the Z-platform to illuminate the build platform from above. The build platform is a MBI Heated Build Platform and has a ring of red LEDs under it to show when it's heating. (That's not shown in this photo.) The Z-platform has RGB LEDs at the back and on the side of the extruder. In the photo, all of the red, green, and blue are at full voltage, so they're making "white". (The red in these RGBs is a little weaker than the green and blue.)

That's all I have time to blog for now, but I'll show how I connected them to the 'bot, as well as my progress on the control circuitry in later posts. (You can peruse my Flickr and see what I'm up to. It gets updated first.)

KC-Area Mini-Maker Faire

2010-06-30T12:04:00.000-05:00

If you live the the Kansas City area (Northwest Missouri or Northeast Kansas) then visit the KC Mini-Maker Fair!

It's put on by Make:KC and CCCKC. I'm a member of CCCKC.

Hopefully I will be able to participate. In the least, I'll try to have Wintermute there! (I'm sure there'll be at least a few MakerBot Cucpcake CNCs to be seen.)

Official announcement: KC Mini-Makers Faire

Plastruder Fail — again!

2010-06-03T02:46:00.000-05:00

I just rebuild my plastruder and installed the new MK5 Drive Gear, and it failed catastrophically!

Ok, well, I didn't blow a retainer or anything, but I think that's a testament to the Drop-in Paxtruder that I'm using.

But man, can that thing push! It twisted the filament up in the tiny space available. Here's a few more photos to show the damage (click on any photo to see it bigger):

And here's what the filament looks like when I pulled it out:

You can see that there's something binding it up, but I think the real problem is heat. I cleaned this out and plugged it back in, and my temperature reads 109ºC at room temperature, so I think my thermistor failed.

If that happened mid-build then that would explain this. The temperature got too low and the plastic was no longer liquid enough to extrude.

Wow.

Now to rebuild, again! Gah!

Say Hello to "Wintermute"

2010-05-29T03:06:00.000-05:00

Wintermute, the serial-number free Makerbot Cupcake CNC

This is my clear acrylic MakerBot Cupcake CNC. I call it "Wintermute."

It's has a Drop in Paxtruder derived from Paxtruder-0.2 (and lasercut) by Craig Berscheidt. (He also lasercut the whole acrylic bot body for me. Awesome work!)

It also has a Heated Build Platform v2.0 (HBPv2) from MBI. (That's what is making the pretty red lights.)

I moved the Extruder Controller to the side of the Cupcake (following Keith's excellent post) partially so that I have room for the heat sink. I also wanted to be able to see the filament better. (The photo above is before I did this.)

One common problem with the HBPv2 is that the MOSFET overheats. A common solution is to make a relay circuit, and I might still end up with one, but as a quick solution I rigged up a quick heat sink from some 20AWG hookup wire (of the RadioShack flavor) with the insulation stripped off.

Then I soldered it onto the ground tab of the MOSFET.

You can see that it sticks out too far to clear the top of the Cupcake's frame, so mounting the extruder controller was required. In retrospect, I could have made the heat sink considerably smaller with the same amount of wire, and not had to move the EC, but I like it better this way.

I've been able to make a few prints, but then I started having extruder problems. Right now I'm rebuilding the extruder.

Wish me luck!

ASUS WL-520GU Webcam - Part 2 - Getting Started

2009-04-25T10:01:00.000-05:00

This post is the second post in a series of posts about making a webcam server using a inexpensive wireless router, some open source software, and a cheap webcam. Read the first post for a little more background.

Why a Webcam

I wanted to be able to watch my 2-year-old's room to see if she was sleeping or not without risking waking her up by entering the room. I had a wireless camera a bought for ~$99 about a year ago and it's crap. It interferes with my WiFi. My WiFi interferes with it. It's not very good quality. And it can only be viewed in one place: the TV the wireless reciever is attached to.

So, my goals are:

Cheap: Under $100 for a complete camera setup, including means of transmitting to my iPhone or computer. If I add multiple cameras, then the per camera cost should either get cheaper or stay the same.
Compatible: I want to be able to view this on my iPhone or MacBook Pro. I want my wife to be able to do the same, ideally at the same time in another part of the house (or world.)
Expandability: I would like to be able to add cameras to the system, and easily switch between them.
Unobtrusive: I don't want a bulky setup hanging out in the corner of my daughter's bedroom. I'd like something that I can hide most of in a drawer and just have a tiny camera hanging out above a window sill or in the corner. The less messy cords and power plugs the better. It's also important that it be safe for a curious 2-year-old to be around, so the positioning and security of the power plugs and other cords must be carefully considered.

Some of those goals are a bit lofty, I know. Streaming to the iPhone requires H.264 encoding, and that might be a bit much to ask of a 200MHz router, especially if I add multiple cameras to one unit and have multiple people viewing those streams. If that proves to be impossible, I'll try to use my underused G5 as a streaming server, converting a simpler format (MJPEG, most likely, since that's what many webcams send natively) to H.264 with the help of a much more powerful processor.

Buying stuff

Router

As I've mentioned, I'm cheap. I like buying things on sale or sometimes used. So, when I read about the ASUS WL-520GU over on the mightyOhm blog, I immediately started looking for deals. When I bought mine, it was $40 on NewEgg.com. Even when there's no specific coupon or rebate, it's still only $50.

If you decide you would like to use a different router, then a lot of these instructions might still apply so long as you're going to use OpenWRT. You can see if you're device is supported by browsing the Table Of Hardware.

Note: As I write this the OpenWRT team is busy moving and updating the wiki, so that link might go stale. Even the "Supported Devices" link on their home page is broken currently, so you might have to dig some to get to it. In any case, you should search the forums to see if anyone else has asked about the hardware you want to use. Keep in mind that sometimes the manufacturer will change the internals of a device without changing it's name or UPC code, so you have to sometimes buy the device and look at the back and see if it says v1, v2, etc. So far, ASUS seems to fairly clearly state when they make changes, but I can't say how much you can trust that.

Webcam

The web cam isn't as easy of a choice. There are many, many different webcams, with ranging features and quality levels, not to mention prices. Many of them would put us over the $100 mark by themselves. Assuming the router costs about $45, and we'll need a USB hub and USB thumb drive, we've got about $30-$35 dollars to spend on a webcam.

I got lucky and found a Logitech QuickCam Communicate STX at a local Target for $30, and that actually included another (normally less expensive) webcam with it. I haven't found that deal since.

Things you should look for when choosing a web cam:

Make sure it's compatible with the gspca/V4L2 drives used by OpenWRT. I had a hard time finding a list I could link to, but I did find this one. That's close, but you really want to check the list from your OpenWRT before you build, because there might be some more added. When I get to the installing of OpenWRT part, I'll explain more. Keep in mind that manufacturers change the internals of a product without changing it's name, sometimes making it incompatible with Linux. The only way to know for sure is to plug it into your computer and check the vendor and product IDs. I'm using a Mac, so I open the System Profiler with the device plugged in and grab it there. On Linux you can use lsusb. I don't have a clue about Windows, but I'm sure it's possible. (Feel free to share how in the comments, in case others want to know.)
You probably want it to be small, for unobtrusive use.
You might want one with a built-in microphone. The STX I'm using has one, but I still haven't gotten it working. I'll try again later and report.

Other USB Stuff

All that's left is a USB hub and a USB flash drive. You probably already have some of these laying around. Most of them will work, so it's mostly up to price and aesthetics.

For the USB hub, I just use a tiny little mobile USB hub that I had. I have no idea what it cost at the time, but I doubt I paid the $20 it goes for on Amazon.

For a flash drive, I'm actually using a tiny little flash card reader (like this one) and a 1GB microSD card. The router sees it like it's any other flash drive. It doesn't have to be big, unless you plan on keeping recordings around on the drive instead of sending them to another computer or just streaming them into the ether. That old 128MB or 512MB flash drive you hardly use anymore might do the trick quite nicely.

Void your warranty

Warning: What we are about to do to your poor ASUS WL-520GU will void it's warranty. You might also turn it into a bunch of spare parts. Proceed with caution, and use common sense. Please.

Adding a serial port to the router

It's really hard to top the instruction over on the mightyOhm blog. Actually, I wouldn't want to try, since that's where I got my information. (Thanks, Jeff!)

However, since I did a few things differently, I will give a very rough outline here:

Open your router, voiding your warranty. In order to do this you have to pop off the rubber feet from the bottom of the router and remove the screws hidden underneath. I cut the feet so that I could stick them back on and leave the screws accessible. The top will not pop off. It has a little bit of a latch, so you can leave the screws out and not worry too much about it falling apart when you pick it up.
Remove the solder from the header that is just below the ASUS logo (when the logo is upright) with a soldering iroon and a solder sucker. This part is not easy, since the "bottom" pin is on a ground plane, and will require a lot of heat. I have a 15W iron, and so I used a BernzOMatic butane-powered mini heat torch to heat the other side at the same time. I have scorched and destroyed several PCBs with this torch, so you have to be careful not to get too hot too fast. Once the solder melts, use the solder sucker to pull the solder out quickly before it cools and solidifies.
Here's where I varied from the mightyOhm instructions. He said to use a 4-pin straight male header, and I instead used a 4-pin right-angle male header. Then, instead of soldering up a piece of perfboard and some female headers, I just used the female-to-female jumpers from SparkFun and a strip of straight headers. Using the schematic provided by mightyOhm, I wired header to the FTDI cable by placing the small strip of straight headers in the FTDI cable and then connecting the cables in this order, from top to bottom as show in the photo above:
1) 3.3V → (unconnected) 2) RX → Orange 3) TX → Yellow 4) GND → Black

I was able to run the wires around the edge of the board and out thru the mounting hole on the back of the router. That way I can close the case and still have access to the serial port on the router.

Testing the serial port.

I'm on a Mac, and so my instructions will be slanted that way. Most of this info should transfer to Linux/*BSD quite easily. I'm sure it won't be hard to find information online on how to do this on Windows.

Connect the FTDI cable to your computer's USB port. (You might need to install drivers first.) Then open a terminal emulator and connect to the router. The settings: 115200 baud, 8N1. Over on mightyOhm, Jeff says he likes Zterm for the Mac and Hyperterminal on the PC. I don't know about Hyperterminal, but I've never been much of a fan of Zterm.

Instead, I use screen. It's built into MacOS X, and works like a charm, mostly because you never leave Terminal.app. The only part I don't like is the hand-cramp required to leave the program. To connect (assuming you have only one FTDI cable attached at a time):

$ screen /dev/cu.usbserial-* 115200

That will connect you to your router. You can type in commands to the normal UNIX shell. You may have to hit return at first to bring up the prompt. As an exercise, you can restart your printer while connected to see the startup logging.

When you're ready to disconnect the cable (or just leave screen) type: Ctrl-A, then "k" for kill, then "y" when it's asks "are you sure." Please refer to the mightyOhm post to see what a typical startup of the WL-520GU looks like.

In the next episode...

In the next post, I'll show you how to custom compile an OpenWRT and load in onto your router.

ASUS WL-520GU Webcam - Part 1

2009-04-14T18:49:00.000-05:00

First post on this blog, Yay! Oh, so much to say, so little time.

Let's start with my current off-time-project: WL-520GU Webcam.

The goal:

Use a simple, cheap, and physically small device and a cheap webcam to make a security camera / baby monitor / nannycam. This device would stream the video over ethernet or (preferably) WiFi to my iPhone and MacBook Pro. (I may have to use an intermediate computer to get the video to the iPhone, which has to be in H.264 format, but I'll avoid that as much as possible.)

The equipment (so far):

Thanks to posts by Jeff at MightyOhm, I've been tinkeri.ng with the ASUS WL-520GU. It's a pretty slick, cheap router with a USB port. More importantly, it can be reflashed with a linux OS that you compile yourself.

There are several choices of OS, but I chose the same one Jeff did: OpenWRT.

I'm cheap, so when it came to picking a webcam, I searched for deals first, and compatibility second. This isn't necessarily the best route, since there are many many webcams on the market, and a lot of them are not supported on linux.

The good news is that linux support for webcams recently became a lot better, and is now part of the linux kernel. (Knowing that earlier would have saved a lot of hair-pulling.) I ended up with the Logitech QuickCam Communicate STX. I got lucky to have found it cheap: ~$30 for it and another webcam bundled together at a local Target.

Note: There are a lot of things to consider when buying a webcam for use on Linux, let alone with a tiny processor. I will try to make another post about this soon (and came back here and link to it.) For now, just know that you should look up compatibility first, and that manufacturers change a product's internals without changing the name or packaging, so be sure you can return it (or have another use for it) unless you don't mind possibly wasting some money.

The downsides:

The WL-520GU's factory-installed linux is based on kernel 2.4, and the wireless drivers from Broadcom are not open source. This means that to switch to 2.6, we lose wireless until the b43 drivers are ready for this device (if ever).
The USB2 drivers that are stable for this device require the current 2.6-based kernel.
The webcam drivers that are part of the OpenWRT packages distribution are not upgraded for 2.6. After a lot of head-bashing, I figured out that the drivers are now part of the 2.6 kernel. However, OpenWRT still doesn't include support for compiling these modules in the default distribution. I'll explain how to add this in a later post.

Progress:

The console port soldered in, like the instruction over on mightyOhm, but with a few modifications.

Instead of using breadboard and straight headers, I used right angle header and female-to-female jumpers from SparkFun and a strip of straight headers.

SparkFun has since added female-to-male headers to their inventory, and I might use those in the future and eliminate the straight headers. The straight headers do leave the cable in order and tidy when the FTDI cable isn't hooked up, however, so I might stick with this method anyway.
OpenWRT running on the 2.6 kernel with USB 2.0 support, usb-storage (and associated filesystems), gspca2 (a.k.a. V4L2), and support for the specific chipset used in my webcam. Unfortunately, this means that WiFi is broken, since the drivers for the WiFi in the Wl-520GU aren't ready in the newer 2.6-based kernel.
Formatted a 1GB USB drive to ext3 format and setup opkg to install new packages on it.
Compiled and installed gstreamer, ffmpeg, ffserver, and motion onto the USB drive. (I'm using about 40MB of the USB drive's 1GB so far, so there was no chance of installing internally!) I know I don't need all of these, and each has it's place. I think this alone will end up being a post.

So, let's get started!

Sadly, the full-on instructions will have to wait until my next post.

Update: Part two is available here.