RepRap: Blog

Just a thought: Why do you want to use a linear slider anyway? It seems to me that it would be mechanically simpler to mount the extruder onto the circumpherence of another (slightly larger wheel such that the extruder moves in an arc over the turntable instead of a straight line. The math to drive it gets a teensy bit more complex - but nothing that can't easily be handled.

The benefit (IMHO) is that you can now have identical mechanisms for moving the extruder as for moving the model. Commonality of parts, etc, etc.

Moreover, it would allow other devices to be mounted further around the circumpherence of the wheel - a camera/laser-pointer for scanning things, a small drill for machining parts that can't be made from plastic, etc.

Whatever solution you have for measuring the position of the turntable will work identically for positioning the extruder, etc.

With a linear slider, you have totally different parts for the slide rails, a different position measurement problem, etc. You'd also be doubling the spare parts requirement and adding to the complexity of assembling the machine.

Here is a picture:

http://www.sjbaker.org/tmp/reprap.png

The red disk is the turntable (with a completed model of Tux the Penguin!) - the blue disk at the top carries the tools: Extruder (green) camera (yellow), laser pointer (orange), drill (magenta). I left out the raising and lowering mechanism for the red turntable. The blue one doesn't need one (although one might find a use for it).
 

Rotating the extruder and so forth becomes more complex when feed lines and control wires are required. The whole rotating complex becomes rather heavy, unweildy and requires large, precise bearings.

This approach was used by Elector in a PCB routing tool design, but basically there's less play in a slider.

Vik :v)
 

Rather than the gear trains, it may be better to use a timing belt to get the three preipheral nuts rotating synchronously.
 

Interesting idea. So, by increasing the ratio, you could decrease the amount of spiral skew.

On a related note, there's a halfbakery idea called R-theta Etch-a-Sketch that produced some interesting ideas that might be of use.
 

It might be fun finding a belt of the appropriate dimensions, but I'll have a look. I might have some old-fashioned chain too.

What about using an internal gear? Or a loop of threaded Polymorph rod?

The R-theta Etch-a-Sketch is intriguing.

Vik :v)
 

OK, Allan found a timing belt from an old printer for me that is 122mm long - about 75mm in diameter - and 9.5mm thick. They are also used in VCRs, I'm told.

I'll design a static idler into the base to ensure the correct tension.

I'm coming round to the belt concept on the basis that, although it might be harder to design, the weight of the belt-driven assembly will be lower. Ergo, more payload.

Vik :v)
 

vok oliver said...

> Rotating the extruder and so
> forth becomes more complex
> when feed lines and control
> wires are required.

The turntable to rotate the tools would only ever have to rotate through maybe 60 degrees while making something. Having feed and wires that only have to rotate through that small an angle ought not to be a problem.

> The whole rotating complex
> becomes rather heavy, unweildy
> and requires large, precise
> bearings.

No more so than the turntable you are forming the model onto surely?

> ...basically there's less play
> in a slider.

So then why aren't you just using two sliders running at right angles?

You ultimately need the same precision from both the slider and the turntable in your present design. If one is significantly better than the other - you should use it in both places.


My point is that you should probably be using the same design for both mechanisms - it's less design effort - and (more importantly) fewer types of parts to have out in the field for spares and such.
 

This is a minimal, lightweight design that can produce rotationally symetrical parts with great accuracy. Think gears & pulleys.

Using a second slider for the Y axis would make things too heavy, while evenly raising and lowering 3 or more heads with their reservoirs etc. sounds too complex for the moment - though it might be a later add-on to be sure.

But don't let me stop you designing and building one. I'm terrible at listening to experts telling me what can't be done, and then doing it anyway to cries of "You cheated!" :)

Vik :v)
 

That is a really cool idea! I think I might try it for my first design. Of course, I am a software guy so any time I can trade hardware complexity for software complexity I tend to take it :)
 

Great, John! Any help we can get is welcome.

Would you be able to write the low-level stuff in 'C' to put on the PIC, or to have some form of major pre-processing going on in the main PC?

If using 'C', we're currently doing things in sdcc, which is free and cross-platform. gpsim is a nice PIC emulator.

Vik :v)
 

Well, The PC has a lot of compute power, but can't really control things with any sort of specific timing requirements, but the exact opposite is true of the PIC.

observing this, I think the best route would be to have the PC calculate and send to the PIC a series of commands in a real-time little interpreted language over the serial port, very similar to how the bitscope works. Something like


step base clockwise

turn on nozzle

wait 50ms

turn off nozzle

step head left -- (or perhaps clockwise)

wait 20ms


