Do you think NI can fix my PLL?

[CC]

I think the root of your problem lies in the amplifier.

Your brushed DC motor system has magnets attached to the case, a thingy
wound with coils attached to the shaft, an amplifier that delivers
current to a switch, and a switch that directs that current to the
appropriate coils depending on the angle of the shaft with relation to
the case (and hence the magnets with relation to the coils).

Your brushless "DC" motor system has magnets attached to the shaft, a
thingy wound with coils attached to the case, sensors that tell you
where the shaft is in relation to the case, and what sounds like this
gawdaful mess of electronics interposed between your torque command and
your coils.

Which appears to be almost an "industry standard" drive topology. Even
the packaging varies little between vendors.

You say you're driving the brushed motor with a power op-amp that's
being driven by your torque command -- why not do the same thing with
your brushless motor?

Well it was simple with the PM motor, and at only about 45W delivered, a
relatively small and easy to manage heat dissipation.

Get three power op amps that are big enough to

handle the current, take the signals from your motor's position sensors
and commutate your drive current (or drive voltage) command with an
appropriate complement of 405x switches, and do the whole thing
linearly. You won't have any concerns about the internal PWM of the
drive doing weird things because there won't be any. You won't have to
worry about internal sampling in the controller, or weirdo loops, or any
of that, either.

Wow. I never thought of doing it that way. Very interesting. I wonder
how long it will take me to figure out how to do the commutation...

I suspect that if you do this you will find out two things: one, the
room will be warmer when the system is running, and two, the brushless
motor/amplifier system will act a whole lot more like the brushed
motor/amplifier system did.

Yes and yes. I didn't think seriously of attempting a linear drive for
this thing simply because PWM drives are the norm, and I didn't want to
mess with figuring out commutation logic when I could possibly avoid
another case of reinventing the wheel. I also thoroughly expected it
wouldn't be difficult to use an off-the-shelf drive. I get enough flak
for making custom stuff as it is. Once in a while I pick something off
the shelf, and whammo! Shouldn't have done that.

But seriously, isn't using minor loop synthesis (Bill Sloman, where are
you?) and using the drive in it's intended application as a speed servo
a suitable way as well?

As I see it there are three drive approaches for a motor (the following
is as much a question as a statement of what little I know so feel
free to educate):

1. current drive -- this is most commonly used for position servos
since acceleration is proportional to torque is proportional to current.
Position servos like to be able to directly control acceleration.

2. voltage drive -- this is used in speed servos since speed is almost
proportional to voltage with the minor complication of the terminal
voltage not being the same as the back EMF. I started using this rather
than current because that's what was done in the Unitrode app notes that
got me started on this odyssey.

3. For a PLL, one is usually controlling a VCO, which produces a
frequency (speed) directly proportional to input voltage. One also
usually expects that the VCO response, ie., the frequency response of
the phase, is not burdened by zeros/poles close to the desired PLL BW,
so one can treat it simply as Kvco/s.

If a motor is put in a speed servo, then it would behave more like a
true VCO than the first two cases. As long as the PLL BW was safely
removed from the response rolloff (likely to be complex poles) of the
speed servo, one can treat it as well as Kvco/s.

This seems to be a very compelling approach. Also, it allows one to use
off the shelf PWM drive hardware with all it's nice features such as
current limiting, very minimal power dissipation, and small package size.

Of course there needs to be a speed feedback path for #3 to work. As we
know, there are issues with that. For my fast wheel, there is an
encoder available, which would need an F-to-V converter. For the slow
wheel, there would only be the possibility of getting 3 pulses/rev from
the halls.

In a time crunch, which makes more sense? Building amplifiers, or
building F-to-V converters? Or maybe neither if there is a speed servo
drive that can take my encoder signal directly. But that still leaves
the slow wheel with it's lack of anything but the hall signals. This
wheel does however have the advantage of requiring much less power, so a
linear custom concoction might be workable.

The amp building looks like a lot of work. I suppose here it would make
sense to first see what kind of ready-made linear DC amps are on the
market. This also would change my rough sketch of what the final system
package would look like to a larger volume. This may be tolerable.

Here's something:

http://www.aerotech.com/products/amps/bal.html

To summarize we have two different wheels. Here are the parameters and
possibilities for each:

SLOW:

