close-circle
Close
0%
0%

Brushed DC Servo Drive

Low cost PID servo drive for small CNC machinery

Similar projects worth following
This servo drive is able to supply a brushed DC motor with up to 7 A continuous current at up to 36 V (approximately 250 W or 1/3 HP) while also performing closed loop control with feedback from a quadrature encoder, and accepts the widespread STEP/DIR signals; thus providing a drop in replacement for the ubiquitous stepper motor in linear positioning applications, like those found in, you know, 3D printers, CNC routers, milling machines, pick and place machines and laser cutters. I could also be used as the power stage for mobile robots that require odometry.

MCU for closed loop control

An ATmega328 microcontroller operating at 20 MHz is present to read the STEP/DIR signals from the machine controller, read a quadrature encoder input and perform the calculations required for PID control of the motor position.

It also controls an indicator LED for signaling the different fault modes the device is able to detect, such as motor overcurrent and driver undervoltage.

MOSFET driver

A DRV8701 full bridge mosfet driver provides the capabilities to drive the MOSFET gates at an appropriate voltage with acceptable switching speed, while also protecting them from being damaged from heating due to insufficient gate voltage, shoot-through, etc.

The IC also provides a low side current sense amplifier that uses an external 10 mOhm power resistor to produce a voltage drop across it for the amplifier. The MCU reads the amplified voltage signal (gain is 20) easily with an 8-bit ADC.

Finally, the driver also performs a current limiting function to avoid damaging the transistors. The current level is set via two resistors in a voltage divider configuration.

MOSFETs in H bridge configuration

The device utilizes four IRFH7545 MOSFETs. This transistors have a breakdown voltage of 60 V and a RDSon of 4.3 mOhm typically (or up to about 9.5 mOhm at 150 °C Tj) with a Vgs of 10 V.

Device Characteristics

Parameter

Min

Typ

Max

Unit

Motor side voltage

6

36

V

Motor side current

0

7

A

Logic side Voltage

4.5

5.5

V

Logic side current consumption

20

50

100

mA

Step signal frequency

0

50

kHz

Encoder frequency (4x)

0

50

kHz

Error signal output current

0

50

100

mA

Ambient temperature for operation

0

50

°C

lbr - 15.13 kB - 08/23/2016 at 22:51

download-circle
Download

Adobe Portable Document Format - 15.99 kB - 07/24/2016 at 19:42

eye
Preview
download-circle
Download

C Source File - 8.70 kB - 02/26/2016 at 08:32

download-circle
Download

Adobe Portable Document Format - 557.59 kB - 02/26/2016 at 08:32

eye
Preview
download-circle
Download

Adobe Portable Document Format - 1.72 MB - 02/26/2016 at 08:32

eye
Preview
download-circle
Download

View all 7 files

  • 4 × IRFH7545TRPBF MOSFET N-CH 60V 85A 6-PQFN
  • 1 × DRV8701ERGET IC MOTOR GATE DVR DC 24VQFN
  • 1 × ATMEGA328-AU Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × 445C25D20M00000 CRYSTAL 20.0000MHZ 18PF SMD
  • 1 × SML-D12V8WT86 LED RED DIFFUSED 0603 SMD

