Resolver motor commutation (motor guru help)

I have a 6 pole motor that will be spinning at 6000 RPM (inverter frequency
= 300 Hz). The motor has a 6 pole resolver that has a 10Khz reference
frequency. A new angle will be computed every 100uS.

300Hz = a period of 3.333mS
If the resolver is sampled at 100uS there will be 33.3 updates during one
electricl cycle or every 10.8 degrees.

Is this sufficient for spinning a motor in constant speed control? Assume
slow moving torque loads.

What would be the minimum sample rate for the resolver to maintain control
of the motor?
something like 10 samples/cycle?

 

If the motor (I assume it's brushless) is going at an exactly steady speed,
with an exactly steady torque, you never need to sample the resolver at
all -- you just need to drive it with what you have been driving it with
(remember it's already going a steady speed) forever.

More important that asking what rate you need to sample your resolver at
vs. the speed of the motor, you should be asking what rate you need to
sample your resolver at vs. the bandwidth of the control loop, and the
bandwidth of any speed disturbances you expect to see on the motor. Taken
that way, you can get away with sampling the resolver at quite low rates,
although sampling close to or below 2x your inverter frequency will become
inconvenient.

For me, if this were a short-run or low volume product I'd go ahead and
sample at 10kHz and make sure I was buying a processor (you are doing this
with a processor, yes?) that could handle the math. One month's worth of
a full-time engineer will buy several hundred $25 processors, after all.

OTOH, if you're talking about something that's going into thousands of
units a year, then sample at 600Hz + 4x (control loop bandwidth). You'll
spend up to a man-month tearing your hair out over algorithms, but you'll
save $$ on the processor, so it'll work out.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

 

If it's an induction motor driven at a constant frequency, what's to
control? Inverter frequency?

At 6 grand, the motor will have a lot of inertia. You could close a
pretty tight control loop at 100 samples per second. Any more is
gravy.

John

 

It's a Permenant magnet AC motor with sinuoidal BEMF. It's about 1.7"
diameter x 6" long, so the intertia isn't extremely high but is
considerable.

I'm doing this with a 100MIPs DSP so I have plenty of processing power. The
resolver angle calculated every 100uS determines the phase angle of the
three output voltage waveforms. The calculated angle fed into the inv Park /
inv Clark transforms to determine the three phase output voltage levels. So
each time the resolver is read it directly controls the output volage to
thet motor.

 

For commutation, you need to establish absolute position.

Most, if not all, commercial designs using PM 3-phase motors use encoders,
rather than resolvers, with a 4-bit Gray code commutation signal,repeated
for each pole pair, and separate quadrature plus one-revolution pulse
signals for velocity/position. There are lots of encoders on the market,
which are relatively cheap. That does away with the need for stable
excitation, too.

Resolvers, at least rotary ones are uncommon, now. Linear ones are still
sometimes used for secondary position feedback in precision systems.
Rotary resolvers used to be used mainly with DC motors having analog
control.

IOW, the world does the job with 16 discrete steps per pole pair. You
should be able to get an idea of how fast you need to sample from that.

 

So the 4 bit encoders provide 16 postion steps within one electrical cycle
of the motor. My application with resolvers allows me to sample the
position 33.3 times per cycle. So I chould be good. Correct?

If I take 16 resolver samples per electrical cycle, them the max speed I
could achieve with that setp (assuming sufficient bus voltage) is a little
over 12K RPM. Correct?

thanks,

All of the encoders I had seen were 10bit 1024 step type which was way
beyond what I could achieve.

 

You.... Wescott are some sort of old whore pedalling some sad version
of your perception of shite in the hope of a bit of money.

I'd rather buy the Nigger from NZ a pint and watch the All Blacks
Stuff France than pay you a cent for your concept of PID insultancy.

No offense mate, I just think you are some sort of twat.

DNA

 

If you're looking for absolute encoders?, look at Gray code units.
Those can give you precise position with in it's own resolution.
most common units are 4 wire out, this gives you 16 combinations of
data that you can use to know exactly where the rotor is.
We have a brushless DC motors at work using this method.

 

Tim,
You're correct it is a "brushless" 3 phase PMAC motor with sinusoidal BEMF.

The torque is not constant but doesn't move extremely fast(something like
1Hz bw.)

I'm using a 100MIPs processor with a 120nS A2D sample rate so I should have
plenty of processor for this task. The resolver angle is used to determine
the necessary phase angle of the inverter output voltage to keep the motor
turning. This requires several updates during the electrical cycle to
create a clean sinusoidal output for the motor. Since the RPM of motor
varies depending on the setpoint (0 - 6000RPM) and the resolver reference
frequency is fixed, the faster the motor turns, the fewer samples you get
for each electrical cycle of the motor.

I'm wondering what would be the minimum number of samples / cycle to
maintain a sinusuodal shaped phase currents?

I do know that a brushless DC motor operates with only 6 commutation points
to turn the motor with trapiziodal drive. Others in this discussion have
suggested that 16 points is what the industry uses via gray code encoders.

 

You still won't have *absolute* position detection, relative to a pole
pair. The control system needs to know where the rotor is, relative to the
stator, immediately on startup, with the rotor still stationary. Resolvers
don't do that.

You haven't said what the characteristics of the motor are, but 12000 RPM
seems a little optimistic. Most AC servo motors weigh in at 2000 - 3000
RPM, maximum.

A little more knowledge of the intended application might help. It may be
that you don't need controllable positioning, just speed and torque, in
which case you'd be better off with an induction motor. A resolver *would*
work with that.

I've never seen a 10 bit encoder on a servo. They're almost invariably 4
bit for commutation, plus 2 quadrature pulse channels at 2000, 2048,
3000, etc. etc, pulses per rev. and a third channel giving one pulse per
rev. There must be a couple dozen firms out there making them.

 

Yes we measure the resolver angle with a constant current DC flowing through
the phases at startup. This gives us the offset between the resolver
position and the BEMF.

12,000 RPM was a theoretical number, we'll be running at 6000RPM for this
application. We don't need position control of the motor beyond what is
need to commutate it. We do need the small size and power provided by a
rare earth magnet PMSM vs an induction motor. We require a small diameter
motor <2". The induction motor quote was 50% longer for the same
performance as the PMSM. Total power will be 1HP.

 

If I read you right, that means you don't mind a bit of uncontrolled
movement at startup. I was assuming this was a servo, where you'd want the
motor to stay stationary until commanded


-snip-

OIC.

I'd still have gone for an encoder, though, if only to do away with the
need for excitation.

 

Resolvers do do that. Incremental encoders dont.

Even the crappiest ones do 4000, not many go above 6000.

Once again your way off, stick to what you know about.

 

Most CNC axis drives 2000RPM

 

That maybe so but it has nothing to do with the typical specification
for a brushless servo motor.

 

If you discount the really tiny stuff, it's a major slice of the market.

 

I dont know what point that statement is supposed to be making.

 

You used the word "typical".