however expressed in a more space efficient bytecode. the PIC should take care of all calibration issues on its own though, since they could be involved and might require real-time reactions to sensor inputs. The nice thing is the pic can easily execute this bytecode in real time since precise timing is trivial on a PIC.

A free advantage of this is that with the addition of a cheap serial EEPROM and a few buttons for an interface, we could have the PIC on the reprap store these sequences of commands so that we can use the reprap away from a computer for free! This would be very useful in poor areas where there might be a communal computer but each household can get its own reprap. every now and again you can go plug it in and calculate the latest models. This can even work if there are many different models of reprap out there, the computer just queries the reprap as to its geometry at the beginning and recalculates the proper commands from the original models for that particular reprap. (caching the results for later repraps of the same type)

We can probably make the pic program a bit smarter to be able to automatically adjust timing based on the material used or things like that.
 

Fair enough for mechanical components, but electrical ones I'd like to test during the build process.

Vik :v)
 

Now, for my part, I'm actually wondering just how neccesary the strict real-time control would be if e verything on the machine was a step, not continuous motor...
So what comes out of the computer becomes more like a bitmap of which motors to step together next.

Maybe give it an old x86 and have the only job be controlling the machine? maybe run realtime linux on it?

And, of course, I'm starting to wonder how hard decent windings are to do by hand / with basic custom tools, and whether a set of neodymium magnets and an RP machine could yeild a workable stepper :)

Just might make some portions of gearing simpler, too, as the radius of the motor could be ajdusted somewhat for torque.

But I'm probably oversimplifying.
 

Steppers need one bidirectional driver per coil, and usually a dump resistor. You still need position sensing for calibration.

DC Motors need one bidirectional driver and a position sensor, but cunning software.

As far as I can see, cunning software and one driver is the easiest and cheapest option to replicate. If we can make it work, that is :)

Vik :v)
 

I thought a stepper generally didn't run the coils backwards - so four unidirectional drivers? and those drivers are strictly on-off, no PWM signals to do? True, there are more of them, but they seem simpler.
I've been poking at how one might interface a set of them to a parallel port as simply as possible. Might not be fast enough to be reasonable, though.
 

I dunno, I've not written or implemented a stepper motor before but I swear I've heard of them being driven by H-bridge drivers.

This was reinforced from the brief look I've had at the National Semi LMD18200 part. I'm getting some to drive the DC motors I'm using, some of which have been recently salvaged from a dead CD drive.

Vik :v)
 

There are two types of stepper motors, bipolar and unipolar. any unipolar motor can be used as a bipolar but not vice versa.

To drive a bipolar motor you need dual H-bridges, because you need to be able to drive each coil in both directions. There are several single chip solutions to this or you can use a bunch of MOSFETs.

To drive a unipolar motor, you just need 4 power transistors or a cheap darlington array, you don't need to be able to reverse the direction of any coil, you just need to activate them in sequence.

In any case. I was planning on a pure stepper motor design, since they are really easy to control from software and can be set to 'hold' mode which resists all movement so it can keep the heads in place. I also have a bunch of H-bridge chips I got as a free sample somewhere :)

Besides the ability to hold in place, stepper motors speed can be precisely controlled since they only move when you clock them by a know amount and are brushless, there is no electrical contact between the spindle and motor housing so they can effectivly last forever since there are no contacts to wear down.
 

Although, the main reason I am using them is because I don't need to worry about precisly controlling the voltage or current like you need to to regulate the speed of a DC motor, and you don't need any position sensors! You just count the steps from one side to the other, and put a contact switch at one end. to calibrate, keep stepping to one side until you hit the switch, then you can get anywhere just by taking the appropriate number of steps.
 

Running a pair of unipolar stepper motors from a parallel port is really easy. and it will certainly be fast enough to step them at any required speed. All you need is some darlington arrays (like a single 2803 chip for a small motor) or a bunch of power transistors or power MOSFETs (one for each line, 4 per motor) and some shunt diodes and a power source. the rest is just software. Look online for schematics on controlling an etch a sketch with your computer (A fun afternoon project). allelectronics had a deal on $1 stepper motors and I picked up a bunch and have been looking for projects to do with them.

Part of the reason I was thinking of using a PIC was that they are really cheap (like $1) and it would mean the machine can be ran away from a computer. it just downloads the design into it. That and a computer doesn't have many IO lines to work with and a PIC really isn't much more expensive than an IO expander chip, so might as well use that.

PCs are also notoriously buggy and fragile, compared to a hardend uC, which can withstand huge temperature differentials and a lot of physical abuse .

However, it should be quite possible to run and test using the parallel port of a computer.
you have 8 data lines, which can control 2 unipolar stepper motors (4 lines each) and use the strobe line to control the nozzle. you even have a couple other IO lines to play with and an error pin for feedback. (but not much)
 

Alternately, you can get a smidge more sophistocated and end up with 16 motors. (4 bits to address the motor, 4 bits to tell it what it's new energization pattern is.)
 

We've a plan for using serial-based I/O and motor control. More details shortly.

I note tthat cheap printers and CD drives use DC motors, not stepper motors. The cost of a powerful 12V DC motor (69.2g-cm) here is NZ$7 while a stepper motor is NZ$24 and not available from high street retailers.

This thing has to me capable of being manufactured in places ranging from Afghanistan to Zaire. If I can't easily buy the bits in New Zealand, we have a problem.

Vik :v)
 

...what about a set of neodymium magnets, some magnet wire & iron cores, and HDPE/Polymorph? Steppers have the advantage of having a thorough absence of moving electrical contacts - if winding and FDM can be done, it might not be that bad to be making them...

Alternately, there are even the versions where they use a straight iron rotor, no permanent magnets at all - could be quite reasonable. But that is, I suppose, an option for another day. Or, you know, for those of us who are watching and fooling around to try :)
 

John: While you can control a stepper motor from a parallel port with, say, Linux, this only works if the motor is slow or the drive mechanism is light (not much momentum). If you drive something with enough momentum quickly, and then get preempted, the motor will keep moving as you lose an unknown number of ticks. Worse, the motor might slow down, and then stall when you go back to trying to drive it quickly. You really do need something like realtime Linux, or (gasp) DOS. (Yes, DOS makes a fine "real-time operating system" for this sort of thing.)

Vik: Does your NZ$7 DC motor include an encoder? If not, you need to add the cost of an encoder to your comparison.
 

I do believe that in any case you're liable to be able to have timers capable of handling it in the kernel - say, you pass the module information on the next such-and-such sequence of steps, and it executes them sequentially and perhaps slows and stops after they're done - and a kernel module to drive the thing certainly sounds perfectly reasonable to me. Device drivers aren't hard under linux; especially simple ones.

Perhaps as simple as a queue of bytes to send down the port, and the frequency automatically reduces if the fifo gets low?
 

The DC motor on my desk (from a printer) does include an optical rotary encoder. The $7 ones do not, but I have discovered a convenient source of magnetic rotary encoders as car parts for engine timing. They can count the teeth on a gearwheel and tell you which direction it is going in for $3.

What mechanism is actually used in cheap, mass-produced printers?

Vik :v)
 

//What mechanism is actually used in cheap, mass-produced printers?//

As far as I know, most use a stepper motor with a belt drive for the head. Printer motors used to use motors with encoders but stepper motors became a cheaper alternative. It looks like the balance might have tipped the other way now. An ideal motor would be one with the encoder circuitry built in, where all you need to do is tell it, go this far at this speed.

I remember working on DECwriter printers a few decades ago. These things had DC motors and optical encoders. The position of the optical sensors had to be carefully adjusted for the head to work properly. Due to vibrations caused by the normal operation of the printers, they had a habit of coming out of alignment over time. The result would be a "head slam", where the print head would be sent at high speed to one end, where it would remain until someone cut the power. (sigh) They just don't make printers like that anymore.
 

Yeah, I wouldn't think a printer port would be good for the final design, but it could be useful for testing the hardware until the PIC or whatever program is worked out. Getting real-time out of linux is not too hard if you decide to keep going that route. But I feel a dedicated uC is the way to go in any case.

$26 seems pretty expensive for a stepper motor. In theory they should be cheaper than DC motors, having a much simpler design. Economy of scale is probably what is keeping DC motors cheaper. However, silicon is getting cheaper all the time, at some point there will be a crossover where a controller chip + a stepper is cheaper than a DC brushed motor. I have been getting my steppers from allelectronics, every now and again they have good deals.

Of course, Like all speculation, take all this with a grain of salt. I think it would be very good if we had several concurrent designs going on in any case. Nothing beats actually implementing something to learn its advantages and disadvantages and tinkering is fun whether it ends up being productive or not :)
 

Until someone comes up with the hydraulic version :)

To be honest, if I can get something that goes round under computer control I'm happy. Currently, the Meccano one goes round, just not under control. I'm going to be concentrating on heads again shortly, and leave others to implement the majority of the turntable design. Simon is developing some interesting control systems which I'm eager to get stuck into too.

Vik :v)
 

It'll definitely be interesting to see how things turn out. From what I hear, brushless motors in general aren't hard to do, including steppers... Might even end up simplifying things.

I'm actually starting to reconsider whether it'll really be more difficult to have three linear axes. Again, we'll see...