motor: Maxon EC 22mm 50W series, model 167130 32V, no tach or encoder
possible; only 3 pulses/rev from hall sensors
speed: 3000RPM
power: <<50W probably about 10-20W needed
voltage: only needs about 2.5V to reach this speed

options:

1. Not sure if it can be put into a speed servo with only 3pp/rev
feedback to undergo F-to-V. If so, this would be worth trying.

2. Since power is low, a linear drive wouldn't be too large or hot.
Since time is in short supply, a big construction project for drive
electronics is to be avoided. If a commercial linear amp ready made is
available then the approach suggested above to do the commutation
ourselves is viable. This might be the best method if the lack of
finely resolved feedback is a showstopper. Thus this would be a true
voltage drive motor PLL.


FAST:

motor: Maxon EC Powermax 30mm 200W, model 305014 32V
incl. encoder 500 pulses/rev (200kHz max)
speed: 24000RPM (motor maximum permissable is 25000RPM)
power: a lot, probably between 100-200W
voltage: need about 52Vrms to do this
current: would need 4A for 200W at 24000RPM

options:

1. Speed servo using 500pp/rev encoder via F-to-V LM2907 and Advanced
Motion Controls B15A8 drive. Advantage is small drive and avoids wasted
capital for items already obtained. Should be fairly expedient. Wrap
PLL around speed servo. What are the gotchas yet unanticipated?

2. Building a linear drive of this magnitude at this stage of the game
is something I seriously want to avoid. Look into commercial options
for plain linear amps?

The Aerotech linear drive is a possibility. However, if that works with
the encoder to make a speed servo, what is the advantage over the PWM?
One thing is that it might take the encoder directly instead of needing
me to implement another circuit.

Need to find out if the Aerotech can operate open-loop.


Goals:

Build PLL around both motors with minimum of custom construction. Focus
should be on choosing the hardware that will drive the motors leaving
the design problem boiled down to PLL loop stabilization. Must work
around limitations of commercial PWM drives, or perhaps find better
drives... Resolve which topology is best and simplest: PLL around
speed servo, or voltage mode motor drive PLL.


Thanks for interest folks!

 

[CC]

What's this PWM crap, it's slow enough, why not an EC motor driven by
a VCO?

...Jim Thompson

What is "slow enough" and what is an EC motor?

 

[Tim Wescott]

Which appears to be almost an "industry standard" drive topology. Even
the packaging varies little between vendors.



Well it was simple with the PM motor, and at only about 45W delivered, a
relatively small and easy to manage heat dissipation.

Get three power op amps that are big enough to



Wow. I never thought of doing it that way. Very interesting. I wonder
how long it will take me to figure out how to do the commutation...



Yes and yes. I didn't think seriously of attempting a linear drive for
this thing simply because PWM drives are the norm, and I didn't want to
mess with figuring out commutation logic when I could possibly avoid
another case of reinventing the wheel. I also thoroughly expected it
wouldn't be difficult to use an off-the-shelf drive. I get enough flak
for making custom stuff as it is. Once in a while I pick something off
the shelf, and whammo! Shouldn't have done that.

But seriously, isn't using minor loop synthesis (Bill Sloman, where are
you?) and using the drive in it's intended application as a speed servo
a suitable way as well?

