Stepper motor alternative ?

can the firmware be modified to use a optical encoder? if yes then what all needs to be changed cause i just modified a dc geared motor so to install a encoder......

Is it true that the recent Kickstarter project The Micro 3D Printer uses DC motors instead of steppers?

For any interested... I finally got a chance to play with an idea that I had along these line, and it turned out really well...

I started with 3 dc motors with encoders (http://www.aliexpress.com/item/5pc-6V-4000rpm-12v-8000rpm-Standard-130-motor-Green-Micro-DC-motor-with-encoder/1698382218.html), added 48:1 gearboxes, and a cheap microcontroller (Texas Instruments MSP430G2553), and 3 motor controllers; and put together a hack that lets me absolute position them from -2147483648 to 2147483647.

Each "step" is 1/128 of a rotation of the motor, which ends up being 1/6144 of a rotation of the output shaft.




On top of all of that, because I am using a constant-read on the encoder to determine position, it is able to detect if it gets blocked or something external moves the shaft.
It can even be used as an alternative to a servo.

Cost Breakdown:
3 dc motors with encoders: 4.20
3 motor drivers: 3.00
3 48:1 gearboxes: 480 (replaced motors that came with them)
MSP430G2553 microcontroller: 2.50 (Could also have been an arduino)
board, mount, wiring: .75
---------------------------------------------------------------
TOTAL: $15.05




PS: I used the Energia development platform (http://energia.nu) to develop the controller code
P.P.S: As soon as I get the chance, I will build a few more and post step-by-steps with code (Assuming anyone is interested, so let me know)

That's a nice idea, and the cost is much lower than I would have expected! My only concern is how long a brushed DC motor will last in this environment, before the brushes wear out.

Which motor driver chip are you using, the SI9986, or something else?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I am using L9110S motor drivers...($1.50 each and use two... leaving one driver unused) The whole rig is purposely drop-dead easy and cheap...
I've attached my current Energia(Arduino) code... It was hacked together something fierce, and I plan on doing much refactoring, but it works pretty darn solid, so it seems like a good start...

Honestly, the most difficult thing about this hack was tracking down the pinouts for the motor (ended up tracing wires). I am seriously surprised I haven't heard of anyone else doing this... Especially since the more that I play with it, the more fun it is.

I replaced the x and y drives on my Mendel (and wrote quick controller code) and it worked just brilliantly. I have some thoughts on an alternative design 3d printer, so I think that will be my next focus... (Gonna have to build at least one more of these for that project, so the how-to is still forthcoming).

Since the traction controls end up being less than $30, I think that other than the extruder, I can keep the costs to under $60 (but, of course, we will have to see).

Quote
thomassmith1969
As soon as I get the chance, I will build a few more and post step-by-steps with code (Assuming anyone is interested, so let me know)

I am definitely interested! It would be great if you could post additional details.

It would be really fun to see a video of your printer working with DC motor drives. Any chance you could post a video? Time and again I see people say that it is impossible to make a 3D printer work with cheap DC motors. It would be wonderful to send them a youtube video showing a working system.

I'm using DC + Encoder on my powder bed printer - DC + Encoder is pretty sweet for constant velocity (the printhead axis) systems.

My Y axis is a geared DC + Encoder (hacked up ball mouse optics on the fishing line drive) and is slow enough that inertial overshoot isn't a big issue.

I am waiting for my new hardware to come in before I make the video (A changed out to l9110h ic's so that I can make a nicely packaged 3 motor control unit on a single board), but have been continuing to verify and test with my current rig. I added the ability to set the speed for each motor so that I could coordinate moves (I am doing inverse kinematics with 2 degrees of freedom to implement my x/y control). For any interested, I am trying to use UV cured resin with an array of UV leds as an extruder (this would eliminate the need for most of the metal, and be a lot easier to deal with, not to mention cheaper since it looks like everything but the motor could be printer). Anyhow, here is my controller code, I will tweak it for Arduino soon since I found a place to get Arduino pro minis for even less than the msp430g2553.

What's typically the speed limitations on a printer? Because if it's the x/y travel speed with steppers, I feel pretty soon there will be a large push for DC or BLDC motors for position control... With a well tuned PID loop you can achieve amazing accuracy and extremely high speed, also: with printers we're talking about consistent load so this makes things a lot easier...

I'm not overly concerned about keeping cost down, yes it should be cheap, but if you get a serious performance/speed upgrade from typical steppers, then I don't see a problem spending a few extra bucks on electromechanics

[www.ebay.com]
[www.ebay.com]


BLDC motors use hall effect sensors for commutation (Hu,Hv & Hw) ... These are essentially magnetic sensors that let the system know the rotor is in rotation... typical these are amplified and sampled into an analog pin for processing...


Above is a simplified schematic of a BLDC motor drivers... it's essentially a three phase H-bridge, as you can see there are 6x BJT transistors... they don't have to be BJT... FET or IGBT will work better... but we're still talking 6x PWM lines PER MOTOR if one chooses to build the drive from scratch... there are also dedicated semiconductors for this task... but then cost goes up...

And then there is dealing with the encoder(s)... 2x external interrupt lines per encoder for full quadrature decoding (4x resolution of encoder ie: 1024 becomes 4096) or 1x interupt line + 1x GPIO line for standard decoding...

There was talk above of the ATmega dealing with this... personally I think...

-2x interrupts lines
-3x analog lines
-6x PWM lines

Per motor...

-Plus dealing with serial transmission, heated bet, 2x steppers, extruder...

Not a hope is hell... we've gotten into the higher level ARM Cortex M3-M4 area... But all that being said. If we can gain a serious speed advantage with all this... development might start heading that way.

But as I stated at the top... I don't actually know what out speed limitation is right now... Might be barking up the wrong tree.

Velocity will never be a problem. Just do the math - a 14 tooth pulley will move the axis 28mm per rotation. Even at a blisteringly fast 200mm/s print speed the motor is rotating at a paltry 400rpm. If you ever need more speed (unlikely given extrusion limits) just swap to a larger pulley.

The improved acceleration provided by servos could eventually improve print speed and quality, but right now frame rigidity is so poor that its unlikely to provide any benefit.

If you are choosing between stepper motors and servos you should pick the cheapest and put the money towards a better frame and more accurate linear guides.


Note that even if you hack together a servo very cheaply the gearbox is going to be a huge issue. Gearboxes introduce a disgusting amount of backlash until you start paying 200$+. Plus the <2$ brushed motors last about two weeks and are generally horrible. The performance is likely worse than an off the shelf stepper.

Edited 1 time(s). Last edit at 01/14/2015 05:11PM by 691175002.

I would invite anyone interested to take a look at my firmware for my powder bed printer.

I am using a mix of DC+Encoder (X and Y axes) and stepper motors (Powder(E) and Part(Z) axes) in my firmware.

Very C++ish, I know, and I need to add 2D kinematics (currently it's only an axis at a time, which isn't an issue with powderbed), but it should be a start.

I use a very non-PID system (ramp up, travel, ramp down) that seems to work for my setup.

BrundleFab Firmware

See Axis.h, Axis_DCEncoder.h, Axis_X.h and Axis_Y.h for the relevant files.

Quote
691175002
Gearboxes introduce a disgusting amount of backlash until you start paying 200$+.

Truth...

Quote
MachineHum

Quote
691175002
Gearboxes introduce a disgusting amount of backlash until you start paying 200$+.

Truth...

Yes, and optical encoders and a good control system takes all that backlash out.

I have a gear motor with a rubber grommet driving a fishing line belt system, and I get 250 micro resolution on that axis without even trying hard - it's all about the encoder when working with DC motors.

Quote
Ezrec

Quote
MachineHum

Quote
691175002
Gearboxes introduce a disgusting amount of backlash until you start paying 200$+.

Truth...

Yes, and optical encoders and a good control system takes all that backlash out.

I have a gear motor with a rubber grommet driving a fishing line belt system, and I get 250 micro resolution on that axis without even trying hard - it's all about the encoder when working with DC motors.

Typically it's rare for the encoder to be mounted at the output of the gearbox... usually it's on the shaft of the motor



"Typically" being the key word

Quote
Ezrec
Yes, and optical encoders and a good control system takes all that backlash out.

I have a gear motor with a rubber grommet driving a fishing line belt system, and I get 250 micro resolution on that axis without even trying hard - it's all about the encoder when working with DC motors.

Even though your system will maintain positional accuracy when moving in a single direction, the motor must take up the slop for every direction change. This gets reflected as a pause in motion which screws up circles and curves.

Furthermore, you cannot move the encoder from the motor shaft to the (non-rigidly coupled) load and expect a stable system. Your gains become very sloppy, completely defeating the point of using a servo in the first place.

Commercial systems always use dual loop control in such situations ( [granitedevices.com] [machinedesign.com] ) which requires two encoders: One on the motor shaft, and one on the load.

Your system "works" because the rubber grommet provides so much friction the system does not oscillate when stopped. That does not mean that it is closely following the setpoint or providing smooth motion under load. It will also fail catastrophically if there is an intermittent force backdriving the load.


Frankly, unless you show me plots of commanded vs actual position (as measured by a higher resolution non-feedback encoder) I will never believe a hacked together servo is superior to a 5$ stepper motor.

I'm sure your system appears to print fine, but stepper motors print fine as well. Assuming "250 micro resolution" means 250 steps per revolution, that is inferior to a stepper motor taking half-steps (and you probably have many encoder counts of following error on top of that).
I suspect acceleration is poor as well due to the use of cheap motors through a gearbox.

What measurable advantages does a DIY servo have over a stepper motor? All I'm seeing is additional cost and complexity.

Edited 1 time(s). Last edit at 01/15/2015 01:16PM by 691175002.

Quote
691175002

Quote
Ezrec
Yes, and optical encoders and a good control system takes all that backlash out.

I have a gear motor with a rubber grommet driving a fishing line belt system, and I get 250 micro resolution on that axis without even trying hard - it's all about the encoder when working with DC motors.

Even though your system will maintain positional accuracy when moving in a single direction, the motor must take up the slop for every direction change. This gets reflected as a pause in motion which screws up circles and curves.

Furthermore, you cannot move the encoder from the motor shaft to the (non-rigidly coupled) load and expect a stable system. Your gains become very sloppy, completely defeating the point of using a servo in the first place.

Commercial systems always use dual loop control in such situations ( [granitedevices.com] ) which requires two encoders: One on the motor shaft, and one on the load.

Your system "works" because the rubber grommet provides so much friction the system does not oscillate when stopped. That does not mean that it is closely following the setpoint or providing smooth motion under load. It will also fail catastrophically if there is an intermittent force backdriving the load.


Frankly, unless you show me plots of commanded vs actual position (as measured by a higher resolution non-feedback encoder) I will never believe a hacked together servo is superior to a 5$ stepper motor.

I'm sure your system appears to print fine, but stepper motors print fine as well. Assuming "250 micro resolution" means 250 steps per revolution, that is inferior to a stepper motor taking half-steps (and you probably have many encoder counts of following error on top of that).
I suspect acceleration is poor as well due to the use of cheap motors through a gearbox.

What measurable advantages does a DIY servo have over a stepper motor? All I'm seeing is additional cost and complexity.

Speed... BLDC motors can run faster, but as people have said before... the x/y speed isn't currently the limiting factor of 3D printer speeds... so right now they don't really have any advantage...

Commercial systems "always" using duel loop feedback is debatable. Zero backlash lead screws or planetary gearboxes are used in CNC applications all the time... with the encoder mounted directly to the shaft of the motor... I've also worked with systems positioning multi-ton machinery within 1/8'' using encoders and squirrel cage induction motors... But duel loop feedback is not uncommon for machines with lots of slop requiring very high positional accuracy

Just saw some one did it nicely on a Prusai3

Quote
691175002
[What measurable advantages does a DIY servo have over a stepper motor? All I'm seeing is additional cost and complexity.

Advantages (for me) are one and one only - exploring DC + Encoder motor control with parts I have laying around. I only had two steppers on hand (for my Z and E powder axes) , so I cobbled something together from what was in my parts bin.

Although it is fun watching the DC motors whip along to their destinations during a G0 move ... then wait for the steppers to slowly show up.

For G1 moves, it's terrible. DC motors just don't have enough stopping force to hold a position without active feedback, and even then it's easy to perturb them. Hence why they are not on my 'anti-gravity' Z and E axes.

However, I'm a powder bed system - the carriage axis only moves slowly, and in one direction at a time (almost no acceleration to speak of) and the printhead axis is a constant velocity system (the spray changes, but the head keeps moving).

So DC + Encoder is fine for my application on those axes, and it allows me to learn new motor control techniques.

For a RepRap FDM? Nah, I'd use steppers all the way.