Improved Machinetool DC Motor Controller

To build a improved controller for DC motor conversions of workshop machine tools.

Similar projects worth following
This project aims to produce a motor controller system that can be applied to a range of DC motors of varying powers and voltages. The result of this would be a great increase in the functionality of both home DC-converted mills and lathes, but also a distinct improvement of control on common Chinese imported machine-tools that often use DC motors as stock.

The goals are to..

1: ..allow setting speed based on tool diameter & desired cutting speed, not just RPMs.
2: ..make it fail-safe by using the motors native voltage as source, not PWM limits.
3: ..make it self-calibrating.
4: ..have over-temp, stall & overload monitoring.
5: ..apply the same core controller to my lathe but add on-the-fly DRO-based speed adjustment to compensate for current material diameter. (stretch goal)

A while back I invested a good chunk of money in a nice big milling machine. Too big as it turned out. With the stock AC motor attatched it was too deep to fit on my workshop bench.

So I picked up a cheap wrecked treadmill, yanked the 1.75HP motor and made up a mount & pulley adaptor for it. It worked lovely.

Right up until the treadmill controller shorted out & nearly set the motor on fire.

The controller was a right-off, but I managed to salvage the motor after replacing the carbon brushes and skimming the commutator bars smooth on the lathe.

In this chaos though, an idea was born. To make a better controller. Safer and a lot more useful, that could be applied to similar DC motor tools.

Turns out the most common voltage for these big DC motors is 230VDC in the UK. Problem is the peak-to-peak voltage of mains AC power is 370v. What I beleive the controller was doing was running the motor at a reduced PWM duty-cycle to give it the correct equivelent. Up until the controller shorted and jammed the control MOSFET on, dumping full rectified mains into the motor, sending it way past it's upper limits and spraying my workshop with sparks.

If I'm going to be using a big DC motor, I want it to be safe to start with. That means instead of using a reduced duty-cycle to make the motor think it's running at the right voltage, I'm actually going to use the right voltage then PWM regulate that.

While I have my own motors to think of first, I know the common Chinese import lathes and mini-mills tend to use 180VDC motors, and some American treadmills (favoured source of cheap 1-2HP DC motors) can apparently be as low as 80VDC. With that in mind, I'm looking at using a Power Factor Correcting buck-boost power supply and aiming to have the eventual PCB laid out in such a way to leave space for the motor-specific caps and inductor choices, whatever they may be.

Once the right power supply is done, it's onto the control. Simple PWM will handle speed control, but that control will be set by a microcontroller.

The current concept design has three 4-digit 7-segment displays, each with it's own rotary-encoder switch. Depending on which is used, you could set raw RPMs as usual, or dial in the cutter diameter and the ideal cutting speed for the material and have the controller automatically spin up to the correct RPMs for that setup.

But how will it know what PWM duty to use? You're still going to have a power transfer system from motor to spindle and it's probably not 1:1. Are you going to have to dial in the precise gear ratio of the machine?

No. Let's just have an RPM sensor on the spindle. A magnetic pickup maybe. When you first start it, go to calibration mode and let it run at, say, 10% speed. Shouldn't take too long to work out the ratio!

Overload protection is a case of poly-fuses, maybe with a current sensor for early-warning. Temperature is a thermocouple. Using the same theory to run a lathe just means altering the code to take diameter input from a DRO input (with upper limits  of course! Can't run a lathe at infinite speed!).

No, it's probably not the biggest thing to happen to machine tools. Yes, you could probably do just fine without it. But cumulatively, I think it could make a big improvement in the quality and capacity of peoples home workshops.

That +5% efficiency multiplier in a game makes all the difference.

  • 1 × Atmega168 Microprocessors, Microcontrollers, DSPs / Microcontrollers (MCUs
  • 1 × ACS712 30A hall effect current sensor

  • Preparing to prototype

    Sci08/21/2014 at 02:09 0 comments

    A concept is a thing of sublime fantasy. It is a dream with no flaws. Reality isn't like that, so when you start to bring it to life, you start having to make changes to get it to work.

    The control panel

    The original idea was simple; three rows of 4-digit 8-segment displays, each row with a matching 2-bit greycode dial. Easy as pie until you start counting available pins on the microcontroller. I have some Atmega168's left over from another project, so we're going to try for a pure Arduino core.

    I want to keep the parts count and cost down, so while I could use a multiplexer and a dedicated 8-segment driver, the segment drivers are about 5 times the cost of the Atmega. Plus if I use a dedicated driver, while I only need 4 lines to drive it, I only get the hex digit range at best.

    I'd rather have complete control over what the display shows, as it would allow the display of error codes.

    So what's the spec? Fantasy says twelve 8-segment displays, total. If you multiplex the display selector with a 4-to-16 line decoder, that's still 12 (8+4) output pins taken up right away. There's still 9 input pins required for the greycode switches (2-bit + button). So we're at 21 pins required and haven't even talked about the current sensor, MOSFET PWM, sounder, serial data, or RPM sensors.

    The Atmega168 only has 28 pins, and they're not all usable. So let's start paring it down.

    Do I need 8-segments? The decimal point is only of conceivable use for tool sizes, but throwing some imaginary numbers at the RPM formulae ( (m/min * 318.057)/dia ) says the mill won't be capable of reaching the speeds where fractions of a millimetre between tooling size are noted. A 1mm tool at 15m/min cutting speed (very slow) needs a speed of 4770rpm.

    Practical considerations. You're never going to be using a tool that fine in a machine this big. We can forget the decimal points and go with whole numbers only without loosing anything.

    One pin down.

    Cutting speed examples ( range from a low of 15 up to 210m/min. (Thought I suspect machining waxes would be best with high, I can't find any cutting speed numbers for them, only RPMs)

    In any case the cutting speed display only needs 3 digits. And if we limit the tool diameter to a very generous 99mm, then we only need 9 digits total.

    So 7 pins for the displays and 9 to multiplex them. Still a bit hight. So let's get the 4-to-16 line decoder back in play. We can have all the original displays at this point if we like, but let's save costs where we can.

    And you know what? Here's another saving. The multiplexing's happening faster than we can see, so our clumsy monkey fingers aren't going to outrun it. Let's turn the greycoder buttons into a 3x3 matrix and run the inputs from the end of the same decoder.

    So now that's 7+4 outputs and 3 inputs to cover all the displays and manual controls. Much better!

    It means using some of what are usually considered the analogue input pins as general IO, but the datasheet says it's fine. It also means there are sufficient pins left for the other functions. The standard serial pins are there, current gets an analogue input, MOSFET control gets a PWM pin, RPM sensor gets a digital input and we even have one PWM left for a small alert sounder!

    I think that uses up every single pin, only requiring the addition of one cheap line decoder IC. Like a glove!

    I'm still favouring a classic look with red 7-segment displays showing through a translucent black plastic fascia, laser engraved with the various labels.


    Now let's start with something close to my wallet. However you cut it I'm going to be hooking a microcontroller up to a 9A mains supply and frequently modifying the code from my computer.

    Every time I get something wrong, I do not want to have to replace my computer because the USB port took a 230v hit.

    I looked up off-the-shelf possibilities for isolation of the USB connection, in case something goes wrong. Turns out USB isolators are very...

    Read more »

  • Spec'ing out

    Sci07/14/2014 at 17:05 0 comments

    What I have to work with will define the initial build, so let's press on with that.

    My mill is a Chester Machinetools Eagle 25. The standard induction motor is 3/4HP and the two-belt gearing set gives it a standard range of 100-2150rpm. I've already stripped it down though.

    To fit the DC treadmill motor I fabricated a simple bracket to mount the treadmill belt-tensioning arm on. An aluminium bushing fits the motor pulley to the M12 treadmill spindle fitting. The positioning looks odd but works. With the middle pulley removed, the highest gear ratio is about 1.7:1, so the upper limit using a 4800rpm motor should be around the 2800rpm mark. The lower end will depend on the motors stall speed plus whatever feels like a good safety margin. At 5% it'll be about 240rpm at that ratio. The low-end belt ratio is about 1:7.69 though, so at 5% it'll give 31rpm. A potential improvement in range in both directions!

    Auto-calibration will be nessesary any time the pulley ratio is changed. A POST operation is probably a good idea.

    The motor in question comes from a Roger Black "Gold" treadmill the owner threw out because it "caught fire". Which meant it made a lot of smoke. This turned out to be from the plastic output pulley coming loose on it's shaft and rubbing against the running platform until it melted. The motor was fine.

    The motor is a Greenmaster GMD118-1, and as you can see from the sticker it's spec is a bit odd. 230V DC. At 50/60Hz. Umm...

    Shops selling them give them a "compatible" voltage range of 180-230v. It's one of the better brands but of still generic chinese DC motor stock, so I'm putting the AC frequency mentions down to bad translation.

    Online shops also list the spec's as being 1.5HP and anywhere from 4000 to a crazy 5600rpm! On the old controller though 10% power put out 471rpm, so I'm inclined to beleive the motors own label. I'll still be very cautious running it up to full power in testing.

    So, 230VDC is the aim. The cont. duty of 1.75HP comes out at around 1305Watts. However the apparent peak power I've seen on (physically identical) motors from other generic manufacterers has been 2.75HP, which comes in at 2050Watts.

    It's an important note to make that some treadmill motor manufacturers seem to list peak motor power and some list the continuous duty power in their specs without defining which it is. Watch out for this when sourcing your own treadmill motors.

    The current sensing is going to come in very handy for testing the motor specs against reality.

    To accomodate the gulf of mystery, the initial build is going to be spec'd for a 2Kw power supply.

    I'm looking to use the Texas Intruments UCC28019. I'll freely admit I don't know a terrible amount about PFC controllers, but I was recommended this one and it's power and voltage specs seem to be suitable.

    The example circuit design for it in the datasheet relies on their design calculator spreadsheet, which is very thorough but only has settings for boost converter configurations. To take rectified UK mains and drop it to 230VDC it would need to be a buck converter. Or, to allow the circuit to operate on a wider range of inputs and outputs, it would need to be a buck-boost converter.

    TI's Power Stage Designer tool takes care of providing the specs for the major power componants (Inductor, diode, MOSFET) for a variety of configurations. The UCC28019's configuration options will need to be calculated from the datasheet formulea.

    Of course the fact that they need individual configuration too means a universal PCB is probably off the table, at least until I've tested the waters some more. The path of least resistance to a working prototype is a buck-converter, so let's get that calculated next.

  • Two design concerns

    Sci07/11/2014 at 21:56 0 comments

    Concern one;

    A friend asked me how this project will meet the "connectivity" requirement of the Hackaday Prize. I'm not sure I liked the phrasing; it sounded like they were suggesting I was just going to cobble something on at the last minute.

    I don't think anything needs cobbling on. What will be used for debugging and control in the prototype will become a data-logging output. Tying control into existing CNC control methods hardly seems pointing out.

    Data-logging isn't anything fancy, but it's extremely useful. Being able to plot current use and RPM for certain cutting speeds and tools could help you find the optimum feedrates you can handle, or watch for worn tools. Or you could simply keep an eye on how much power you're using, or even just general machine health (free-spinning current is higher than it was last month for the same speed? That doesn't sound good).

    That's all just software though, this just gives an all-in-one way of accessing it. With a simple serial output, I expect there'll be many more ways found of using it all than I can imagine alone.

    Obviously I'll have the microcontroler opto-isolated from any high voltage stuff. USB ports are better not on fire.

    Concern two;

    Is it really nessesary to have the special power supply? Couldn't I make do with just using better fuses as a safety?


    It may be overkill to have it arranged this way. And if you want to do it "treadmill style", you should be able to just replace the whole PFC power board with a rectifier and set the apropriate range limits in software (Id: that's a good idea actually, I'll put it in as a redundant config option).

    Personally though I don't like it. Just doing PWM off straight rectified mains is going to be electrically noisy for one. I also have a suspicion that even though a limited PWM duty keeps motor speed down, the high-voltage peaks that still go through the motor are what causes the most common failure; overheating.

    If using a properly regulated power supply from the start solves the issue of motor-overheating, I may be able to remove the temperature interlock from the design completely. But this is again entering into the "black magic" area of motor control, so we'll just see if behaves well enough when the time comes.

  • Progress through proper planning

    Sci07/11/2014 at 00:48 0 comments

    First things first. If I want to get this done properly, I need to plan properly. To that end I've started using some "mind map" software (a fancy way of saying "spider-diagram") to lay out the various notes about this project. I've only discovered this method recently, but I'm finding it a lot more natural and adaptable than linear lists.

    Version 1.0 of the list is uploaded as a graphic. Green items are the basics to cover in the prototype, yellow in the next version (an extension of the prototype really), and the third will likely need to be a wholey fresh build, built on what's learnt from the first two iterations.

    A fourth version isn't mentioned, but will likely be required to tidy up the layout of adding in the additional sensors.

    First stage though is finding someone with an up-to-date version of MS Word so I can use the PFC design calculator. The macros don't seem to like Open Office.

View all 4 project logs

Enjoy this project?



Steve wrote 02/10/2018 at 17:08 point

Did you ever finish this project?  BTW,  Chester Machine Tools doesn't sell this model anymore.

  Are you sure? yes | no

Mike Szczys wrote 07/28/2014 at 18:20 point
Hello Sci, looking good! Don't forget to add a concept video of no more than 2-minutes, post your system design document, and add one more project log to reach the minimum requirement of 4. Thanks!

  Are you sure? yes | no

Sci wrote 07/28/2014 at 23:05 point
Thankyou Mike. I have the video uploaded to youtube and tagged as described in the rules. Where should I put it on this project? Embedded in an entry or as a dedicated link?

  Are you sure? yes | no

Mike Szczys wrote 07/28/2014 at 23:14 point
I think making it an external like is a good choice but you could embed it to. I show both in this demo video:

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates