Posts Tagged ‘motor control’

BLDCs, the Wrong Way

Thursday, May 3rd, 2012

Hall Sensor Boo Boo
The above is a set of scope traces from the three coils of a BLDC which is being commutated incorrectly. Read on.

The job that’s been paying my bills and keeping me away from artsy-fartsy circuits for the past six months involves making a set of these enormous robot doors for a Certain Very Fancy Person’s house. Each door is 13 feet tall, around 7 feet wide, and weighs 1500 pounds. There are 66 of them in said house, and more in the servant quarters(!?!). The circuits on board each door have to handle running an onboard air compressor (which regulates a pneumatic weatherseal) as well as keeping track of temperature to linearize the pressure sensors when the weather gets cold. They also have to charge and maintain sealed lead acid batteries. They have commutated power rails. They have to communicate over said power rails, and do so using an capacitively-coupled data slicer and a proprietary protocol I wrote. This protocol has to be robust enough to bootload the processor over. It’s a proper embedded systems job.

All this having been said, the great majority of the real estate on the PCB is dedicated to running the big BLDCs that make the doors move. This post is some observations particulars of said motors.

I’d run lots of standard DC motors in past, and built H-bridges galore, but this was my first encounter with BLDC driving. As such, I made some mistakes in the prototype. And I am going to lay those out for you, dear reader, such that you might learn from the fires of MY workbench.

The motors in question were Maxon EC-Max 30 series motors with a gearhead. They are small, powerful, and expensive. We decided to use BLDCs for this job primarily because of their size, but the fact that the reliability is generally greater (no brushes) than a standard brushed motor certainly was a bonus. The BLDC driver circuit needed to fit into the stile of this door, which was only 1.5″ wide or so. The motors could be expected to stall under certain conditions, so the motor drivers had to be more Conan than not.

Once that driver was designed and fabbed, the fun on the workbench began.

A quick BLDC review:
Brushless DC Motors are like normal DC motors — except the user has to handle commutating the motor on their own. This means, more or less, wrangling the electric fields in the motor at the right time such that the motor turns. A standard DC motor has a set of “brushes” (usually pieces of carbon) that squeeze against the moving part of the motor (the rotor). These are responsible for getting power from stationary part into the spinning part. As the rotor turns, the brush presses on the correct bit of the rotor to get the fields doing their thing. This is cool because it’s easy to drive and relatively simple mechanically. The BAD thing about it is that the graphite/carbon brush wears down over time, AND the brush-scrape nature of the contact makes a world of tiny electrical arcs inside the motor which look cool but kick off a ton of electrical noise (and audio noise, which in this case mattered).
In a BLDC, it’s YOUR job to energize a set of coils at the right time to keep the motor turning. There are three (usually) coils in the stationary part of a BLDC and a number of magnets in the rotor. The trick is to energize the right combination of coils such that you pull the right magnet to the right spot at the right time. If you do this, the motor turns smoothly. It’s a sort-of-not-really like timing a spark plug, if you’ve ever had to do that.
The trick is, you need to know WHERE the rotor is at any given time, such that you can know when to turn off the last set of coils and turn on the next set. There are lots of ways to do this, but a common one is with hall sensors which read the rotation of the motor shaft via some magnets on that shaft. These are usually conveniently built into the motor. In my case, they read with 60 degree resolution, which is plenty to keep the motor moving correctly. Often, either a piece of hardware or an ISR reads the hall sensors, and then energizes the correct coils. This whole process can be as simple as a look up table.

There are lots of documents on the internet about BLDCs, but there are relatively few about what happens with incorrect commutation. The interesting part is when you mess it up and try to figure out what went wrong.

First step, the datasheet: The Maxon datasheet more or less recommends that you buy the Maxon motor drivers and just be done with it. Our form factor, target budget, and my not-insignificant sense of pride ruled that out. It DOES have a commutation chart, but it’s pictorial and is not that clear about “active high / active low” and other minor details like that. So, I made some guesses and let her rip.

In the course of letting her rip, I saw all kinds of exciting (read: trainwreck) motor beahvior. I figured out how that Maxon ran, but I also made a handy set of rules of thumb about what BLDCs do when you drive them wrong. From this, I made some procedures with which I ought to be able to start out with any unknown three-phase BLDC with hall sensors and derive how to get the correct drive sequencing. It’s like this:

Observations:

1.) BLDCs _WILL_ turn with some combinations of incorrect drive. This can mislead the un-wary.

2.) BLDCs usually not turn if the commutation sequence is mixed up. I assumed this would always be the case. It isn’t.
When a BLDC has a commutation sequence which is out of order, usually you see it STOP at some position and lock up, drawing stall current. If you aren’t on a current limited supply, or your motor drivers are not like Conan, you may damage your drive section. This is because whatever coil you’ve energized is pulling the BLDC to the wrong place and then KEEPING it there, since another set of halls has not been triggered. This probably means you have your driving steps out of order (or are energizing the wrong combination of coils).

3.) The interesting part — the BLDC _WILL_ spin, maybe, if you have the commutation sequence right BUT offset from the hall sensors readings. Meaning, if you are always energizing your coils one step ahead of where they should be, the BLDC will pull the motor to the right spot, but it will draw a lot of power doing it AND you will not have very much torque. If this happens, you probably have your hall sequence right AND your commutation sequence right, BUT they are lined up incorrectly.

Corollary:

1.) If you aren’t sure what your hall sequence is, you can spin the motor with your fingers (or a wrench, or whatever) and read the correct order of hall transitions.
2.) If you aren’t sure what your commutation sequence is, you can try messing with the order of different valid coil combinations and running your motor OPEN LOOP. This means stepping through your coil combinations on a timer, energizing them, and seeing if the motor turns. It will turn with bad efficiency again, and probably draw a lot of current, but it will turn when you have the sequence right. Best to do this on a current limited supply.
3.) Once you have those two pieces of information, you can line them up and figure out the correct drive sequence. This sequence will be the one in which the motor spins with the greatest torque and the best efficiency in both directions (IE, it has to work when reversed, too).

An unexpected benefit of doing this is that you see all kinds of BLDC commutation problems. This is useful when you’re debugging a system later, and have to deal with broken wires or damaged drivers, and can guess symptoms much more easily.

Whitney Dancing Stand Development, Part 1

Sunday, April 10th, 2011

So Cory has a bigass show coming up at the Whitney this summer, and I’ve got SEVENTEEN!! dancing stands to build. They’re different from the last batch in that they have to run synchronously. The idea is to use a PID control loop and sync them via RF. They run on steppers, mostly because it was easy to find steppers that were torquey enough for the application and still fit under the dancing stand easily. The MCU is an Atmel, the RF link is by LINX, and the stepper driver is a TI DRV8xxx part.

Here’s the protos:

Stand Controller Proto

The system has a lot of slop, and I decided to do positional feedback using an absolute position sensing magnetic rotary encoder. This one is by Austria Microsystems. The specs on these are INCREDIBLE, but mounting them takes serious care to get that accuracy. I made a bunch of jigs, you can see this one all strung up under the stand’s driven leg. We’ll see how well they work…

Encoder Jig

Oh, yeah. And we made more bowling controllers. Or mostly my assistant Daniel did. These guys are really getting pretty cookie-cutter:

Moar Bowling

I feel pretty good about the protos of those stands, but my crystal ball predicts something will be screwy. We’ll see.