I don't know. I haven't worked with much off-the-shelf stuff, and I
don't know just how it's messing you up (or for that matter if there
isn't something else going on). With your time crunch, slapping an
encoder on the thing and seeing what happens may not be a bad way to go,
but if the drive is interfering with smooth motor operation what's to
say it won't continue to do so?

As I see it there are three drive approaches for a motor (the following
is as much a question as a statement of what little I know so feel free
to educate):

1. current drive -- this is most commonly used for position servos
since acceleration is proportional to torque is proportional to current.
Position servos like to be able to directly control acceleration.

I think it's also because it's easier to limit current, and certainly
more visible to your 'main' controller.

2. voltage drive -- this is used in speed servos since speed is almost
proportional to voltage with the minor complication of the terminal
voltage not being the same as the back EMF. I started using this rather
than current because that's what was done in the Unitrode app notes that
got me started on this odyssey.

3. For a PLL, one is usually controlling a VCO, which produces a
frequency (speed) directly proportional to input voltage. One also
usually expects that the VCO response, ie., the frequency response of
the phase, is not burdened by zeros/poles close to the desired PLL BW,
so one can treat it simply as Kvco/s.

If a motor is put in a speed servo, then it would behave more like a
true VCO than the first two cases. As long as the PLL BW was safely
removed from the response rolloff (likely to be complex poles) of the
speed servo, one can treat it as well as Kvco/s.

That's true, except that the motor's mechanical time constant is going
to be pretty darn slow; unless you want to _really_ slow down your PLL
response it's going to be almost as troublesome as it would be sitting
at s = 0 in your current drive case.

This seems to be a very compelling approach. Also, it allows one to use
off the shelf PWM drive hardware with all it's nice features such as
current limiting, very minimal power dissipation, and small package size.

Of course there needs to be a speed feedback path for #3 to work. As we
know, there are issues with that. For my fast wheel, there is an
encoder available, which would need an F-to-V converter. For the slow
wheel, there would only be the possibility of getting 3 pulses/rev from
the halls.

Could you use an external encoder on the slow wheel? They're certainly
out there. You could even have the outside of the wheel notched and
stick your own opto on it. For that matter, if you're going external,
what about a tach?

I was going to suggest just using the encoder output for PLL with a
significantly higher sampling rate, then using a 'D' term in your loop
closure. But that still leaves the question of what the amp is doing to
the signal, which gets back to maybe a frequency to voltage converter
being the right answer.

In a time crunch, which makes more sense? Building amplifiers, or
building F-to-V converters? Or maybe neither if there is a speed servo
drive that can take my encoder signal directly. But that still leaves
the slow wheel with it's lack of anything but the hall signals. This
wheel does however have the advantage of requiring much less power, so a
linear custom concoction might be workable.

The amp building looks like a lot of work. I suppose here it would make
sense to first see what kind of ready-made linear DC amps are on the
market. This also would change my rough sketch of what the final system
package would look like to a larger volume. This may be tolerable.

Here's something:

http://www.aerotech.com/products/amps/bal.html

To summarize we have two different wheels. Here are the parameters and
possibilities for each:

SLOW:

motor: Maxon EC 22mm 50W series, model 167130 32V, no tach or encoder
possible; only 3 pulses/rev from hall sensors
speed: 3000RPM
power: <<50W probably about 10-20W needed
voltage: only needs about 2.5V to reach this speed

options:

1. Not sure if it can be put into a speed servo with only 3pp/rev
feedback to undergo F-to-V. If so, this would be worth trying.

2. Since power is low, a linear drive wouldn't be too large or hot.
Since time is in short supply, a big construction project for drive
electronics is to be avoided. If a commercial linear amp ready made is
available then the approach suggested above to do the commutation
ourselves is viable. This might be the best method if the lack of
finely resolved feedback is a showstopper. Thus this would be a true
voltage drive motor PLL.


FAST:

motor: Maxon EC Powermax 30mm 200W, model 305014 32V
incl. encoder 500 pulses/rev (200kHz max)
speed: 24000RPM (motor maximum permissable is 25000RPM)
power: a lot, probably between 100-200W
voltage: need about 52Vrms to do this
current: would need 4A for 200W at 24000RPM

options:

1. Speed servo using 500pp/rev encoder via F-to-V LM2907 and Advanced
Motion Controls B15A8 drive. Advantage is small drive and avoids wasted
capital for items already obtained. Should be fairly expedient. Wrap
PLL around speed servo. What are the gotchas yet unanticipated?

2. Building a linear drive of this magnitude at this stage of the game
is something I seriously want to avoid. Look into commercial options
for plain linear amps?

The Aerotech linear drive is a possibility. However, if that works with
the encoder to make a speed servo, what is the advantage over the PWM?
One thing is that it might take the encoder directly instead of needing
me to implement another circuit.

Need to find out if the Aerotech can operate open-loop.


Goals:

Build PLL around both motors with minimum of custom construction. Focus
should be on choosing the hardware that will drive the motors leaving
the design problem boiled down to PLL loop stabilization. Must work
around limitations of commercial PWM drives, or perhaps find better
drives... Resolve which topology is best and simplest: PLL around
speed servo, or voltage mode motor drive PLL.


Thanks for interest folks!

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Jim Thompson]

Jim Thompson wrote: [snip]

What's this PWM crap, it's slow enough, why not an EC motor driven by
a VCO?

...Jim Thompson

I'll kick myself when you tell me, but what's an EC motor?

Electronically commutated

Electro-Convulsive? A big hysteresis motor would do, but they can be
pretty dang inefficient -- one that could put out 200 watts might waste
more power than my linear amp suggestion.

The design I did for Bosch was for the A/C blower in Mercedes
vehicles. Up to 20 amps consumption.

I had considered suggesting driving the brushless motors with a VCO, but
that leads to startup problems, which are complex to solve, then you're
back to nasty complex problems -- unless whatever an EC motor is solves
that problem.

Of course I was doing a custom chip, ultimately processed at National
Semi in Scotland. Startup WAS a nasty problem, particularly with a
blower cage that can be spinning the wrong direction when power is
applied... but I'm clever ;-)

Given that the problem originates at a research lab I'm assuming that
getting something that works with a minimum of effort trumps developing
the World's Most Elegant Circuit.

"Working" always trumps "theory".

...Jim Thompson

 

[Jim Thompson]

What is "slow enough" and what is an EC motor?

At 24K RPM, 3-phase, the timing between phases is just shy of a
millisecond.

EC = electronically commutated

...Jim Thompson

 

[Joerg]

Hello Chris,

Of course there needs to be a speed feedback path for #3 to work. As we
know, there are issues with that. For my fast wheel, there is an
encoder available, which would need an F-to-V converter. ...

That would be pretty easy, basically a precise pulse generator (_not_
the usual 555 thingie) whose pulse length is set to the shortest
possible interval at the highest motor speed (minus some margin), and a
non-leaking integrator.

... For the slow
wheel, there would only be the possibility of getting 3 pulses/rev from
the halls.

How about measuring the time between two consecutive pulses and
outputting a DC voltage proportional to that? Could be done via a
counter and a DAC. The DAC would update at every pulse and the counter
would be reset at that same time, to clock up the next episode. Or you
could do it analog.

Goals:

Build PLL around both motors with minimum of custom construction. Focus
should be on choosing the hardware that will drive the motors leaving
the design problem boiled down to PLL loop stabilization. Must work
around limitations of commercial PWM drives, or perhaps find better
drives... Resolve which topology is best and simplest: PLL around
speed servo, or voltage mode motor drive PLL.

As suggested earlier I think you do have to check the quality of the PWM
part and anything before that if you decide to go with a commercial
motor controller unit. If they used an old one-shot as the PWM source
that might be a concern. Take a good look at this with a scope.

Just FYI: The old National LM331 is a chip that I found to be remarkably
clean in V/F and F/V applications.

Another option is to call the engineers at the company that made the
motor controller, briefly describing what you want to do and asking them
whether their product would be capable enough for that. They should know.

 

[Tim Wescott]

Jim Thompson wrote:
[snip]

What's this PWM crap, it's slow enough, why not an EC motor driven by
a VCO?

...Jim Thompson

I'll kick myself when you tell me, but what's an EC motor?

Electronically commutated

That's what the 'brushless' is in this case, unless electronically
commutated means something even more specific.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Rene Tschaggelar]

Hi:


I'm attempting to build another motor PLL system and running into some
difficulties stabilizing the loop. Since there is a lot of work to do,
I have considered contracting out the PLL design to a well known control
expert outside of my company, so I can focus on building other
subsystems of the project.

Basically, the PLL is to lock a 136mmx2.54mm Al wheel to a 400Hz
reference (24kRPM, 1 pulse/rev position sensor). Must be 2nd order PLL
yielding zero phase error with constant frequency input. Wheel to be
driven directly by a Maxon 200W brushless DC motor with an Advanced
Motion Controls B15A8 PWM servo driver running in open loop mode. I
have found that the open-loop mode of the motor drive results in not
very linear DC transfer of ref. voltage in to motor phase voltage out,
as well as not yielding a very linear dynamic response as well (rise
time != fall time, but only by about 10-20%).

[snip]

The problem calls for an analog solution. If neccessary
linearize the VCO. And to start with, measure the open
loop response of the system, then do the math.

Rene

 

[CC]

Hello Chris,




That would be pretty easy, basically a precise pulse generator (_not_
the usual 555 thingie) whose pulse length is set to the shortest
possible interval at the highest motor speed (minus some margin), and a
non-leaking integrator.

Oddly, I haven't touched a 555 since I was a kid. I use a few HC221 and
HC123 when I need a reliable one-shot and can tolerate a few % variation
in timing mostly due to cap tempco. Never had a problem with these.

I was thinking of using LM2907 with one phase of the 500pp/rev encoder
signal directly. This should be easy enough.

Oh I see, by setting a constant pulse width for each encoder tick, then
high speed->high duty cycle / low speed->low duty. So low-pass
filtering that gives a smooth result.

I don't get why an integrator would be desired. That would accumulate
V(t)*dt until saturation.

A low-pass filter != an integrator.

How about measuring the time between two consecutive pulses and
outputting a DC voltage proportional to that? Could be done via a
counter and a DAC. The DAC would update at every pulse and the counter
would be reset at that same time, to clock up the next episode. Or you
could do it analog.

Actually I have a good digital F->V converter. In case you ever need an
off-the shelf instrument, this is a really nice little gadget:

http://www.ectron.com/prods/441.htm

It has been indispensable in measuring the AC response of the motor. I
can scope frequency vs. control voltage. Something like an LM2907 isn't
good for this because to get the ripple down you need to kill the BW.

Perhaps the Ectron F->V should be fed 3pp/rev from the halls. I am also
curious how close to 50% duty the hall signals are. It is remotely
possible that I could get 6 pp/rev fairly evenly spaced.

Another nice F->V converter on the market:

http://www.onosokki.co.jp/English/hp_e/products/keisoku/revo/fv1300.htm



Thanks as always for the input.


Good day!

 

[Joerg]

Hello Chris,

Oddly, I haven't touched a 555 since I was a kid. I use a few HC221 and
HC123 when I need a reliable one-shot and can tolerate a few % variation
in timing mostly due to cap tempco. Never had a problem with these.

I haven't either. But I must confess that I also used the 121 in the old
TTL days. Not anymore, and I hope that can be chalked up to teenage sins

I was thinking of using LM2907 with one phase of the 500pp/rev encoder
signal directly. This should be easy enough.

But mind it's linearity error. +/-1% isn't exactly something to write
home about.

Oh I see, by setting a constant pulse width for each encoder tick, then
high speed->high duty cycle / low speed->low duty. So low-pass
filtering that gives a smooth result.

I don't get why an integrator would be desired. That would accumulate
V(t)*dt until saturation.

A low-pass filter != an integrator.

Sorry, I meant integrator plus S&H. A lowpass will still let substantial
ripple pass. Ideally you'd want nice steps where each level corresponds
to the velocity, like the output of a DAC. That makes filtering a lot
easier. So an integrator would start integrating, then hold and store
when the one-shot time is up. Now it is reset and waits for the next
pulse. You will be up to one pulse behind in phase when doing that,
something that may matter in a clutch application.

Actually I have a good digital F->V converter. In case you ever need an
off-the shelf instrument, this is a really nice little gadget:

http://www.ectron.com/prods/441.htm

Sweet. Even has selectable filters.

It has been indispensable in measuring the AC response of the motor. I
can scope frequency vs. control voltage. Something like an LM2907 isn't
good for this because to get the ripple down you need to kill the BW.

A good sample and hold helps.

Perhaps the Ectron F->V should be fed 3pp/rev from the halls. I am also
curious how close to 50% duty the hall signals are. It is remotely
possible that I could get 6 pp/rev fairly evenly spaced.

Another nice F->V converter on the market:

http://www.onosokki.co.jp/English/hp_e/products/keisoku/revo/fv1300.htm

Man, you guys must have a very comfy R&D budget over there.

 

[CC]

That's true, except that the motor's mechanical time constant is going
to be pretty darn slow; unless you want to _really_ slow down your PLL
response it's going to be almost as troublesome as it would be sitting
at s = 0 in your current drive case.

But a linear system is at least a linear system. Basically, there needs
to be some plan for elucidating if what I have at present is just a
mediocre motor characterization, poor choice of loop compensation, or
trouble with the slight nonlinearities of the drive.

Can you say anything from experience about the implications of "slight
nonlinearities" such as let's say a -25%/+50% variation in DC transfer
gain, coupled with a 10-20% variation in transient response on the
rising edge vs. the falling? Does it seem that such nonlinearities
would make it impossible to get a decent loop going?

Could you use an external encoder on the slow wheel? They're certainly
out there. You could even have the outside of the wheel notched and
stick your own opto on it. For that matter, if you're going external,
what about a tach?

I was going to suggest just using the encoder output for PLL with a
significantly higher sampling rate, then using a 'D' term in your loop
closure. But that still leaves the question of what the amp is doing to
the signal, which gets back to maybe a frequency to voltage converter
being the right answer.

The most promising prospect here is to drill a ring of additional holes
in the slow wheel at a radius where there are no present slits (we
already have the image and speed sensor slits.) I am sure there is some
available real estate. The practical problem for now is whether doing
that, and then developing the mechanics and electronics is a time sink.

I don't think an encoder on the opposite side from the motor is
possible, due to space constraints in the apparatus and also that the
front of the wheel housing is a bearing holder. The substantial
mechanical mods needed here would probably be more time consuming than
drilling holes and adding a little LED and photodiode detector attachment.

So for SLOW wheel:

Step 1: Try another iteration of double-checking the motor+drive
characterization (for a 1st order effort should need just effective
motor voltage constant Kv and the time constant ? ). Feed these numbers
into a PLL compensation scheme and see what we get. If it at least
meets the very loose jitter requirements for the slow wheel (see update
to specs below) then it is good enough for now. Switch focus to fast wheel.

Step 2: If it fails to meet jitter specs then we debate speed servo vs.
modifying to add another fine resolution position sensor.

jitter requirement: 1-1.5 degrees (have to check mechanicals on the
large slit in the slow wheel vs. the narrow slit in the fast wheel)

This jitter is constrained by how much the slow slit can be out of
alignment before it obstructs the view of the fast wheel's slit.

jitter requirement: about 0.58-0.72 degrees. This is constrained by
how much error is tolerable in the Q-switch timing of the YAG laser.
The Q-switch needs to be within about 4-5 us of the correct 200us
timing. this may need to be a little tighter still, if they are using
injection seeding on the YAGs. Have to check this out.

Of course, the two jitters add, so the slow may actually need to be
better than I am estimating at this point.



Thanks for your input, folks!

 

[Tim Wescott]

But a linear system is at least a linear system. Basically, there needs
to be some plan for elucidating if what I have at present is just a
mediocre motor characterization, poor choice of loop compensation, or
trouble with the slight nonlinearities of the drive.

Can you say anything from experience about the implications of "slight
nonlinearities" such as let's say a -25%/+50% variation in DC transfer
gain, coupled with a 10-20% variation in transient response on the
rising edge vs. the falling? Does it seem that such nonlinearities
would make it impossible to get a decent loop going?

Those should be quite easy, if that's all that's going on. You'd have
to make somewhat conservative loop tuning, but you wouldn't have to back
it off that much. The real question is how jitter do you get running
open loop compared to what you get in closed loop. If you're not
getting any significant jitter at all then you should be able to make a
really slow loop and be done with it.

If you _are_ getting open loop jitter you need to deal with it. Then
you need to ask what the frequency content of the jitter is, what the
achievable bandwidth of the loop is, and what (if anything) you can do
to reduce the amplitude of the jitter.-- snip --

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[CC]

I haven't either. But I must confess that I also used the 121 in the old
TTL days. Not anymore, and I hope that can be chalked up to teenage sins

Well then I guess I'm still a sinner. But I do avoid the "pulses
running all over the place" design method rightly castigated in AoE.

But mind it's linearity error. +/-1% isn't exactly something to write
home about.

Oh yeah, that's not so hot.

Sorry, I meant integrator plus S&H. A lowpass will still let substantial
ripple pass. Ideally you'd want nice steps where each level corresponds
to the velocity, like the output of a DAC. That makes filtering a lot
easier. So an integrator would start integrating, then hold and store
when the one-shot time is up. Now it is reset and waits for the next
pulse. You will be up to one pulse behind in phase when doing that,
something that may matter in a clutch application.

Pardon my density, but all I see happening here is that I integrate the
pulses, which are always the same width.

Oh wait, I think I get it. I integrate the not-pulse time! So I get a
measure of the period of each cycle, with a small error equal to the
width of the one-shot pulses. Then hold the integrator value in the S&H
over the duration of the pulses, while the integrator also resets.

Right?

Now I have to go see how the LM2907 works again. I didn't try to
understand it actually the last time I used one. Just needed a quick hack.

Man, you guys must have a very comfy R&D budget over there.

Heh, heh. Yeah. There was actually a dearth of equipment when I
started. I've built things up quite a bit over 7 years. But haven't
asked for anything over about $13k. Still no decent spectrum analyzer,
but at least a trio of good scopes, a logic analyzer which I haven't
used yet :-( and 3 function gens including one of those new Tek models
with the graphical screens. A nice new Kronhite 8-pole Bessel filter.
Still a bit low on power supplies. They get borrowed almost as fast as
I buy them.

 

[CC]

Those should be quite easy, if that's all that's going on. You'd have
to make somewhat conservative loop tuning, but you wouldn't have to back
it off that much. The real question is how jitter do you get running
open loop compared to what you get in closed loop. If you're not
getting any significant jitter at all then you should be able to make a
really slow loop and be done with it.

If you _are_ getting open loop jitter you need to deal with it. Then
you need to ask what the frequency content of the jitter is, what the
achievable bandwidth of the loop is, and what (if anything) you can do
to reduce the amplitude of the jitter.

Well it will be easy enough to take another look at the open loop
jitter. But it leads me to wonder, how does one know if the jitter is
electrical or mechanical in nature? There is jitter introduced by
bearings, etc.

I'll check this out next week!

 

[Joerg]

Hello Chris,

Pardon my density, but all I see happening here is that I integrate the
pulses, which are always the same width.

Oh wait, I think I get it. I integrate the not-pulse time! So I get a
measure of the period of each cycle, with a small error equal to the
width of the one-shot pulses. Then hold the integrator value in the S&H
over the duration of the pulses, while the integrator also resets.

Right?

Yes, sorry, I have worded it wrong. But that's what I meant. The
one-shot time doesn't produce an error, only an offset.

Now I have to go see how the LM2907 works again. I didn't try to
understand it actually the last time I used one. Just needed a quick hack.

You can get this all in a chip but I was never thrilled with their
performance versus a discrete solution. Maybe Analog Devices has
something nice, they are usually the ones who push the envelope.

 

[[email protected]]

But seriously, isn't using minor loop synthesis (Bill Sloman, where are
you?) and using the drive in it's intended application as a speed servo
a suitable way as well?

Beats me. This is a pretty impressive thread about a rather nasty
problem. My guess would be that the dead time in the PWM drive is the
source of the problem, but I've not worked on comparabe hardware, and
consequently my intuitions aren't worth much.

 

[Tim Wescott]

Well it will be easy enough to take another look at the open loop
jitter. But it leads me to wonder, how does one know if the jitter is
electrical or mechanical in nature? There is jitter introduced by
bearings, etc.

I'll check this out next week!

Initially one doesn't know, so one invents ways to test. I would expect
that you'd be able to feel any jitter-inducing torques on your bearings
by hand -- you could work out the dynamics to make an estimate of the
torques involved. If you just _had_ to measure it you could set
yourself up with a triple-pole single throw switch, get the motor
spinning fast then cut it out of the circuit & try to estimate the
'jitter' as the wheel slowly spins down.

Note that from a purely control standpoint the source of the jitter
doesn't matter -- from the control standpoint the only things that
matter are the jitter's power spectrum and the amount that you can
modify the loop's response to jitter. Stepping back from this a bit,
though, if you have too much jitter what matters is how to reduce it
(which is when you decide you want to know where it's coming from) and
how you make a control loop that can be pushed to higher bandwidths.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Michael A. Terrell]

50 years ago when I was a student at MIT and was teching for the MHD
group, I synced all the associated triggering electronics to the smear
camera flywheel with a photo pickup (PMT).

Jim Thompson

"Teching"?


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

 

[Jim Thompson]

"Teching"?

Being a technician... aka designing and building all the stuff the PhD
candidates couldn't manage ;-)

...Jim Thompson

 

[Michael A. Terrell]

Being a technician... aka designing and building all the stuff the PhD
candidates couldn't manage ;-)

...Jim Thompson

What is wrong with just saying, "I was working as a technician."?
There is nothing wrong with being a technician, if your really good at
it.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida