I developed a dc servo drive based on the DSPic 4012 and OPA549 amp. I would like to know the status of this DC servo drive.

Thanks

Hi, where did you purchase the mitumi motor?

hello @ all where i cun found schematic !!!

tnx 1000!!

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.

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

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.

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

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!

Hi Max - I am very interested in what you have done to up the speed with a Atxmega16e5. I also would like to have a +/-10V signal available for some older drives. Please let me know where you are in this and how we can be in touch. I tried sending you a PM but could not make it work for some reason.

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!

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

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.

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.

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.

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

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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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 

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 :)

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. 

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

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

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.

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.

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?

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?

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.

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.

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?

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.

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.

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)