View all 21 components

  • Crowdfunding campaing status update

    ottoragam01/18/2017 at 21:23 0 comments

    At just 3 days from the end of the campaign, the project is just 800 dolllars away from the goal.

    Now is the time to get your own board at https://www.crowdsupply.com/citrus-cnc/tarocco

  • Funding Campaign Started!

    ottoragam12/09/2016 at 02:25 0 comments

    The Crowdsupply funding campaign is now live! If you find the project useful please consider backing it.

    https://www.crowdsupply.com/citrus-cnc/tarocco

  • Take a look at the new servo drive

    ottoragam09/26/2016 at 19:05 0 comments

    Just wanted to keep every follower updated on the status of this project. I made a new controller design, for improving mainly the microcontroller and current handling capability. You can check the new project here: https://hackaday.io/project/15025-tarocco

    I'm launching a crowd funding campaing for it too, here: https://www.crowdsupply.com/citrus-cnc/tarocco

  • Circular form factor by Bogdan Fargas

    ottoragam08/23/2016 at 22:50 0 comments

    Update: taking down the design files for this version due to an error. The fix is in the works!

    I got an email from Mr. Bogdan Fargas informing me of his modified PCB for servo drive. He needs to control a GR63x25 DC motor from Dunkermotoren for a coil winding machine. He wanted to stack the motor, the encoder board and servo drive board, so he created a circular PCB version of said boards.

    I've been given permission to post his files here. Hopefully they'll be of use to some of you!

  • CNC mill working! (pic heavy)

    ottoragam07/01/2016 at 01:31 0 comments

    I'm finally done building my CNC mill. For the past half year I've been buying the parts and machining the structure out of 1/4 in thick steel plate on my "bigger" manual mill, a ZAY7040.

    The machine characteristics are:

    • Weight: 55 kg/ 120 lb (99% steel)
    • Rapids: up to 400 ipm/10 000 mm/min
    • Motors: 24 V 20 W output power at maximum efficiency brushed motors (60 W maximum output power)
    • Linear motion: 12 mm diameter 4 mm lead ballscrews, 12 mm linear rails, back to back angular contact bearings on the fixed side, deep groove bearing on the floating side, spider couplings for the motors
    • Travel: 160 x 120 x 80 mm (X,Y,Z)
    • Spindle: 800 W 220 VAC three phase synchronous motor
    • Motor driver: pretty obvious :)
    • Machine controller: Beaglebone running machinekit with a custom cape for the signal connectors, e-stop, limit switches...

  • The commercial side of this thing

    ottoragam06/03/2016 at 23:52 0 comments

    I've been working with James Newton, of Linnistepper fame, on an open source commercial low cost closed loop motor conversion system. An encoder board is available for sale, along with a PIC based PID controller.

    https://cdn.hackaday.io/images/5569361461622297516.jpg

    The relevant links are here:

    Hakcaday.io project

    https://hackaday.io/project/11418-massmindorg-abosoluteincremental-rotary-encoder

    Purchase here!

    http://techref.massmind.org/techref/io/sensor/pos/enc/ENC1.htm

    http://techref.massmind.org/techref/io/servo/BOBPID.htm


    This project may also be of interest to some of you. It is a low cost 40V 18A H bridge based on the same FET driver as my smaller servo drive project, with some easier to cool transistors.

    https://cdn.hackaday.io/images/5344591461622861291.jpg

    https://hackaday.io/project/11419-massmindorg-40-v-15-a-output-dc-motor-drive

  • Avoiding motor runaway

    ottoragam02/26/2016 at 08:23 0 comments

      The other thing I wanted to address is the detection of a faulty encoder, in particular, I want to be able to handle the loss of the quadrature signal and an incorrect A/B channel wiring.
      First, motor runaway caused by an inverted encoder channel signal is controlled via programming a following error check. When the driver tries to rotate the motor in one direction, the encoder will output a poulse train that corresponds to rotation in the othe direction, thus incrementing the error magnitude until it surpasses the following error value, and when this happens the driver stops the motor.
      This test also gives the driver the ability to signal when the motor is lagging too much and avoid ruining a CNC job.

      A encoder signal loss also causes motor runaway. We could analyze the following cases:

      1. Lost encoder signal and STEP input present. In this case, the error will grow each time a STEP pulse is present, until the following error value is reached, and an alarm is raised/motor is stopped.
      2. Lost encoder signal and no STEP input present. This case happens when the motor still needs to move an amount of "steps" that is below the following error value. The two conditions I'm using to determine if this case occurs are: comparing the current encoder state to an inmediate previous one to see if the signal changed, and checking if the STEP input is firing. The tricky thing with this heuristic is that not changing encoder signal + no STEP input conditions happen also in normal operation, when the motor has reached the desired position and is waiting for the next move.

      Becasuse of that, I can't just make the driver signal a fault when those conditions are met. One could think on cheking the PID output value too, to see if the motor is commanded to be moved when the encoder state is not changing, by looking at the duty cycle value, but that's not really a reliable option because of the value that we compare the duty cycle against may not be easy to determine, as it varies with the PID calibration, motor cogging, etc.
      I decided to just zero the duty cycle if the two conditions I mentioned are met for a certain number of times (to filter false positives). This way, I avoid motor runaway, but I also allow the servo drive to further receive STEP signals in case everything was functioning correctly.
      The driver must perform the aforementioned tests continuously to be able to stop the motor at any time if something occurs to the encoder.

      In the following video I start the motor and apply pulses to the STEP and DIR inputs. The algorithm discerns between a finished move status and a disconnected encoder status, and stops the motor when the encoder gets disconnected (and lights the LED).


      I'll upload the updated code to the project's repo. I also need to program something to detect when only one of the encoder channels is lost.

  • Servo drive speed test

    ottoragam02/26/2016 at 07:35 0 comments

    I wanted to find if the controller could accept a higher STEP pulse frequency, so I took out a Mitsumi printer motor with an integrated encoder (334 divisions, 1336 cpr with 4x decoding) from my parts bin.

    I programmed another MCU to generate a 83 kHz square signal, and fed that signal to the servo drive. I also updated the quadrature decoding routines to light the error LED when the encoder state changes to a value that doesn't correspond to the previous or next step with respect to the current step in the sequence. I couldn't make the LED to light, so I'm assuming that the AVR is not missing any pulses.

    One could argue that the MCU may be missing more than one step pulse, thus not meeting the error condition, but I find very unlikely that the microcontroller misses the "correct" amount of puses tens of thousandths of times during the short test.

    The video shows me measuring the signal frequency on one of the encoder channels, and then measuring the STEP input frequency, wich is nearly 4 times higher as is supposed to be.

    You can see the error LED turning on at the end of the video when I disconnect the encoder, causing the drive to detect an erroneous quadrature sequence.

  • A few more details...

    ottoragam02/08/2016 at 01:53 0 comments

    I present you with the motors I'm using for my milling machine, and a video I took for my quadrature encoder project of the servo drive controlling the "steps" of one of those motors, and the accelerating and decelerating it.



    I'd also like to add a to do list:

    • Add serial interface for configuring PID parameters without recompiling and uploading the firmware.
    • Create a GUI for adjusting said parameters
    • Change 100 uF capacitor footprint
    • Change current limiting approach (I think it would be better to utilize the MOSFET driver's current limiting function instead of the uC for this task).
    • Add more indicator LEDs
    • Desgin a case

  • A little background

    ottoragam02/06/2016 at 03:33 0 comments

    This project came to be when I became tired of searching for a commercial option for closed loop position control for a CNC machine I'm developing.

    The majority of the retrofit CNC drives I found were stepper motor drives, and altough many brushed or brushless drives exist, they're more expensive than the stepper drives ($100 USD and upwards).

    Going into hobbyist controller territory, another issue arises: a lot of the commercially available designs are IC based, and frankly, motor driver ICs are shit. They have too much internal resistance, and they're more expensive than a MOSFET/gate driver combo for switching the same load.

    I did manage to find some discrete transistor designs that were the right price, but some of them weren't usable at the current or voltage I require for my motors, or were not designed to receive feedback from a quadrature encoder.

    I decided then to develop my own brushed motor servo drive. Why brushed and not brushless? Well, because brushed motors for this kind of application are easier and cheaper to find. You can buy some very very good surplus motors, take them out of machines or buy some cheap gearmotors and use them with or without the garbox, in contrast with the BLDC motors, RC ones are the only cheap option, and those spin too fast and may need cooling when used in a non moving machine (as in not an airplane).

    Then, I decided that 250 W of output power (per controller) was more than enough for a desktop CNC machine. Lets take a look at an example case:

    I got some 24 V 20 W rated (output) motors. They develop 700 gcm of torque at 3000 rpm. For this, they consume 1 amp, so the input power is:

    where P is power, I is current and V is voltage. The output power and efficiency are

    where E is efficiency, Tau is torque and Omega is angular speed. The efficiency is really nice (it may be the manufacturer inflating numbers a little). I chose to use 5 mm lead ballscrews in my machine. So the thrust my motor is going to generate is:

    where F is force, Tau is torque and L is screw lead (assuming 100% efficiency of the system). And the axis could theoretically move at 15,000 mm/min.

    So if with 20 W of motor powerwe can achieve that, why are 250 W needed (in this case 168 W, I'm powering the motors with 24 V, remember). Well, the axis may need more torque when pushing the material against the tool, and when the motor develops more torque, it slows down, and uses more current, until it stops spinning completely, and when this happens, its output power becomes zero but its output torque (along with the input current and thrust) reaches its maximum. In my motor's case I have 6,000 gcm of torque at 7.5 A. So the power being used by the motors is 180 W, a bit higher than 168W, but the thing should be able to handle it. In fact, the screw terminals are the thing that limits my current, the ones I'm using are rated for 8A. That's why I need the full power output from my servo drive, to reach maximum thrust (about 740 N).

    Finally, I decided that a small footprint would be preferable. I was able to lay out my board in a 40x40 mm area, using 2 layers. Perhaps in the future I'll change the design to use 4 layers to improve MOSFET cooling and reduce EM emissions.

View all 10 project logs

  • 1
    Step 1

    The device supports two 3.5 mm terminals. The one marked with the MOTOR-A and MOTOR-B labels should be connected to the motor power cables. The other terminal, marked V+ and V- should be connected to a power supply of the correct voltage, ensuring the correct polarity of the connection.

    Two JST PH headers are also installed on the board. the 4 way PH header accepts the encoder signal inputs and supplies 5 V to said encoder. The 6 way PH header is used for supplying 5 V to the board’s logic side, accepts the STEP, DIR and RESET signal from the machine controller and has the open drain ERROR output to inform the rest of the system of a fault condition.

    The last connector present is a 3x2 0.1 in pitch male header. It is used for reprogramming the MCU present on the board.

    Every microcontroller input present in the PH headers has a 330 Ohm resistor connected in series for protection against a mistake when making the connections or a misconfiguration of the pin in the case of a firmware change.

View all instructions

Enjoy this project?

Share

Discussions

Jiannong wrote 07/01/2017 at 03:41 point

Hi Ottoragam,

Where can I buy some of this driver to do some testing?

 I suggest to use ST STM32F3, because these ARM chip is more popular and bit cheaper.

  Are you sure? yes | no

Andrey wrote 07/02/2016 at 11:47 point

Hey. your project is very good. Very good for home use. I have a few questions: Will your driver work with the encoder (http://ru.aliexpress.com/item/AB-Two-phase-5-24V-400-Pulses-Incremental-Optical-Rotary-Encoder/32258485761.html?spm=2114.30010708.3.110.7EriNV&ws_ab_test=searchweb201556_0,searchweb201602_2_10048_10047_10037_10017_405_507_10046_10045_406_10032,searchweb201...) and what changes you need to make to your code for atmega 328

  Are you sure? yes | no

ottoragam wrote 07/02/2016 at 20:16 point

Hi Andrey, any quadrature encoder will work with the project, no extra work is required!. Only make sure the pulse changes from that encoder are clean.

  Are you sure? yes | no

MaxVandenbussche wrote 04/24/2016 at 08:42 point

Hi!

I really love your project. I've loaded your code into an Atmega328 @ 20MHz to do some testing. We have a big old CNC mill/plotter in the lab. Driven by a (failing by now) old windows DOS PC where the servo loop was implemented on a ISA-bus card.

Unfortunately the little µC was to slow. The incoming quadrature was 80kHz and higher. We checked and the µC was missing steps. The machine is also really powerful and i liked to have some overhead.

We ordered some Atxmega16e5 chips and I wrote some new code based on your approach. And the first tests are looking good! These chips can decode quadrature and count a timer register in hardware by using Atmel's new 'evensystem'.  No interrupts needed there. They have a build in DAC, which is useful, because the machine has oldschool brushed DC drives (@ 90v!), and these need an analog input signal. I must say, i'm really impressed by these little micros.

So anyway, thanks for sharing this project with the world. It really helped advance ours!
Keep up that good work!

Max

  Are you sure? yes | no

ottoragam wrote 04/24/2016 at 18:01 point

Thanks for your input, Max. It is super cool that you tooke the time to test the Atmega328p. I am more confident now that rating servo drive for 50 kHz was a good choice.

The Xmegas... I've been wanting to try one for years, but I still have to buy one of them. They must be a beast, with the encoder counter running asynchronously, and at 32 MHz!

Good luck with your project!, it is always nice to talk with a CNC enthusiast!

  Are you sure? yes | no

shadowgamesarts wrote 02/19/2016 at 04:52 point

This project is exactly what I've been looking for!  Between the savings building these (and also the encoders you designed) vs buying a professionally built one are going to enable me to retrofit an old industrial mill that at this point is an incredibly oversized paper weight (I've run the physical calculations and they do put out plenty of power for what i need them to do). I'm definitely no expert with electronics but i know the basics. Once you get into concepts like voltage division I get lost. I've got a couple of questions though. 

 Your BOM and Components list differ slightly.

I know that 2 of the resistors in your schematics are for the voltage divider to limit current, but the only resistors that don't match up with the rest of the components are (2) 1k resistors (r1, r2, r3, r4 on schematic) and (1) 68k resistor (r6 on schematic). Which two of these determine the limited current? And how is that calculated? 

The other inconsistency is with capacitors, (6) of the (8) 0.1uf capacitors listed on BOM are accounted for in components, but there are (2) 22pf capacitors on the components list that aren't on BOM. I'm assuming these (2) are to make up for the other missing (2). But where are these 22pf capacitors located on the schematic? (c1, c2, c3, c4, c5, c6, c8 or c9)?

I also read that the limiting factor in the design is the 3.5mm terminals (you said yours were limited to 8a). If I were to use terminals rated for a higher current, say 14 amps, would any other components need to be changed to accommodate that? (other than the current limit, which i covered earlier).

Again, this is an awesome project, and your work looks very professional. Any other tips would also be appreciated! Thanks again!

  Are you sure? yes | no

ottoragam wrote 02/19/2016 at 06:09 point

Hi! this is going to be a lenghty answer, so I'm gonna send it as a private message to you.

  Are you sure? yes | no

esot.eric wrote 02/17/2016 at 06:18 point

Wow, these catz is really goin' after yah!

If you go the route of a uC with dedicated quadrature-decoding, or even an external quadrature decoder like the HCTLs, then nobody learns anything! Of Course those systems can handle it... they could handle it while simultaneously putting a lander on the moon, with a little effort. CNC's been around since *long* before 8bit processors could run faster than 1MIPS, and now people are complaining that 20MIPS ain't enough? Handling 30,000 counts per second with a lowly-AVR and no dedicated decoder while also handling the feedback loop and handling communication... Not to be scoffed at. 

Them Folks is why my friggin' high-end 3D video card of only a few years back can barely render a friggin' spreadsheet these days.

  Are you sure? yes | no

ottoragam wrote 02/17/2016 at 06:29 point

Hi there, Erick. Overall I think it's better to have powerful hardware even though most applications waste it being inneficcient (well, maybe not if you need to buy said hardware frequently), cause some people will make awesome things with it. Just an hour ago I found out that I cannot make the AVR miss a count at 70, 000 counts per second, even when randomly reversing the motor's direction without ramping. 

I'll try to upload a new log this week, with said test, and a motor runaway prevention test.

  Are you sure? yes | no

esot.eric wrote 02/17/2016 at 07:29 point

wow, 70k! That is impressive. Oh, those 1MIPS 8bitters I was talking about almost certainly used dedicated decoder chips/circuitry ;)

And, yeah, I agree there are some great things people are coming up with without having to spend as much effort on code-efficiency. "It's a good thing." I just wanted to rant about my spreadsheet rendering.

And, yeah, I'm using a 32-bitter at ~100MHz these days... But the same code's running nowhere near 5x as fast (nevermind the extra bits), but that's another rant.

Keep it up, yo, whatever route you take.

  Are you sure? yes | no

David wrote 02/17/2016 at 05:49 point

How could I Build One

I Have a project I would not mind testing it on (lasers any one)

Have a laser welder that it should work with

  Are you sure? yes | no

ottoragam wrote 02/17/2016 at 06:01 point

Hi  David, take a look at the PCB files and the source code https://github.com/ottoragam/Brushed-DC-Servo-Drive

You can order some PCBs on OSHPark, Itead Studio, SeeedStudio, or the recently created Dirty PCBs. The components could be purchased via Mouser or Digikey. You can buy everything for assembling 3 controllers for less than 100 very very easily (unless you pay expensive shipping options). 

Do you have selected any motors/encoders for your machine?

If you have more questions, I'll be happy to help, just shoot me a message or mail me at ottoragam at gmail.com

  Are you sure? yes | no

John Stockton wrote 02/13/2016 at 23:51 point

BTW - a very interesting parallel project has been done by Benjamin Vetter - here is the youtube link: 

  Are you sure? yes | no

John Stockton wrote 02/13/2016 at 23:38 point

Is there anything that keeps the driver from working at 48V?  That is a pretty common supply for CNC conversions.  Also, have you given any thought to combining linear encoders along with the shaft encoder?  I read on some website that they split the PID loop to have something like PD on a shaft encoder and I on a linear encoder (I think that is how they split it - I'll see if I can find the reference to be sure).   That would allow the system to cancel out any backlash that is common with larger CNC mills.

  Are you sure? yes | no

ottoragam wrote 02/13/2016 at 23:56 point

Sadly the gate driver I'm using is rated only for 45 V (with an absolute maximum of 47 V). You could get my design to operate up to that voltage, but you have to make sure the supply voltage doesn't go above it. The MOSFETS I'm using are rated for 60 V breakdown voltage, and the capacitors (ceramic and electrolytic) are rated for 50 V. All in all I think it is possible to get close to the 48 V mark.

I think I can easily make the PID operate with different sources of feedback for the different terms. In the case you mention, having a second error variable that updates with the secondary encoder, and using said variable to increment the integral error would do the trick. I'd guess the main problem with that would be handling all those extra interrupts from the secondary encoder, so maybe it would be better to use an absolute position sensor that I can just poll when I update the integral error.

Do you happen to know any suitable linear encoder for hobby CNCs? Yesterday I was checking the Austria Microsystems ones, but getting a supply of the necessary magnetic strips of good lenght may be problematic.

  Are you sure? yes | no

James Newton wrote 02/26/2016 at 16:51 point

He's right, you know... 48 volts is pretty common in CNC builds. That's because stepper motors have such problems with speed, and the higher voltage gets them moving quicker. No reason why a 12 volt starter motor couldn't run a CNC machine at twice the speed and power that an expensive, high voltage, stepper system does it, but until we show people that working, they are going to look for high voltage DC motor drivers out of habit.

  Are you sure? yes | no

John Stockton wrote 02/27/2016 at 12:45 point

I previously looked for longer magnetic strips on ebay and found a couple of sources that would sell lengths up to 3 feet or so.  I don't recall who they were now, but I didn't have to look all that hard to find them.  On the AMS sensor, I've read others complain about latency of that sensor, but I never looked into the details enough to see if that would limit performance.  I suspect for the integration term, the latency might not have as bad affect as if it were in one of the other terms (but I'm not a controls guy).  If the latency isn't too bad, that is clearly the way to go for a hobby machine.  Higher end machines use glass scales with very high resolutions - but those seem to cost hundreds of dollars each.

  Are you sure? yes | no

Neon22 wrote 02/13/2016 at 21:20 point

STM32F4 series, and some of the less capable ones, have up to 10 timers. some of which have dedicated quadrature detection h/w for this express purpose. Handled automatically and not interupting the CPU - but can generate interrupts. The F in STM32F4 means floating point. which you might not need. but there are several variants without and all in that 3-4 dollar price point. Please consider.

http://www.st.com/web/en/catalog/mmc/FM141/SC1169?sc=stm32

  Are you sure? yes | no

ottoragam wrote 02/13/2016 at 22:07 point

Thanks for the tip! I'm starting to think is time to let go those 8 bitters. I keep seeing STM32 microcontrollers in the suggestions. Is there a reason for their popularity compared to NXP or Atmel Cortex M parts? I would think all brands have comparable hardware.

  Are you sure? yes | no

Neon22 wrote 02/13/2016 at 22:20 point

they all use ARM cores. M0 to M4 but they differ entirely on their peripherals etc.

Finding eth balance between low power, speed, sufficient ADC, or SPI buses as well as internal Timers for quad detection seems like wher eth choices are. I see many STM32F405 etc chips in use. Just enough CPU, floating point makes some of the math easier, 10 timers, sufficient flash, RAM... seems like a good balance. There is an even cheaper variant locked to 48MHz, smaller package F401 maybe... See if any meet your needs.

  Are you sure? yes | no

K.C. Lee wrote 02/13/2016 at 23:45 point

There are a lot of low cost eval boards (from ST) for STM32F chips that comes with on broad USB hardware debugger.  This makes it easier/cheap to develop with their parts.

  Are you sure? yes | no

misan wrote 02/13/2016 at 15:02 point

Great job. I do agree that keeping the cost low is not always a priority for some projects. I have been working in the same domain for a while (closer to 3D printing than to CNC), now I even have a wifi-enabled controller, have a look at the code https://github.com/misan/dcservo

  Are you sure? yes | no

ottoragam wrote 02/13/2016 at 18:03 point

Thanks misan! I'll check your work as soon as possible. Quick question tough, how fast is the Arduino when dealing with the encoder pulses or calculating the output of the PID? I never got to use the Arduino for control projects due to the fear of it not beign up for the task, and I never checked the libraries source code either.

  Are you sure? yes | no

misan wrote 02/13/2016 at 18:17 point

My guess is that that might be a problem for fast speed motors. But I am now using magnetic encoders with no interrupts. So far I am very happy with the result. OTOH, I am using ESP12E 32bit SoC too, which seems to handle more than a million interrupts per second happily while running my PID code plus wifi/sockets. You are right that general I/O of Arduino libraries is very slow though, so I avoided most of it.

  Are you sure? yes | no

julien wrote 02/13/2016 at 11:58 point

I took a look at the code, its nice and straight forward. Have you checked the reliability of the quadrature decoding? I am usually skeptical about using port interrupts for quadrature especially if you have lots of data communication on the micro as well. It might also be worth looking at a controller with an integrated quadrature decoder. Many of them have them now, even most Bluetooth chips :P 

  Are you sure? yes | no

ottoragam wrote 02/13/2016 at 17:52 point

I have currently tested the driver up to 32,000 counts per second, and so far so good. I plan to do a torture test this weeked to see if I can find some errors. When you say port interrupts, are you referring to the pin change interrupts? The encoder channels are currently hooked up to the two external interrupt pins on the microcontroller, and the STEP interrupt is being handled by a pin change interrupt on one of the pins of PORTD. It is the only pin that has interrupts enabled on that port, so I don't even have to waste cycles checking which pin changed state.

Do you have a part number for that MCU with quadrature decoding hardware and BT? Sounds really interesting :)

  Are you sure? yes | no

julien wrote 02/14/2016 at 01:19 point

Yeah Port interrupts are essentially the same thing. My only worry is that if you decide to use UART the interrupts from the UART may clash because the controller doesn't have interrupt prioritizing. It might be just fine though. Just make sure to included some comunications in your stress testing, escpecially if you are adding a real time GUI

The nRF51822 has it, most STM32 and TIVA chips have it. I think are probably some ATMEL chips with it as well. 

  Are you sure? yes | no

ekaggrat singh kalsi wrote 02/13/2016 at 11:56 point

great work... i have been following and implementing a similar project.https://www.youmagine.com/designs/dc-motor-closed-loop-control-software

  Are you sure? yes | no

ottoragam wrote 02/13/2016 at 17:45 point

Thanks ekaggrat! I'll make sure to take a look at your work too.

  Are you sure? yes | no

ottoragam wrote 02/11/2016 at 03:51 point

Hi Wudgaem. I've tested this controller using the AS5040 encoder with 1024 counts per revolution, with my 24V motors. The motors operate at 4,000 rpm (no load speed), but I don't have a 24V PSU available right now, so they can only reach 2,000 rpm (a bit over 1,900 rpm in reality, I've checked the encoder pulse frequency with an scope). That results in 32,000 counts per second (sort of), and the microcontroller handles that fine. The quadrature decoding state machine I've implemented in my program can detect when an encoder state is invalid. By comparing it to the previous encoder state and seeing if the new state is the next (or previous) entry in the sequence, I can detect if the uC missed one count and raise an alarm (If it misses 2 I'm doomed).

Thaks for the heads up on those Cypress ICs, I'll take a look at them. I was actually playing with the idea of changing the uC to something with a bit more muscle like precisely a Cortex M0 part, to handle the 16 and 32 bit integer operations faster, so your suggestion is spot on.

  Are you sure? yes | no

John wrote 02/13/2016 at 17:55 point

The AS5040 does include direct quadrature output in addition to the digital output -- I'm not sure if that's what you're using.  You can also coerce it to directly drive a multiphase motor.  The AS5045B has quadrature output and 12 bits of precision, although I haven't managed to get my hands on one yet.

  Are you sure? yes | no

ottoragam wrote 02/13/2016 at 18:21 point

Yes, that's exactly what I'm using. They're really versatile encoders, A/B quadrature, PWM and SPI outputs, ant they also serve as sensor for brushless motors (is that what you're saying?)

I think, in my case, the AS5045 is overkill. With the AS5040 I get less than 5 micrometer resolution using a 5mm ballscrew. The 12 bit resolution would give me almost a micrometer resolution, and probably choke the poor atmega328.

What are you planning to use them for?

  Are you sure? yes | no

James Newton wrote 02/09/2016 at 20:06 point

This is really very nice! The components you've selected really do result in a low cost driver and that is NOT the case with 99.9% of the available open source designs. Two questions, which are probably just a result of my not looking in the right places:

I'm a little confused by your assertion that brushed DC motors are low cost via surplus... can you give an example where you are finding them for less than an equivalent brushless motor? RC motors are very reasonably priced these days... And they don't wear out brushes...

I'm also a bit confused about the statement that brushless RC motors "spin to fast"... isn't that the point of the encoder and controller? To stop them at the desired point?

  Are you sure? yes | no

ottoragam wrote 02/09/2016 at 20:36 point

I think the main reason behind the poor adoption of closed loop controllers in hobby machines is the price of the controller, so I tried to attack that issue with my design,

The problem with the BLDC motors spinning very fast is that you'll be underutilizing the motor. In my example, whith a 5 mm lead ballscrew and a 3,000 rpm motor, I get 15 m/min of linear speed, which frankly is a lot (useful for rapids, not so much for milling). RC BLDC motors can easily surpass that at even 12V. Maybe they could be useful on something other than milling. All in all my next project will probably be an equivalent drive for BLDC motors. Also, the brushes are not too much of an issue, they wear out but that takes plenty of time, and you could replace them easily.

Regarding the surplus motors, you could take a look at ebay periodically to see if something nice appears. I got DC servos (Dynetic Systems 220014A) for my bigger mill there for 40 bucks each, when the cheapest one of the same characteristics I found was 70 bucks (chinese Keiling motor).

I hope my answers are useful, and thanks for stopping by.

  Are you sure? yes | no

James Newton wrote 02/09/2016 at 22:52 point

Well, you certainly nailed the cost and your encoder is pretty cool as well. 

I'll be VERY interested to see a version of this for BLDC motors! Perhaps one PCB could serve both depending on how it was populated? That makes a large PCB run much more cost effective.

  Are you sure? yes | no

Ivan wrote 02/08/2016 at 21:43 point

I can try to help with GUI for configuring PID parameters and with serial protocol for data exchange between PC and MC. However I have doubts about "blocking" issues if You want to change or monitor parameters in realtime - is it possible to continuously calculate parameters of PID algorithm, counting pulses from encoder and exchange serial data without interfering those processes with each other? I think servodriver should not receive(and process) any data while it is working(rotating motor). What are You thinking about that?

  Are you sure? yes | no

ottoragam wrote 02/08/2016 at 21:58 point

Help with the communications would be awesome. And I think you're right about doing communications and control separately. Also, have you looked at the schematic? The RX pin is an open drain output (external MOSFET), so that signal would be inverted.

  Are you sure? yes | no

ottoragam wrote 02/06/2016 at 01:09 point

Reply to Ivan "Have You considered to use dedicated IC (Avago HCTL-2032 for example) to
decode encoder signals. This could lower the computational load from
microcontroller"

Regarding the quadrature decoding, I don't really want to add a separate chip for that, because it rises the cost for the project, and because the decoding its not really that demanding (at least at somoething like 50,000 counts per second)compared to calculating the output value of the control loop.

  Are you sure? yes | no

Wudagem wrote 02/11/2016 at 01:35 point

Have you done any accuracy testing at higher pulse counts/sec (30k/sec and higher) to determine if you are missing any pulses on the quadrature or step/dir side? I assume you are using the encoders from your other project, what pulse count/rev setting are you using?


With regards to a seperate chip for the decoding, I've recently been playing with the Cypress PSoC 4 dev kits (~$4 from digikey, CY8CKIT-049-42XX), they have hardware quadrature decoding and a chunk of programmable logic that could be used as a 16bit up/down counter to handle the step/dir pulses as well, freeing up the processor to handle just the PID loop and any serial communications you might want. You could likely implement real-time serial performance data and the PID adjustments while the motor was running without changing the cost much. (ATMEGA328AU is $3.25 and the CY8C4245AXI-483 is $3.91 from digikey)

  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