Wednesday, June 22, 2005
Turntable Proposal Mk I
Based on the shortcomings of the Meccano turntable, I've drawn this proposal for an auto-lowering turntable. It relies on using 3 vertical pieces of M5 studding driven equally by a gear train. Play in the gear train should not be significant for the purposes of raising or lowering, but the fit of the initial worm drive onto the turntable shaft will need to be a good one.
As the centre of the turntable rotates, the M5 studding rotates at 14.4:1 . As the thread pitch is 0.8mm, every revolution causes it to drop relative to the static nuts approx 0.06mm. So it can rotate back and forth through one revolution to do the fabrication, then rotate twice to drop 0.12mm and build the next layer.
Not sure what to do for bearings yet. I might smooth things off, or I might pack the studding into cheap skate bearings.
I learned a lot about gearing designing this, but feel free to enlighten me further :) Worst case, we might have to use separate motors but this would be simpler.
Vik :v)
As the centre of the turntable rotates, the M5 studding rotates at 14.4:1 . As the thread pitch is 0.8mm, every revolution causes it to drop relative to the static nuts approx 0.06mm. So it can rotate back and forth through one revolution to do the fabrication, then rotate twice to drop 0.12mm and build the next layer.
Not sure what to do for bearings yet. I might smooth things off, or I might pack the studding into cheap skate bearings.
I learned a lot about gearing designing this, but feel free to enlighten me further :) Worst case, we might have to use separate motors but this would be simpler.
Vik :v)
Comments:
<< Home
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)
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.
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)
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)
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)
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)
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)
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)
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)
Fair enough for mechanical components, but electrical ones I'd like to test during the build process.
Vik :v)
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.
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)
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'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)
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)
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)
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 :)
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 :)
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?
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?
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.
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.
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)
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...
Post a Comment
I'm actually starting to reconsider whether it'll really be more difficult to have three linear axes. Again, we'll see...
<< Home
