DC motor replacement for 3D printers

Thanks to the work of Miguel Sanchez I started to experiment with DC drive for 3D printer.
My original goal was to experiment, but it starts to be usefull now.
I build a ToyRep printer and it was failure - motors overheated, it was painfully slow and useless.
But thanks to Miguel's github repo I am now using the toyrep as a platform to create closed-loop feedback for 3D printers.
For now, I feel like the progress is worth communicating.
The axis movement is working great - for now I've built X axis, working on Y and Z.
I am using motors from old Inkjet printer. I also salvaged the encoder strip and optical sensor - working no problem at all.
Yesterday I made a small startup routine, that is able to search for minimum and maximum position, eliminating any need for min/max switches.
The final goal is to produce a small board - drop-in replacement for stepper controllers - with pin-level compatibility.
As I am using motor driver for 2 motors, for the time being I plan to do a single board that will replace 2 stepper drivers.

The advantages are obvious - thanks to direct position information, the printer will never run out of alignment.
Steppers have to be oversized with plenty of torque so one can be sure the printhead will ALWAYS move to desired position. This is not necessary with closed loop - the logic always know where it is and is able to compensate its position by temporary increasing torque.
Result is much smaller current requirement and way quieter printer.
And, depending on the motor size, much faster movement, too.
I know about one more project - servolulu - that is trying to do the same, but unfortunately for now it's closed source.
Should anyone have comments, questions or any suggestion, please, start the discussion below.

I like the idea, but it's hard to find motors from old inkjet printers if you don't have them. Finding a cheap enough motor and encoder with the right specs was always the sticking point for me.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

What resolution does the encoder strip provide?
You can really read an absolute position with these or do you have to home the axis before you turn off the printer? ( to start at a known position next time )

Quote
bobc
I like the idea, but it's hard to find motors from old inkjet printers if you don't have them. Finding a cheap enough motor and encoder with the right specs was always the sticking point for me.

Mabuchi makes a bunch of really low-cost DC motors with fairly high resolution encoders (the same ones that go into all the old printers). It'd be nice if some place like Pololu, SparkFun or Adafruit carried some of these. I have no idea how many they'd need to buy at a time from Mabuchi, but I'd guess it would only be a few hundred.

How low cost, Lobo?

What is your micro-controller?
What code are you using?

One can not say an inkjet printer will never run out of alignment
There are inkjet alignment routines.

Would like to see a closed loop system running on cheap controller
that can pull around and operate an extruder / hotend

Quote
DRobs86
How low cost, Lobo?

I know in production quantities motors like these are about $2.50.

Quote
o_lampe
What resolution does the encoder strip provide?
You can really read an absolute position with these or do you have to home the axis before you turn off the printer? ( to start at a known position next time )

My current resolution (calculated and tested) is approximately 0.047mm per reading.
No, I don't know absolute position in the beginning.
That's why I have the start-up sequence, where the system determines the direction of the motor, then the slowest speed for movement and tries to find minimum position by moving the motor in negative direction as long as it receives inputs from the encoder. As long as the input stops, despite the motor still has power, we have minimum endpoint.
Same goes for maximum, although this one is not necessary to determine.

Quote
bobc
I like the idea, but it's hard to find motors from old inkjet printers if you don't have them. Finding a cheap enough motor and encoder with the right specs was always the sticking point for me.

You are right.
What I'm doing is I am buying reasonably old (4 years max.) printers second hand for price between $0 to $10 (vast majority of them for $0). When you then disassemble the printer, you almost all the time end up with:

• full gantry for 1 axis
  
  • DC motor including wheel for specific belt
  • belt
  • encoder strip
  • encoder
  • idler wheel/mechanism including tensioning mechanism
• additional motor for paper feeder including encoder

For now I am working on the axes (X done, Y in progress, but my today's print failed and my family already sleeps so it has to wait until tomorrow).
The plan is also to use the paper-feeder motor and mechanism for movement of Z axis and extruder, although I have a bit of a doubt if the torque will be sufficient for this - we'll see.

Quote
cozmicray
What is your micro-controller?
What code are you using?

For now I worked with ATtiny85 from China for less than $2 - that's cheap enough for me
However, I tune the PID parameters using arduino pro mini, the code works there too.
Misan also ported the code to ESP8266 and additional microcontrollers - check his github.

Quote
cozmicray
One can not say an inkjet printer will never run out of alignment
There are inkjet alignment routines.

That's a bit different - the alignment routine there is to align current position of the ink cartridge with the position of the print gantry holding such cartridge - to ensure the droplets of black colour fall precisely onto the expected spot as the droplets of the colour ones.
Therefore this problem does not apply - as long as the encoder strip is in place and I have readings, I'll not run out of alignment.
But regarding the physical test - so far I haven't run my test printer for more than 20 hours straight and it was just a dry routine test as I only have one axis ready.

Quote
cozmicray
Would like to see a closed loop system running on cheap controller
that can pull around and operate an extruder / hotend

I strongly advice to check Miguel's youtube channel - so far he made extruder driven by the cheap RC servo with magnetic encoder inside and here you can see his original arduino based system with encoders on the motors including a demonstration of violent printhead misalignment.

Quote
LoboCNC
I know in production quantities motors like these are about $2.50.

Well, if one can get the motor with encoder for, let's say, $4, then add the price of ATtiny85 ($1) and H-bridge (I'm using TB6612FNG capable of driving 2 motors) for $1.4, you have the whole axis done for less then $7.
However, I like the system with linear encoder strip a bit more - with this motor/encoder you posted one still runs into problems when the belt slips a bit. With my system, the belt can be only semi-tightened
What's funny for me is that the price of 2 DC motors, 2 optical encoders and rotational+linear encoding strips combined is higher than the price of a full-blown new inkjet printer that includes all of these
One can even get one with 2 linear strips and one rotational, brand new, for less then $40 including free shipping

I had a another look on ebay, and I found some interesting cheap motors like this one [www.ebay.co.uk]

Is that the sort of thing we need? I am not quite sure how to read the specs.

I will get a few just to have a play with. I have some applications where this might be really useful.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

The motor seem to be OK.
The question is the encoder.
From the picture, it looks like it has 36 strips, so the quadrature encoder should be able to read 36*4 impulses per revolution. That is 144 impulses.
The diameter of the belt-running wheel seems to be ~7mm, so 1 revolution will result in 22mm movement.
22mm divided by 144 impulses makes resolution of 0.152mm per impulse.
I guess it can be sufficient, but it's much lower than what you'll get with 144dpi encoding strip.
And the wiring of the motor is very weird - I've never seen something like this. My guess is it does not have quadrature encoder, but only a simple optical sensor for rotation speed - which is insufficient for positioning.

Quote
bobc
I had a another look on ebay, and I found some interesting cheap motors like this one [www.ebay.co.uk]

Is that the sort of thing we need? I am not quite sure how to read the specs.

I will get a few just to have a play with. I have some applications where this might be really useful.

The motors I'm thinking of have a transparent plastic codewheel with 334 lines, giving 1336 quadrature counts/rev. I had seen some on Aliexpress a few weeks ago, but they seem to have disappeared. Reading the specs on motors sold on ebay or aliexpress is really tricky because the people selling them often don't know that they have and fail to give you pertinent details (like encoder resolution, number of channels, etc.)

Quote
LoboCNC
Reading the specs on motors sold on ebay or aliexpress is really tricky because the people selling them often don't know that they have and fail to give you pertinent details (like encoder resolution, number of channels, etc.)

Exactly my experience.
Different topic - do you consider it better to have the encoder on the motor?
From my perspective the belt still can slip and cause problems by this, so I guess I would opt for a linear encoder on the X and Y gantry itself - seems safer to me.

Resolution on the motor is theoretically higher than on a linear strip. It will have some backlash, but this can be minimized in the design and may also be handled in software. If belts slip, it is a defective design.

Quote
rklauco
Different topic - do you consider it better to have the encoder on the motor?
From my perspective the belt still can slip and cause problems by this, so I guess I would opt for a linear encoder on the X and Y gantry itself - seems safer to me.

In the parlance of control theory, using a linear encoder not on the motor shaft is a non-co-located sensor and actuator and it raises all sorts of nasty control issues that result in instabilities or as someone else pointed out, "hunting' back & forth across and slop in the system. More sophisticated systems use dual encoders - one on the motor to stabilize the servo and a second one on the output to enable compensation for slop. Things are generally simpler and you get better results, though, if you go to the effort and expense to eliminate any slop in the system. (By slop, I mean both backlash and extras sources of compliance.)

Without the slop, in theory, it doesn't matter if the encoder is on the motor or on the output. In practice, though, you can usually get higher effective encoder resolution with the encoder on the motor shaft. Keep in mind that for dynamic positioning (ie, following a path v. just settling at an endpoint), you really want the encoder resolution to be about 10x the required positioning accuracy.

Edited 1 time(s). Last edit at 05/05/2016 06:25PM by LoboCNC.

While I agree with the theory, I have to question why all the inkjets use encoder out of the motor only for both the print head and for the paper feed.
Nasty issues are probably true, but I have to say one thing.
I actually built the device already - I modified the X axis of my ToyRep to the DC servo and it works - even with loosened belt (due to some plans to extend the footprint in future I don't want to shorten it and therefore it's not properly fixed).
The motor has to work extra to compensate for the belt and VERY rough 8mm non-hardened cheapest rod imaginable, yet it still works no problem.

So theory aside, this approach has an extreme advantage - the head is always where it said it is, not where the motor "thinks" it is. So for me, this works much better.

However, the solution (ATtiny85 code) works independently from the position of the encoder - I had previous version with encoder on the motor shaft and it worked too - just the loose belt did cause a lot more troubles then

Edited 1 time(s). Last edit at 05/05/2016 06:41PM by rklauco.

How are you testing the servo performance? Is your printer printing yet? A good overall measure is to print something like a GT2 pulley and then seeing how well a GT2 belt fits. Printing pulley teeth produces the sort of small back & forth motion that really tests how well your servos are working dynamically under a load. Could be that your inertial loads are really light as compared to the stiffness of your loose belt and that you won't actually have any trouble positioning through the slop.

Quote
LoboCNC
How are you testing the servo performance? Is your printer printing yet? A good overall measure is to print something like a GT2 pulley and then seeing how well a GT2 belt fits. Printing pulley teeth produces the sort of small back & forth motion that really tests how well your servos are working dynamically under a load. Could be that your inertial loads are really light as compared to the stiffness of your loose belt and that you won't actually have any trouble positioning through the slop.

I am struggling with the Y axis for now. I printed 4 carriages already, none of them fit to the gantry
Maybe I need to improve my CAD skills first

How does "51mNm starting torque" translate in Ncm? Is it 5.1Ncm?
Then the "9.8mNm rated load" is only 0.98Ncm, which IMHO is very low.

What is the weight of this motor? We have seen steppers with 50grams and 7Ncm holding torque....

Quote
o_lampe
How does "51mNm starting torque" translate in Ncm? Is it 5.1Ncm?
Then the "9.8mNm rated load" is only 0.98Ncm, which IMHO is very low.

What is the weight of this motor? We have seen steppers with 50grams and 7Ncm holding torque....

Your numbers are correct, confirmed by this site
Yes, I admit the torque is low.
But, there is a huge difference to steppers.
In stepper, you don't know precisely where the position is, so you need a LOT of torque (with a lot to spare) to be sure that when you do a step (even more with microstep) you get to the desired position. As you have no feedback, you simply force your way to the target. E.g. even when 1Ncm would be enough, you rather use 15Ncm just to be sure you moved.
With feedback the situation changes dramatically - you don't have to use the full torque all the time as you know how much did you move. And therefore you use much less current, produce less heat, less noise, ... When the feedback loop indicates you did not move at all, the driver will simply increase the current using PID for the motor until the desired position matches the current one.
I am using motors with 57.8mNm with no problem - as I don't have smaller ones now, I can't tell if 51mNm will be OK too, but I can tell you the motor moves with less then 6V and is rated for 24V (never tested with more than 12V so far - didn't need more torque for now).

I agree with your torque theory, but in certain moments you need this huge torque ( immediately ). At turning points of a move ( inertia ) or when you start to move you have to deal with more friction.
The PID is not very helpful then, because it's not part of the planner in firmware. You will reach the desired position eventually, but not necessarily in sync with the other axis/extruder.

This is 100% true. That's the reason I've spent last week or so trying to read repetier firtmware code to identifgy propper routines in planner, hal and printer.cpp. But my cvodingb skills are veru limited

Quote
o_lampe
I agree with your torque theory, but in certain moments you need this huge torque ( immediately ). At turning points of a move ( inertia ) or when you start to move you have to deal with more friction.

My current solution to this is to limit the jerk movement distance, provide safe acceleration and feedrate speeds.
However, if I succeed to get the planner part working ok, I think this will be way faster then my cvurrent "safe" 220mm/s.

Quote
o_lampe
I agree with your torque theory, but in certain moments you need this huge torque ( immediately ). At turning points of a move ( inertia ) or when you start to move you have to deal with more friction.
The PID is not very helpful then, because it's not part of the planner in firmware. You will reach the desired position eventually, but not necessarily in sync with the other axis/extruder.

In practice, you can usually tune your servos so that the maximum position error is comparable to that of a stepper. (Keep in mind that even when using microstepping the position error with a stepper can be up to +/- 1 full step.)

Regarding the motor torque issue in comparing steppers and dc motors, with steppers, the "holding torque" is the absolute maximum torque available, and it decreases with speed. At typical motor speeds used for 3D printers (5 - 10 rev.sec), the actual available stepper torque is maybe 1/2 to 1/3 of the holding torque. And as rklauco points out, because there is no feedback with steppers, you need a safety factor on top of that. While a DC motor has a much lower rated torque, the peak torque is maybe 5x the rated torque, and you can run at the peak torque for short periods as long as your average torque is no more than the rated torque.

Lastly, what you really want to do is compare the power rating of the motors (power = speed x torque). A DC motor may be rated for only 1Ncm, but the motor can deliver that torque at speeds up to maybe 5000 RPM. Meanwhile, your 7Ncm stepper is probably only delivering 3Ncm at 600 RPM. Hence the DC motor can deliver more power. The drawback with the DC motor, though, is that to get that the maximum power out of it for 3D printing applications, you usually need an additional 5:1 (or so) gear reduction beyond what you'd need fro a stepper.

I made a mental pro/con list and one of the cons was the limited access to dc motors, sensors and strips.
Would it be possible to make my own encoder strip? Say, I have a laser engraver and would like to make a different strip...( longer, more/less signals per mm, UV resistant material, etc...)

Quote
rklauco
motors overheated

How about reducing motor current? A printer design isn't at fault if you don't adjust such things properly, nor is the concept of having stepper motors.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
How about reducing motor current? A printer design isn't at fault if you don't adjust such things properly, nor is the concept of having stepper motors.

Of course I did that first. But the steppers were simply too weak to move the gantry then. I'd suggest you first look at the steppers used within ToyRep to get the idea

Quote
o_lampe
I made a mental pro/con list and one of the cons was the limited access to dc motors, sensors and strips.
Would it be possible to make my own encoder strip? Say, I have a laser engraver and would like to make a different strip...( longer, more/less signals per mm, UV resistant material, etc...)

I agree - lack of access to low-cost encoders is probably the biggest issue with using servos over steppers. Really cheap DC motors with encoders show up in all sorts of equipment, but trying to buy just a few is nearly impossible. It shouldn't be so hard. Making your own code strips or wheels with decent resolution (say 150 LPI) is pretty tricky. You also have to make the strip match the resolution of whatever sensor you are using.