Help with Digital PLL motor control

[Jay]

Hi everyone.

I am working on a digital PLL design for a motor control application and
I need some help with the control-loop aspects. The end goal is to have
my motor achieve phase lock with a reference signal.

Some background information:

My system consists of an FPGA which implements the "digital logic" end
of things such as the Frequency/Phase detector + error counters, PWM
controller, etc. The PFD is setup to drive a counter which keeps track
of the phase difference(in terms of counts) between my motor and a
reference clock. The FPGA is also paired up with a micrcontroller which
I am using to implement a PID loop, provide debug output, etc.

The DC motor I am using has an output that goes high once per revolution
("tach sense") which feeds one input of the PFD(realized in the FPGA).
The other input to the PFD is an external clock signal, so the PFD
compares a reference clock and the motor tach pulse train and spits out
an error between the two in terms of counts(it also has an output lets
me know if the motor is faster or slower than the reference clock).

The problem:

Since I am implementing a digital PID controller (in software on the
uController), usually the sampling rate ("Ts") is factored in the
conversion from a continuous-time to discrete-time control-loop. If it's
important, I am using the Tustin or Bilinear transform to go from C-->D.

The issue I face is that my error counter can only be read when the only
when the motor has spun around and the reference clock has come by(the
FPGA logic provides a signal that interrupts the uC when a new error is
available and then the uC reads the error counter in the FPGA).

Given that the motor will probably be speeding up/slowing down as a
result of the control-loop, this means that I probably will not receive
errors at periodic intervals, thus I cannot factor in one Ts into my PID
code for my discrete-time implementation.

My question:

Can I just keep track of the time between each error event, convert that
to a Ts and use that as my Ts each time I get a new error ("variable
sampling rate")?

Are there any draw backs to this technique?

Are there any alternative methods?

I appreciate all suggestions and information.

Best regards.
-- Jay.

[Fred Marshall]

"Jay" <[email protected]> wrote in message
news:[email protected] ...
> Hi everyone.
>
> I am working on a digital PLL design for a motor control application and
> I need some help with the control-loop aspects. The end goal is to have
> my motor achieve phase lock with a reference signal.
>
> Some background information:
>
> My system consists of an FPGA which implements the "digital logic" end
> of things such as the Frequency/Phase detector + error counters, PWM
> controller, etc. The PFD is setup to drive a counter which keeps track
> of the phase difference(in terms of counts) between my motor and a
> reference clock. The FPGA is also paired up with a micrcontroller which
> I am using to implement a PID loop, provide debug output, etc.
>
> The DC motor I am using has an output that goes high once per revolution
> ("tach sense") which feeds one input of the PFD(realized in the FPGA).
> The other input to the PFD is an external clock signal, so the PFD
> compares a reference clock and the motor tach pulse train and spits out
> an error between the two in terms of counts(it also has an output lets
> me know if the motor is faster or slower than the reference clock).
>
> The problem:
>
> Since I am implementing a digital PID controller (in software on the
> uController), usually the sampling rate ("Ts") is factored in the
> conversion from a continuous-time to discrete-time control-loop. If it's
> important, I am using the Tustin or Bilinear transform to go from C-->D.
>
> The issue I face is that my error counter can only be read when the only
> when the motor has spun around and the reference clock has come by(the
> FPGA logic provides a signal that interrupts the uC when a new error is
> available and then the uC reads the error counter in the FPGA).
>
> Given that the motor will probably be speeding up/slowing down as a
> result of the control-loop, this means that I probably will not receive
> errors at periodic intervals, thus I cannot factor in one Ts into my PID
> code for my discrete-time implementation.
>
> My question:
>
> Can I just keep track of the time between each error event, convert that
> to a Ts and use that as my Ts each time I get a new error ("variable
> sampling rate")?
>
> Are there any draw backs to this technique?
>
> Are there any alternative methods?
>

Jay,

Yes, I believe there's an alternative method. It hinges on why you need Ts
in the first place.

First of all though, I've not used PID controllers as such but only the
old-fashioned linear control design. I suppose that it's easy enough to
translate. A quick look suggests that Ts is simply part of the gain
coefficients anyway. So, once you have a controller, KI*Ts and KD/Ts are
constants anyway, right?

I see that there's KP, KI, KD and Ts in the PID equations. However, the
actual coefficients are:
KP, KI*Ts, KD/Ts so you could call these A,B and C and never worry further
about Ts. Just pick a Ts and pick KI and KD to compensate. In fact, just
to be sure, try this:
Let's say that KP=3, KI=2, KD=4 and Ts=0.1.
Then, A=3, B=0.2 and C=40. If you arbitrarily change to Ts=.2, KI=1 and
KD=20, will the system be any different? From what I'm reading, it appears
not - although it perturbs the bilinear transformation. Does it matter in
practice? That's the question. It might be a good test to see if my
conjecture is OK or not OK. Anyway, this is just an argument and I'm not
sure that it matters in getting to a design. See below:

I have designed motor controls using a tach. One of the issues you will
face is whether you're truly building a speed control or a position control.
Using a tachometer for feedback with a PLL often becomes a position control
and you add an integration term by doing this - since the position is the
integral of the velocity. If the PLL tries to lock the motor tachometer to
the reference clock, then it's a position servo because you're trying to
control the position of the shaft relative to the clock - even though it's a
rotating position, it's still a position at an instant in time.

One thing I might suggest is to select that value of Ts that matches the
speed you're trying to achieve. That's where the control loop is critical.
Otherwise, you do have a velocity servo for dealing with the shaft speed
being much too low or too high. Your controller "switches" from velocity to
position when you go from frequency control to phase control. My suggestion
here is something like using "describing functions" in analyzing a nonlinear
system - where an approximation is plenty good enough. So, this will be an
approximation. Given that you'll need gain and phase margins in the end
anyway, it should be fine.

Then, if you have a range of values of Ts / motor controlled speed to deal
with, I would analyze the system at the extreme values to see which
dominates / is worse......

Somehow you need to consider the delays that are introduced in the
implementation you've described. The interrupt service and associated
processing time is quite concerning. You may not be able to do what you
want with this kind of implementation. You'll need to run the numbers to
see.

With only one sample per revolution, you don't have much data to go on. How
can you be sure that you're meeting the sampling criterion? I guess the
motor could be very slow to respond to any changes but.....
Let me explain further:
What if you apply either drive voltage to the motor or a load that will vary
sinusoidally (just as one example) or perhaps as a square wave AND the
frequency of this forcing function is such that the shaft speed will be
forced to increase during one rotation and decrease during the other
rotation? Will there be appreciable change in the shaft speed at the
frequency of this perturbation? If so, the one-sample-per-revolution
tachometer is insufficient sampling because it doesn't meet the Nyquist
criterion for sampling. This could be a very big deal. It also suggests
that the lowest shaft speed you need to control to is the most critical in
this sense - rather than the largest shaft speed / smallest Ts.

I'm sure it could cause some discussion but let me say this: I think it
doesn't matter what you *think* the perturbation bandwidth can be. What
matters is what the motor is capable of responding to. I think that
determines the bandwidth that you have to be able to sample - since you
really can't predict what frequencies will be present in motor position.

Hope this helps.

Fred

[Jim Gort]

Fred:

I think you are missing the point. Because he can't measure the feedback at
a well-defined sample rate (he can only see that it crosses when it crosses,
and has no idea about the phase of it at any given time of applying a new
input), there is no firm application of Ts. That is, the notion of Ts in a
digital control system implies that, at every Ts, you know the system
output, and apply a new system input. Your discourse implies that Ts might
be "unknown", but in fact it is time-varying (or at least on the feedback
end of things).

There has been much work done for digital controllers with *fixed* phase
delay, meaning that you apply an input, but the D/A time plus the A/D time
creates a *fixed* time delay (but variable phase delay, as phase depends on
current system frequency). However, I'm not sure about his situation, with
variable *time* delay, as he doesn't know the plant position when he applies
control vector at Ts--he only knows plant position when it happens to cross
one of the encoder/zero-crossing positions.

There is hope, though. My thesis advisor at MIT has done some work in
precisely these type of situations (Kamal Youcef-Toumi), and also there is a
wealth of information on the subject from people who provide encoders for
motors, and tell you how to use the encoders to control the motor (just
google "control of motors", or something like that).

Jim Gort

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
news:[email protected]...
>
> "Jay" <[email protected]> wrote in message
> news:[email protected] ...
> > Hi everyone.
> >
> > I am working on a digital PLL design for a motor control application and
> > I need some help with the control-loop aspects. The end goal is to have
> > my motor achieve phase lock with a reference signal.
> >
> > Some background information:
> >
> > My system consists of an FPGA which implements the "digital logic" end
> > of things such as the Frequency/Phase detector + error counters, PWM
> > controller, etc. The PFD is setup to drive a counter which keeps track
> > of the phase difference(in terms of counts) between my motor and a
> > reference clock. The FPGA is also paired up with a micrcontroller which
> > I am using to implement a PID loop, provide debug output, etc.
> >
> > The DC motor I am using has an output that goes high once per revolution
> > ("tach sense") which feeds one input of the PFD(realized in the FPGA).
> > The other input to the PFD is an external clock signal, so the PFD
> > compares a reference clock and the motor tach pulse train and spits out
> > an error between the two in terms of counts(it also has an output lets
> > me know if the motor is faster or slower than the reference clock).
> >
> > The problem:
> >
> > Since I am implementing a digital PID controller (in software on the
> > uController), usually the sampling rate ("Ts") is factored in the
> > conversion from a continuous-time to discrete-time control-loop. If it's
> > important, I am using the Tustin or Bilinear transform to go from C-->D.
> >
> > The issue I face is that my error counter can only be read when the only
> > when the motor has spun around and the reference clock has come by(the
> > FPGA logic provides a signal that interrupts the uC when a new error is
> > available and then the uC reads the error counter in the FPGA).
> >
> > Given that the motor will probably be speeding up/slowing down as a
> > result of the control-loop, this means that I probably will not receive
> > errors at periodic intervals, thus I cannot factor in one Ts into my PID
> > code for my discrete-time implementation.
> >
> > My question:
> >
> > Can I just keep track of the time between each error event, convert that
> > to a Ts and use that as my Ts each time I get a new error ("variable
> > sampling rate")?
> >
> > Are there any draw backs to this technique?
> >
> > Are there any alternative methods?
> >
>
> Jay,
>
> Yes, I believe there's an alternative method. It hinges on why you need
Ts
> in the first place.
>
> First of all though, I've not used PID controllers as such but only the
> old-fashioned linear control design. I suppose that it's easy enough to
> translate. A quick look suggests that Ts is simply part of the gain
> coefficients anyway. So, once you have a controller, KI*Ts and KD/Ts are
> constants anyway, right?
>
> I see that there's KP, KI, KD and Ts in the PID equations. However, the
> actual coefficients are:
> KP, KI*Ts, KD/Ts so you could call these A,B and C and never worry further
> about Ts. Just pick a Ts and pick KI and KD to compensate. In fact, just
> to be sure, try this:
> Let's say that KP=3, KI=2, KD=4 and Ts=0.1.
> Then, A=3, B=0.2 and C=40. If you arbitrarily change to Ts=.2, KI=1 and
> KD=20, will the system be any different? From what I'm reading, it
appears
> not - although it perturbs the bilinear transformation. Does it matter in
> practice? That's the question. It might be a good test to see if my
> conjecture is OK or not OK. Anyway, this is just an argument and I'm not
> sure that it matters in getting to a design. See below:
>
> I have designed motor controls using a tach. One of the issues you will
> face is whether you're truly building a speed control or a position
control.
> Using a tachometer for feedback with a PLL often becomes a position
control
> and you add an integration term by doing this - since the position is the
> integral of the velocity. If the PLL tries to lock the motor tachometer
to
> the reference clock, then it's a position servo because you're trying to
> control the position of the shaft relative to the clock - even though it's
a
> rotating position, it's still a position at an instant in time.
>
> One thing I might suggest is to select that value of Ts that matches the
> speed you're trying to achieve. That's where the control loop is
critical.
> Otherwise, you do have a velocity servo for dealing with the shaft speed
> being much too low or too high. Your controller "switches" from velocity
to
> position when you go from frequency control to phase control. My
suggestion
> here is something like using "describing functions" in analyzing a
nonlinear
> system - where an approximation is plenty good enough. So, this will be
an
> approximation. Given that you'll need gain and phase margins in the end
> anyway, it should be fine.
>
> Then, if you have a range of values of Ts / motor controlled speed to deal
> with, I would analyze the system at the extreme values to see which
> dominates / is worse......
>
> Somehow you need to consider the delays that are introduced in the
> implementation you've described. The interrupt service and associated
> processing time is quite concerning. You may not be able to do what you
> want with this kind of implementation. You'll need to run the numbers to
> see.
>
> With only one sample per revolution, you don't have much data to go on.
How
> can you be sure that you're meeting the sampling criterion? I guess the
> motor could be very slow to respond to any changes but.....
> Let me explain further:
> What if you apply either drive voltage to the motor or a load that will
vary
> sinusoidally (just as one example) or perhaps as a square wave AND the
> frequency of this forcing function is such that the shaft speed will be
> forced to increase during one rotation and decrease during the other
> rotation? Will there be appreciable change in the shaft speed at the
> frequency of this perturbation? If so, the one-sample-per-revolution
> tachometer is insufficient sampling because it doesn't meet the Nyquist
> criterion for sampling. This could be a very big deal. It also suggests
> that the lowest shaft speed you need to control to is the most critical in
> this sense - rather than the largest shaft speed / smallest Ts.
>
> I'm sure it could cause some discussion but let me say this: I think it
> doesn't matter what you *think* the perturbation bandwidth can be. What
> matters is what the motor is capable of responding to. I think that
> determines the bandwidth that you have to be able to sample - since you
> really can't predict what frequencies will be present in motor position.
>
> Hope this helps.
>
> Fred
>
>
>
>
>
>
>

[Fred Marshall]

"Jim Gort" <[email protected]> wrote in message
news:pbvDb.401932$275.1275736@attbi_s53...
> Fred:
>
> I think you are missing the point. Because he can't measure the feedback
at
> a well-defined sample rate (he can only see that it crosses when it
crosses,
> and has no idea about the phase of it at any given time of applying a new
> input), there is no firm application of Ts. That is, the notion of Ts in a
> digital control system implies that, at every Ts, you know the system
> output, and apply a new system input. Your discourse implies that Ts might
> be "unknown", but in fact it is time-varying (or at least on the feedback
> end of things).
>
> There has been much work done for digital controllers with *fixed* phase
> delay, meaning that you apply an input, but the D/A time plus the A/D time
> creates a *fixed* time delay (but variable phase delay, as phase depends
on
> current system frequency). However, I'm not sure about his situation, with
> variable *time* delay, as he doesn't know the plant position when he
applies
> control vector at Ts--he only knows plant position when it happens to
cross
> one of the encoder/zero-crossing positions.
>
> There is hope, though. My thesis advisor at MIT has done some work in
> precisely these type of situations (Kamal Youcef-Toumi), and also there is
a
> wealth of information on the subject from people who provide encoders for
> motors, and tell you how to use the encoders to control the motor (just
> google "control of motors", or something like that).
>
> Jim Gort
>

Jim,

If I understood his question, it was about how to analyze the control
equations for stability, etc. So, a variety of values of Ts might actually
suffice for this purpose. The results wouldn't be exact but might be
adequate. I know it's time varying and I purposefully substituted treating
it as static but with a range of values. That isn't too much different than
using describing functions for nonlinear system components.

It would be scary to think that if the sample rate went up that the system
would go unstable. I think that's right. Thus the lower bound on the
sample rate could be the interesting case.

Presumably if the system delays are small enough then he knows (nearly
enough) the system state at the time of applying the next control vector.
But, that remains a concern - being small enough.

I find the sensor to be strange. An encoded tach with 1024 states is surely
possible - I think that's what we were using in our low-flutter tape drive
controller. A tach with but one "blip" per revolution seems strange to me.
But that's what he says he has.

Fred

[Jay]

Hello Fred, Jim

First, thank you both for your response.

I read your original post Fred, but ran out of time to respond, and I
see there is a new post so I'll try to answer all your questions (and
pose some new ones of my own) in one shot...

In article <[email protected]>, fmarshallx says...
>
> "Jim Gort" wrote in message
> news:pbvDb.401932$275.1275736@attbi_s53...
> > Fred:
> >
> > I think you are missing the point. Because he can't measure the feedback
> at
> > a well-defined sample rate (he can only see that it crosses when it
> crosses,
> > and has no idea about the phase of it at any given time of applying a new
> > input), there is no firm application of Ts. That is, the notion of Ts in a
> > digital control system implies that, at every Ts, you know the system
> > output, and apply a new system input. Your discourse implies that Ts might
> > be "unknown", but in fact it is time-varying (or at least on the feedback
> > end of things).

This is what I was trying to get at in my first post -- Ts is not fixed
but is a function of the motor rotational frequency and it's crossing
with the reference clock.

> >
> > There is hope, though. My thesis advisor at MIT has done some work in
> > precisely these type of situations (Kamal Youcef-Toumi), and also there is
> a
> > wealth of information on the subject from people who provide encoders for
> > motors, and tell you how to use the encoders to control the motor (just
> > google "control of motors", or something like that).

I'll check into the research done by your thesis advisor, thank you for
the name.

I did try to read all available information with respect to motor
control including data sheets from a lot of vendors, but I didn't seem
to find the information I was looking for (or I misunderstood?).

See below on my explanation about the motor outputs and what I found
about motor control ICs.

> If I understood his question, it was about how to analyze the control
> equations for stability, etc. So, a variety of values of Ts might actually
> suffice for this purpose. The results wouldn't be exact but might be
> adequate. I know it's time varying and I purposefully substituted treating
> it as static but with a range of values. That isn't too much different than
> using describing functions for nonlinear system components.

Fred, if I understood your original post and your text above, you are
essentially saying that I should figure out my gains to account for the
range that Ts might take on. Thus, my PID gains are effectively time
varying gains (like an adaptive filter?) and I should pick my "fixed"
gains to so that I'm stable across the range that Ts might take on?

> It would be scary to think that if the sample rate went up that the system
> would go unstable. I think that's right. Thus the lower bound on the
> sample rate could be the interesting case.

I think this would be the case as well, which gets into some details I
wanted some comments on too...

It is my understanding that the motor setup (which in my case has a
fixed load for which I know the moment of inertia for) will effectively
set the bandwidth for my system. The motor is effectively a second-order
system and can be modeled as a typical RLC circuit.

It is also my understanding that the PID compensator I design cannot
increase the final bandwidth of the system(since that is limited by the
"RLC" network) but can and will vary the gain/phase over the frequency
range that the motor responds to.

The Integrator should (when designed properly) provide gain at lower
frequencies and eliminate steady-state error while the Differentiator
term should increase the phase response at higher frequencies and also
provide for some gain at high frequencies. The D term should reduce
overshoot, decrease settling time, etc.

This also means, if my understanding is correct, my digital PID loop
should not apply or provide control changes at a rater faster than the
motor can respond to.

My feeling is if I continue with my existing control-loop approach
(using the tachometer output) I would have to provide some kind of
hysteresis or slew-rate limiting so even if my motor is spinning at say
50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB
frequency is say 10 Hz, I would not issue updates any faster than 10 Hz.

Is my reasoning correct?


> Presumably if the system delays are small enough then he knows (nearly
> enough) the system state at the time of applying the next control vector.
> But, that remains a concern - being small enough.

> I find the sensor to be strange. An encoded tach with 1024 states is surely
> possible - I think that's what we were using in our low-flutter tape drive
> controller. A tach with but one "blip" per revolution seems strange to me.
> But that's what he says he has.

Actually the motor *does* have a quadrature encoder on it (a 2000
count/revolution if I use the quadrature counts) and I have designed my
FPGA logic to properly interface to the these signals. I have software
on the uC that can read the quadrature counts either asynchronously or
synchronously (the FPGA will interrupt the uC when a new count has come
by).

However, I was unable to visualize a complete mechanism that utilized
the quadrature counts of the motor to help get phase-lock with my
reference clock.

In most of the motor controller data sheets/appnotes that I looked at,
the devices are attempting to position some load, say a printer head, at
a particular location. In these applications, the IC will zero a
quadrature counter, then move the motor (following a trapozoidal
velocity pattern), sampling the quadrature counts at a fixed Ts, until
the total quadrature count is = value where the load should be.

For those kinds of "position" control systems, the final position can be
expressed in a total number of quadrature counts from starting location
(I.e. when the quadrature count starting from 0 reads 1 million, the
print head will be in the desired spot).

However, my system is not trying to position a load at a fixed location,
but is instead trying to have the tachometer output be phase-aligned
with a reference clock.

The only scheme I have some up with that can utilize the quadrature
encoder is the following:

1. Accelerate the motor so it is spinning at a frequency close to the
reference clock to speed-up phase clock(aka do an FLL first).

( Right now, the FPGA is setup to allow it to time the reference clock
and the uC can convert the count to a frequency. The uC also knows the
Kv (voltage constant) for the motor so it can backsolve for a voltage
and have the DAC/PWM circuit output a value that gets the motor close to
the desired frequency. )

2. Use the index/tachometer pulse from the motor is used to zero-out a
quadrature counter(in the FPGA) on each revolution and have the
quadrature counter start counting upward.

3. The quadrature count is stopped when a reference clock comes by and
the quadrature counter (error) should be read by the uC and used in the
control-loop as an error.

Since the reference clock *IS* periodic and the error will be available
on each reference clock tick, this means my Ts can be fixed.

Note: My external clock range is between 1 to 50 Hz but is set on the
system start-up, so I don't have to track a varying clock.

Keeping in mind that the reference clock rate (thus "Ts" if I use the
above scheme) could be higher than the bandwidth of my system, I still
think I would need to limit the rate at which I can issue a new output.
That is, I would NOT issue a new output on each error sample but somehow
space them out so I don't cause the motor to go sinusoidal.

Is the above scheme more sane? Is my reasoning sound?

I did find one other PDF that seemed relevant:

http://www.st.com/stonline/books/pdf/docs/1383.pdf

It's an ST part that basically does what I'm trying to do, and also only
uses a tach sense. The relevant pages, 14-18 give an idea of how they
are doing their control but it still does not say what they do to rate
limit the output.

Finally, I guess related to digital controllers, I am wondering, how do
other systems cope with not issuing outputs faster than the system can
respond?

Typically, the sampling rate is, to meet Nyquist, @ 2x the highest
frequency component. That means that an error signal is available at
this rate too. How do other digital-control loops avoid spitting outputs
too fast? Do they not process a new output based on each error they get?

Thanks for all your responses, hopefully with some time I might get
phase lock on solution =)

-- Jay.

[Jerry Avins]

I avoided answering at first because it seems to me to be an attempt to
build a silk purse from a sow's ear. The only indication of motor
position seems to be a once-around signal. In effect, the sample rate is
the rotation rate. Servos should be oversampled by at least a factor of
five -- i.e., five times the Nyquist rate -- to keep the processing
delay low enough for stability. What kind of angular accuracy is wanted
at lock? Either the speed of the motor changes so slowly that the time
of the last revolution is an adequate estimate of the current speed, or
the system can't work. There's not even a way to directly measure the
direction.

To make it work (it's seductively easy to make it almost work), replace
the once-around indicator with a quadrature position encoder that has an
auxiliary once-around track.

And have a look at http://users.erols.com/jyavins/servo.html

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Jim Gort wrote:
> Fred:
>
> I think you are missing the point. Because he can't measure the feedback at
> a well-defined sample rate (he can only see that it crosses when it crosses,
> and has no idea about the phase of it at any given time of applying a new
> input), there is no firm application of Ts. That is, the notion of Ts in a
> digital control system implies that, at every Ts, you know the system
> output, and apply a new system input. Your discourse implies that Ts might
> be "unknown", but in fact it is time-varying (or at least on the feedback
> end of things).
>
> There has been much work done for digital controllers with *fixed* phase
> delay, meaning that you apply an input, but the D/A time plus the A/D time
> creates a *fixed* time delay (but variable phase delay, as phase depends on
> current system frequency). However, I'm not sure about his situation, with
> variable *time* delay, as he doesn't know the plant position when he applies
> control vector at Ts--he only knows plant position when it happens to cross
> one of the encoder/zero-crossing positions.
>
> There is hope, though. My thesis advisor at MIT has done some work in
> precisely these type of situations (Kamal Youcef-Toumi), and also there is a
> wealth of information on the subject from people who provide encoders for
> motors, and tell you how to use the encoders to control the motor (just
> google "control of motors", or something like that).
>
> Jim Gort
>
> "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
> news:[email protected]...
>
>>"Jay" <[email protected]> wrote in message
>>news:[email protected] ...
>>
>>>Hi everyone.
>>>
>>>I am working on a digital PLL design for a motor control application and
>>>I need some help with the control-loop aspects. The end goal is to have
>>>my motor achieve phase lock with a reference signal.
>>>
>>>Some background information:
>>>
>>>My system consists of an FPGA which implements the "digital logic" end
>>>of things such as the Frequency/Phase detector + error counters, PWM
>>>controller, etc. The PFD is setup to drive a counter which keeps track
>>>of the phase difference(in terms of counts) between my motor and a
>>>reference clock. The FPGA is also paired up with a micrcontroller which
>>>I am using to implement a PID loop, provide debug output, etc.
>>>
>>>The DC motor I am using has an output that goes high once per revolution
>>>("tach sense") which feeds one input of the PFD(realized in the FPGA).
>>>The other input to the PFD is an external clock signal, so the PFD
>>>compares a reference clock and the motor tach pulse train and spits out
>>>an error between the two in terms of counts(it also has an output lets
>>>me know if the motor is faster or slower than the reference clock).
>>>
>>>The problem:
>>>
>>>Since I am implementing a digital PID controller (in software on the
>>>uController), usually the sampling rate ("Ts") is factored in the
>>>conversion from a continuous-time to discrete-time control-loop. If it's
>>>important, I am using the Tustin or Bilinear transform to go from C-->D.
>>>
>>>The issue I face is that my error counter can only be read when the only
>>>when the motor has spun around and the reference clock has come by(the
>>>FPGA logic provides a signal that interrupts the uC when a new error is
>>>available and then the uC reads the error counter in the FPGA).
>>>
>>>Given that the motor will probably be speeding up/slowing down as a
>>>result of the control-loop, this means that I probably will not receive
>>>errors at periodic intervals, thus I cannot factor in one Ts into my PID
>>>code for my discrete-time implementation.
>>>
>>>My question:
>>>
>>>Can I just keep track of the time between each error event, convert that
>>>to a Ts and use that as my Ts each time I get a new error ("variable
>>>sampling rate")?
>>>
>>>Are there any draw backs to this technique?
>>>
>>>Are there any alternative methods?
>>>
>>
>>Jay,
>>
>>Yes, I believe there's an alternative method. It hinges on why you need
>
> Ts
>
>>in the first place.
>>
>>First of all though, I've not used PID controllers as such but only the
>>old-fashioned linear control design. I suppose that it's easy enough to
>>translate. A quick look suggests that Ts is simply part of the gain
>>coefficients anyway. So, once you have a controller, KI*Ts and KD/Ts are
>>constants anyway, right?
>>
>>I see that there's KP, KI, KD and Ts in the PID equations. However, the
>>actual coefficients are:
>>KP, KI*Ts, KD/Ts so you could call these A,B and C and never worry further
>>about Ts. Just pick a Ts and pick KI and KD to compensate. In fact, just
>>to be sure, try this:
>>Let's say that KP=3, KI=2, KD=4 and Ts=0.1.
>>Then, A=3, B=0.2 and C=40. If you arbitrarily change to Ts=.2, KI=1 and
>>KD=20, will the system be any different? From what I'm reading, it
>
> appears
>
>>not - although it perturbs the bilinear transformation. Does it matter in
>>practice? That's the question. It might be a good test to see if my
>>conjecture is OK or not OK. Anyway, this is just an argument and I'm not
>>sure that it matters in getting to a design. See below:
>>
>>I have designed motor controls using a tach. One of the issues you will
>>face is whether you're truly building a speed control or a position
>
> control.
>
>>Using a tachometer for feedback with a PLL often becomes a position
>
> control
>
>>and you add an integration term by doing this - since the position is the
>>integral of the velocity. If the PLL tries to lock the motor tachometer
>
> to
>
>>the reference clock, then it's a position servo because you're trying to
>>control the position of the shaft relative to the clock - even though it's
>
> a
>
>>rotating position, it's still a position at an instant in time.
>>
>>One thing I might suggest is to select that value of Ts that matches the
>>speed you're trying to achieve. That's where the control loop is
>
> critical.
>
>>Otherwise, you do have a velocity servo for dealing with the shaft speed
>>being much too low or too high. Your controller "switches" from velocity
>
> to
>
>>position when you go from frequency control to phase control. My
>
> suggestion
>
>>here is something like using "describing functions" in analyzing a
>
> nonlinear
>
>>system - where an approximation is plenty good enough. So, this will be
>
> an
>
>>approximation. Given that you'll need gain and phase margins in the end
>>anyway, it should be fine.
>>
>>Then, if you have a range of values of Ts / motor controlled speed to deal
>>with, I would analyze the system at the extreme values to see which
>>dominates / is worse......
>>
>>Somehow you need to consider the delays that are introduced in the
>>implementation you've described. The interrupt service and associated
>>processing time is quite concerning. You may not be able to do what you
>>want with this kind of implementation. You'll need to run the numbers to
>>see.
>>
>>With only one sample per revolution, you don't have much data to go on.
>
> How
>
>>can you be sure that you're meeting the sampling criterion? I guess the
>>motor could be very slow to respond to any changes but.....
>>Let me explain further:
>>What if you apply either drive voltage to the motor or a load that will
>
> vary
>
>>sinusoidally (just as one example) or perhaps as a square wave AND the
>>frequency of this forcing function is such that the shaft speed will be
>>forced to increase during one rotation and decrease during the other
>>rotation? Will there be appreciable change in the shaft speed at the
>>frequency of this perturbation? If so, the one-sample-per-revolution
>>tachometer is insufficient sampling because it doesn't meet the Nyquist
>>criterion for sampling. This could be a very big deal. It also suggests
>>that the lowest shaft speed you need to control to is the most critical in
>>this sense - rather than the largest shaft speed / smallest Ts.
>>
>>I'm sure it could cause some discussion but let me say this: I think it
>>doesn't matter what you *think* the perturbation bandwidth can be. What
>>matters is what the motor is capable of responding to. I think that
>>determines the bandwidth that you have to be able to sample - since you
>>really can't predict what frequencies will be present in motor position.
>>
>>Hope this helps.
>>
>>Fred

[Jerry Avins]

Jay,

When you think about it, a phase-locked servo is a position servo
following a moving command. I hesitate to call anything impossible, but
it's very hard to make a position servo without position feedback. In
order to adjust the motor's phase, you have to know (or be able to
pretty accurately guess) where it is. All the details that you need to
work out follow from that.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Jerry Avins]

Jay,

When you think about it, a phase-locked servo is a position servo
following a moving command. I hesitate to call anything impossible, but
it's very hard to make a position servo without position feedback. In
order to adjust the motor's phase, you have to know (or be able to
pretty accurately guess) where it is. All the details that you need to
work out follow from that.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Fred Marshall]

"Jerry Avins" <[email protected]> wrote in message
news:[email protected]...
> Jay,
>
> When you think about it, a phase-locked servo is a position servo
> following a moving command. I hesitate to call anything impossible, but
> it's very hard to make a position servo without position feedback. In
> order to adjust the motor's phase, you have to know (or be able to
> pretty accurately guess) where it is. All the details that you need to
> work out follow from that.

Jerry,

Yeah, it depends on your reference if the "command is moving".
If the command isn't in velocity space but, rather, is in phase space then
the command is fixed - say at zero phase. I think that's what this type of
phase-locked servo tries to accomplish - to keep the phase difference at
zero.

The idea isn't so much to "adjust" the motor's phase as to "control" it. By
this I mean, it's not the objective to control the motor shaft position to
be, for example, 90 degrees removed from a particular point of rotation.
There's no command of that sort when the overall objective is to control
velocity. The objective is to control the motor tachometer output to be in
phase with a clock - which translates to an *arbitrary* shaft / tachometer
position. While the words may seem contradictory, we agree that it's a
position servo

Fred

[Jay]

Hi Fred,

Thanks for the detailed response.

In article <[email protected]>, fmarshallx@
>
> ***Yes, that was the idea. But, I think you need to get away from this
> approach anyway.

I agree, the variable Ts / variable gains is an interesting problem but
perhaps for another time? :).

> .................................
> >
> > This also means, if my understanding is correct, my digital PID loop
> > should not apply or provide control changes at a rater faster than the
> > motor can respond to.
>
> ***Oh, I don't see why not if you have the compute power - if what you mean
> is the drive voltage to the motor. Actually, the issue is that it might not
> have an *adequate* rate!

I am slightly confused here(more below). My system has enough
computational resources to issue an update rates probably on the order
of a kHz or so.

I also have enough drive voltage and drive current, so that isn't what I
was getting at.

> > My feeling is if I continue with my existing control-loop approach
> > (using the tachometer output) I would have to provide some kind of
> > hysteresis or slew-rate limiting so even if my motor is spinning at say
> > 50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB
> > frequency is say 10 Hz, I would not issue updates any faster than 10 Hz.
> >
> > Is my reasoning correct?
>
> ***I don't think so. You probably want to generate them even faster than
> that! Our concern was that one indication per revolution might be
> undersampling. Jerry's rule of thumb of a factor of 5 times oversampling is
> a good thing to focus on. That is, 5 times the Nyquist rate or 10 times the
> bandwidth of the data. If the shaft rate is 50Hz then this would mean a
> single sample per revolution would be OK if the motor could not appreciably
> change speed with a superimposed drive voltage at 5Hz - more or less. This
> translates into a motor step response that's much slower than 0.2 seconds.
> That's a little hard to imagine.

> Turning the numbers around:
> If you sample at intervals around 1/50=0.020 seconds then the <bandwidth has
> to be less than 1/(10*0.020) or 5Hz.
> Hysteresis or slew-rate limiting generally make things worse.

What you are saying is that if my motor bandwidth is around 5Hz, 50Hz
would be an acceptable sampling rate for errors.

My point of confusion is if my motor bandwidth is only 5Hz, and I
receive error information at the rate of 50Hz, process the error and
produce a new output at a rate of 50Hz with some slight time delay from
when I get the error does this not mean that I could end up with a limit
cycle since I am driving the motor at a rate faster than it can keep up
with?

An illustration of the condition *I think I want to avoid* is shown on
this page:

http://www.engin.umich.edu/group/ctm/freq/freq.html

search for "higher than the bandwidth frequency".

If I'm missing something or have something flipped in my head, I'll
gladly welcome any corrections!

> .....snip the details.....
> Take advantage of the full tachometer output! The phase lock control chips
> that I'm familiar with do the rough velocity control that you describe - so
> that part sounds OK. You adjust the frequency coming out of the motor tach
> until it's close.

> Then, when it's close, the controller switches to a different mode of
> operation - so you really have two control loops to analyze: the rough
> control and the fine control. I guess as long as the rough control gets you
> into the fine range, it's OK if the rough control has a limit cycle (it may
> oscillate around the desired velocity if left by itself).

Right, my idea is to bring the motor up to the desired speed or very
close to it so phase lock occurs quickly.

> For the fine control, what if you do a typical phase detection between the
> clock and the tach? That would be a more normal thing to do rather than to
> use counters. Surely the FPGA is plenty fast enough to do that. Then you
> phase lock the two in a normal sort of phase-locked loop approach. I should
> think that all of this would be in the FPGA. Something like the single
> ended falling edge detector in:
> http://www.cs.binghamton.edu/~csekhar/AN8017.PDF

Actually this is *exactly* the kind of setup I have now. I have a
Phase/Frequency detector in the FPGA, as I mentioned in my original
post.

Normally the edge-type phase detectors just provide the Up/Down signals
and the duration that the Up/Down signals are on signifies the amount of
error between the reference and clock(until both of them are in the on
state).

My "addition" to the edge type detector was to take the Up/Down signals
and XOR them. The XORed output is used as an Enable to a counter clocked
around 1.5MHz or so.

The result is the counter holds the error between the reference and the
motor tach output in terms of counter ticks which could be converted to
a numerical time or a numerical phase error rather easily. My goal in
using the counter was to have the control-loop chew on the error which
is now numerical instead of being a square-wave of varying duty cycle.

> Of course, in your case, the motor and its drive is the VCO and the
> reference clock is the reference into the PLL, etc. And, I believe, the
> integrator in the PID is the integrator in the VCO, right? I haven't seen a
> block diagram of what you're doing.....

My original approach to this solution was just to treat the motor as a
VCO and use the PFD to produce an error signal(or error count) used by
the control-loop and just to approach the whole problem as a PLL design.

But this sort of brings us back all the way around to my original
variable Ts problem. See the error information from the Edge
Phase/Frequency detector is only valid when the motor spins around once
and the reference clock comes by.

Even if I don't use a counter to numerically keep track of the time
difference between the reference clock and the motor tach, I would still
need some meaningful way to use the Up/Down signals...

> I'm not the expert in how to implement this but here's a wild guess:
> Build the single ended falling edge detector as above. Use the output to
> count up and down. While the phase is too positive, count up. While the
> phase is too negative, count down. The result is an integration of the
> errors which should integrate to zero when it's locked. The count drives a
> DAC that creates the motor control voltage. I imagine the whole thing looks
> something like this. So, whether the counter is in the FPGA or in the uC,
> is up to you but I imagine that the responsiveness will be better if it's in
> the FPGA. Then the PID in the uC *can* be implemented with a fixed Ts
> because you might sample the counter output regularly from the uC - which
> puts the sampling control in a better place. This all assumes that you use
> the full capability of the tachometer and have 1000 or 2000 pulses per
> revolution of the motor shaft. It looks like it means that your reference
> clock will increase in frequency by a factor of 1000. Well, anyway, this is
> really a "cartoon" of what might work.... and there must be some fixed
> output from the DAC somehow - maybe from the rough loop.

What you're suggesting is sort of what I threw together in an hour (just
to demonstrate to myself the PFD and all the logic in the FPGA was
working).

My one hour setup:

First bring the output* to a value so the motor speed is very close to
the reference clock.

Then, each time the PFD circuit produced a new error (which meant one
reference clock came by and the motor had spun one revolution), I had
the uC read the error counter in the FPGA(which also provides
leading/lagging information).

If the motor was leading the reference signal, I decreased the output*
by one binary count. If the motor was behind the reference clock I
advanced the output* by one binary count.

* The output in my case is the output from a 16-bit PWM controller
housed in the FPGA. The PWM output drives an H-bridge whos output goes
to the DC (brushed)motor.

What I found is that the motor tach would hover around the reference
clock but would never stop or lock. In my case I had set the reference
clock to 20 Hz and I noticed +/- 100 deg variation in the motor output
with respect to the reference.

I figured that this approach was too simplistic and I wasn't taking into
account the phase/frequency response of the motor, so I started on the
PID approach.

I don't see how what you are suggesting (+/- the output based on
leading/lagging) could really be extended to using the quadrature
outputs(as I think you are suggesting) unless I do something like what I
suggested in my previous post where I use the quadrature counts as a
positional error(established by the motor 1 pulse-per-revolution and the
reference clock).

I say that because if I use the quadrature output simply as a
"tachometer", I would also have to multiply my reference signal
frequency by a factor of 2000, which I don't have the facilities to do
easily. In my case the reference clock is provided by an external
circuit and I don't have the room for a normal PLL to perform frequency
multiplication.

Technically it is possible for me to build some kind of DDS in the FPGA
but having THAT phase lock to the reference signal, etc, etc seems like
a lot of trouble.

I appreciate your help(and everyone elses) so far, it has been very
valuable. As usual I welcome comments, criticisms and suggestions =).

Thanks!
-- Jay.

[Jay]

Jerry,

In article <[email protected]>, jya says...
> delay low enough for stability. What kind of angular accuracy is wanted
> at lock? Either the speed of the motor changes so slowly that the time
> of the last revolution is an adequate estimate of the current speed, or
> the system can't work. There's not even a way to directly measure the
> direction.

I am aiming for 1 deg accuracy.

I am not sure what you mean by "direction". The Phase/Frequency detector
does let me know if the motor is ahead of or behind the reference clock.

>
> To make it work (it's seductively easy to make it almost work), replace
> the once-around indicator with a quadrature position encoder that has an
> auxiliary once-around track.
>
> And have a look at http://users.erols.com/jyavins/servo.html

I'm trying to digest this...we'll see where I get.

Thanks.

-- Jay

[Fred Marshall]

"Jay" <[email protected]> wrote in message news:k0FDb.38$Si1.13@fe01...

................snip
>
> > If I understood his question, it was about how to analyze the control
> > equations for stability, etc. So, a variety of values of Ts might
actually
> > suffice for this purpose. The results wouldn't be exact but might be
> > adequate. I know it's time varying and I purposefully substituted
treating
> > it as static but with a range of values. That isn't too much different
than
> > using describing functions for nonlinear system components.
>
> Fred, if I understood your original post and your text above, you are
> essentially saying that I should figure out my gains to account for the
> range that Ts might take on. Thus, my PID gains are effectively time
> varying gains (like an adaptive filter?) and I should pick my "fixed"
> gains to so that I'm stable across the range that Ts might take on?

***Yes, that was the idea. But, I think you need to get away from this
approach anyway.

..................................
>
> This also means, if my understanding is correct, my digital PID loop
> should not apply or provide control changes at a rater faster than the
> motor can respond to.

***Oh, I don't see why not if you have the compute power - if what you mean
is the drive voltage to the motor. Actually, the issue is that it might not
have an *adequate* rate!

>
> My feeling is if I continue with my existing control-loop approach
> (using the tachometer output) I would have to provide some kind of
> hysteresis or slew-rate limiting so even if my motor is spinning at say
> 50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB
> frequency is say 10 Hz, I would not issue updates any faster than 10 Hz.
>
> Is my reasoning correct?

***I don't think so. You probably want to generate them even faster than
that! Our concern was that one indication per revolution might be
undersampling. Jerry's rule of thumb of a factor of 5 times oversampling is
a good thing to focus on. That is, 5 times the Nyquist rate or 10 times the
bandwidth of the data. If the shaft rate is 50Hz then this would mean a
single sample per revolution would be OK if the motor could not appreciably
change speed with a superimposed drive voltage at 5Hz - more or less. This
translates into a motor step response that's much slower than 0.2 seconds.
That's a little hard to imagine.
Turning the numbers around:
If you sample at intervals around 1/50=0.020 seconds then the bandwidth has
to be less than 1/(10*0.020) or 5Hz.
Hysteresis or slew-rate limiting generally make things worse.

............

> Actually the motor *does* have a quadrature encoder on it (a 2000
> count/revolution if I use the quadrature counts) and I have designed my
> FPGA logic to properly interface to the these signals. I have software
> on the uC that can read the quadrature counts either asynchronously or
> synchronously (the FPGA will interrupt the uC when a new count has come
> by).
>
> However, I was unable to visualize a complete mechanism that utilized
> the quadrature counts of the motor to help get phase-lock with my
> reference clock.
>
> In most of the motor controller data sheets/appnotes that I looked at,
> the devices are attempting to position some load, say a printer head, at
> a particular location. In these applications, the IC will zero a
> quadrature counter, then move the motor (following a trapozoidal
> velocity pattern), sampling the quadrature counts at a fixed Ts, until
> the total quadrature count is = value where the load should be.
>
> For those kinds of "position" control systems, the final position can be
> expressed in a total number of quadrature counts from starting location
> (I.e. when the quadrature count starting from 0 reads 1 million, the
> print head will be in the desired spot).
>
> However, my system is not trying to position a load at a fixed location,
> but is instead trying to have the tachometer output be phase-aligned
> with a reference clock.
>
> The only scheme I have some up with that can utilize the quadrature
> encoder is the following:
>

......snip the details.....
Oh! Well, then. That's the sort of tach that you need! Now to take
advantage of it:
You have the right idea here until you get into using the counters I think.
Take advantage of the full tachometer output! The phase lock control chips
that I'm familiar with do the rough velocity control that you describe - so
that part sounds OK. You adjust the frequency coming out of the motor tach
until it's close.

Then, when it's close, the controller switches to a different mode of
operation - so you really have two control loops to analyze: the rough
control and the fine control. I guess as long as the rough control gets you
into the fine range, it's OK if the rough control has a limit cycle (it may
oscillate around the desired velocity if left by itself).

For the fine control, what if you do a typical phase detection between the
clock and the tach? That would be a more normal thing to do rather than to
use counters. Surely the FPGA is plenty fast enough to do that. Then you
phase lock the two in a normal sort of phase-locked loop approach. I should
think that all of this would be in the FPGA. Something like the single
ended falling edge detector in:
http://www.cs.binghamton.edu/~csekhar/AN8017.PDF

Of course, in your case, the motor and its drive is the VCO and the
reference clock is the reference into the PLL, etc. And, I believe, the
integrator in the PID is the integrator in the VCO, right? I haven't seen a
block diagram of what you're doing.....

I'm not the expert in how to implement this but here's a wild guess:
Build the single ended falling edge detector as above. Use the output to
count up and down. While the phase is too positive, count up. While the
phase is too negative, count down. The result is an integration of the
errors which should integrate to zero when it's locked. The count drives a
DAC that creates the motor control voltage. I imagine the whole thing looks
something like this. So, whether the counter is in the FPGA or in the uC,
is up to you but I imagine that the responsiveness will be better if it's in
the FPGA. Then the PID in the uC *can* be implemented with a fixed Ts
because you might sample the counter output regularly from the uC - which
puts the sampling control in a better place. This all assumes that you use
the full capability of the tachometer and have 1000 or 2000 pulses per
revolution of the motor shaft. It looks like it means that your reference
clock will increase in frequency by a factor of 1000. Well, anyway, this is
really a "cartoon" of what might work.... and there must be some fixed
output from the DAC somehow - maybe from the rough loop.


+---------+ +---------+ +---------+ +---------+ +---------+
| | | | | | | | | |
ref | |up | | | | | | | |
--->|Phase Det|--->| Counter |>| PID |->| DAC |->| Motor |>---+
| |down| | | | | | | | |
| | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ |
^ |
| |
| |
| +---------+ |
| | | |
| | | |
+-----------------------------------------------| Tach |<---+
| |
| |
+---------+


Fred

[Jim Gort]

Jay:

If bandwidth/nyquist is a problem in your system, how about this
modification to address it:

Use a clock that is N times the frequency of your desired frequency (e.g.,
16 times). If you want to lock into one motor rev/original clock, lock into
1 motor rev/16 clocks. You can then measure the phase error (in encoder
counts) 16 times per cycle (each clock, check the encoder, and compare it to
N/16, where N is the encoder counts/revolution). Or, stated another way,
lock into N/K encoder counts between clock edges, where N is encoder
counts/rev and K is the oversample factor of the clock. You can't go crazy
with K, since an encoder count has inherent uncertainty of true position
(unless you use encoder crossings as the time base of your system, wich you
cannot, since your crystal must be the time base), and as K gets close to N
you loose accuracy in your measurement. However, this may be a nifty way to
achieve higher sample rate for controller, albeit with accuracy of
measurement sacrificed.

Jim

"Jay" <[email protected]> wrote in message news:61NDb.23$cj.11@fe01...
> Hi Fred,
>
> Thanks for the detailed response.
>
> In article <[email protected]>, fmarshallx@
> >
> > ***Yes, that was the idea. But, I think you need to get away from this
> > approach anyway.
>
> I agree, the variable Ts / variable gains is an interesting problem but
> perhaps for another time? :).
>
> > .................................
> > >
> > > This also means, if my understanding is correct, my digital PID loop
> > > should not apply or provide control changes at a rater faster than the
> > > motor can respond to.
> >
> > ***Oh, I don't see why not if you have the compute power - if what you
mean
> > is the drive voltage to the motor. Actually, the issue is that it might
not
> > have an *adequate* rate!
>
> I am slightly confused here(more below). My system has enough
> computational resources to issue an update rates probably on the order
> of a kHz or so.
>
> I also have enough drive voltage and drive current, so that isn't what I
> was getting at.
>
> > > My feeling is if I continue with my existing control-loop approach
> > > (using the tachometer output) I would have to provide some kind of
> > > hysteresis or slew-rate limiting so even if my motor is spinning at
say
> > > 50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB
> > > frequency is say 10 Hz, I would not issue updates any faster than 10
Hz.
> > >
> > > Is my reasoning correct?
> >
> > ***I don't think so. You probably want to generate them even faster
than
> > that! Our concern was that one indication per revolution might be
> > undersampling. Jerry's rule of thumb of a factor of 5 times
oversampling is
> > a good thing to focus on. That is, 5 times the Nyquist rate or 10 times
the
> > bandwidth of the data. If the shaft rate is 50Hz then this would mean
a
> > single sample per revolution would be OK if the motor could not
appreciably
> > change speed with a superimposed drive voltage at 5Hz - more or less.
This
> > translates into a motor step response that's much slower than 0.2
seconds.
> > That's a little hard to imagine.
>
> > Turning the numbers around:
> > If you sample at intervals around 1/50=0.020 seconds then the <bandwidth
has
> > to be less than 1/(10*0.020) or 5Hz.
> > Hysteresis or slew-rate limiting generally make things worse.
>
> What you are saying is that if my motor bandwidth is around 5Hz, 50Hz
> would be an acceptable sampling rate for errors.
>
> My point of confusion is if my motor bandwidth is only 5Hz, and I
> receive error information at the rate of 50Hz, process the error and
> produce a new output at a rate of 50Hz with some slight time delay from
> when I get the error does this not mean that I could end up with a limit
> cycle since I am driving the motor at a rate faster than it can keep up
> with?
>
> An illustration of the condition *I think I want to avoid* is shown on
> this page:
>
> http://www.engin.umich.edu/group/ctm/freq/freq.html
>
> search for "higher than the bandwidth frequency".
>
> If I'm missing something or have something flipped in my head, I'll
> gladly welcome any corrections!
>
> > .....snip the details.....
> > Take advantage of the full tachometer output! The phase lock control
chips
> > that I'm familiar with do the rough velocity control that you describe -
so
> > that part sounds OK. You adjust the frequency coming out of the motor
tach
> > until it's close.
>
> > Then, when it's close, the controller switches to a different mode of
> > operation - so you really have two control loops to analyze: the rough
> > control and the fine control. I guess as long as the rough control gets
you
> > into the fine range, it's OK if the rough control has a limit cycle (it
may
> > oscillate around the desired velocity if left by itself).
>
> Right, my idea is to bring the motor up to the desired speed or very
> close to it so phase lock occurs quickly.
>
> > For the fine control, what if you do a typical phase detection between
the
> > clock and the tach? That would be a more normal thing to do rather than
to
> > use counters. Surely the FPGA is plenty fast enough to do that. Then
you
> > phase lock the two in a normal sort of phase-locked loop approach. I
should
> > think that all of this would be in the FPGA. Something like the single
> > ended falling edge detector in:
> > http://www.cs.binghamton.edu/~csekhar/AN8017.PDF
>
> Actually this is *exactly* the kind of setup I have now. I have a
> Phase/Frequency detector in the FPGA, as I mentioned in my original
> post.
>
> Normally the edge-type phase detectors just provide the Up/Down signals
> and the duration that the Up/Down signals are on signifies the amount of
> error between the reference and clock(until both of them are in the on
> state).
>
> My "addition" to the edge type detector was to take the Up/Down signals
> and XOR them. The XORed output is used as an Enable to a counter clocked
> around 1.5MHz or so.
>
> The result is the counter holds the error between the reference and the
> motor tach output in terms of counter ticks which could be converted to
> a numerical time or a numerical phase error rather easily. My goal in
> using the counter was to have the control-loop chew on the error which
> is now numerical instead of being a square-wave of varying duty cycle.
>
> > Of course, in your case, the motor and its drive is the VCO and the
> > reference clock is the reference into the PLL, etc. And, I believe, the
> > integrator in the PID is the integrator in the VCO, right? I haven't
seen a
> > block diagram of what you're doing.....
>
> My original approach to this solution was just to treat the motor as a
> VCO and use the PFD to produce an error signal(or error count) used by
> the control-loop and just to approach the whole problem as a PLL design.
>
> But this sort of brings us back all the way around to my original
> variable Ts problem. See the error information from the Edge
> Phase/Frequency detector is only valid when the motor spins around once
> and the reference clock comes by.
>
> Even if I don't use a counter to numerically keep track of the time
> difference between the reference clock and the motor tach, I would still
> need some meaningful way to use the Up/Down signals...
>
> > I'm not the expert in how to implement this but here's a wild guess:
> > Build the single ended falling edge detector as above. Use the output
to
> > count up and down. While the phase is too positive, count up. While
the
> > phase is too negative, count down. The result is an integration of the
> > errors which should integrate to zero when it's locked. The count
drives a
> > DAC that creates the motor control voltage. I imagine the whole thing
looks
> > something like this. So, whether the counter is in the FPGA or in the
uC,
> > is up to you but I imagine that the responsiveness will be better if
it's in
> > the FPGA. Then the PID in the uC *can* be implemented with a fixed Ts
> > because you might sample the counter output regularly from the uC -
which
> > puts the sampling control in a better place. This all assumes that you
use
> > the full capability of the tachometer and have 1000 or 2000 pulses per
> > revolution of the motor shaft. It looks like it means that your
reference
> > clock will increase in frequency by a factor of 1000. Well, anyway,
this is
> > really a "cartoon" of what might work.... and there must be some fixed
> > output from the DAC somehow - maybe from the rough loop.
>
> What you're suggesting is sort of what I threw together in an hour (just
> to demonstrate to myself the PFD and all the logic in the FPGA was
> working).
>
> My one hour setup:
>
> First bring the output* to a value so the motor speed is very close to
> the reference clock.
>
> Then, each time the PFD circuit produced a new error (which meant one
> reference clock came by and the motor had spun one revolution), I had
> the uC read the error counter in the FPGA(which also provides
> leading/lagging information).
>
> If the motor was leading the reference signal, I decreased the output*
> by one binary count. If the motor was behind the reference clock I
> advanced the output* by one binary count.
>
> * The output in my case is the output from a 16-bit PWM controller
> housed in the FPGA. The PWM output drives an H-bridge whos output goes
> to the DC (brushed)motor.
>
> What I found is that the motor tach would hover around the reference
> clock but would never stop or lock. In my case I had set the reference
> clock to 20 Hz and I noticed +/- 100 deg variation in the motor output
> with respect to the reference.
>
> I figured that this approach was too simplistic and I wasn't taking into
> account the phase/frequency response of the motor, so I started on the
> PID approach.
>
> I don't see how what you are suggesting (+/- the output based on
> leading/lagging) could really be extended to using the quadrature
> outputs(as I think you are suggesting) unless I do something like what I
> suggested in my previous post where I use the quadrature counts as a
> positional error(established by the motor 1 pulse-per-revolution and the
> reference clock).
>
> I say that because if I use the quadrature output simply as a
> "tachometer", I would also have to multiply my reference signal
> frequency by a factor of 2000, which I don't have the facilities to do
> easily. In my case the reference clock is provided by an external
> circuit and I don't have the room for a normal PLL to perform frequency
> multiplication.
>
> Technically it is possible for me to build some kind of DDS in the FPGA
> but having THAT phase lock to the reference signal, etc, etc seems like
> a lot of trouble.
>
> I appreciate your help(and everyone elses) so far, it has been very
> valuable. As usual I welcome comments, criticisms and suggestions =).
>
> Thanks!
> -- Jay.
>

[Jim Gort]

Jay:

One other thing. I think you are confused regarding the bandwidth of the
controller verse the sample rate of the controller. The update rate of the
controller should be on the order of 5 times the highest mode of the system,
not because it needs to create control vectors with at that high of
frequency, but so that the phase delay between the plant error and the
controller action is minimized.

There is absolutely no problem with a controller running at 1Mhz controlling
a 1hz system. In practice, it will not create control signals greater than
1Hz, but they will be applied with almost zero phase delay.

Jim

"Jay" <[email protected]> wrote in message news:61NDb.23$cj.11@fe01...
> Hi Fred,
>
> Thanks for the detailed response.
>
> In article <[email protected]>, fmarshallx@
> >
> > ***Yes, that was the idea. But, I think you need to get away from this
> > approach anyway.
>
> I agree, the variable Ts / variable gains is an interesting problem but
> perhaps for another time? :).
>
> > .................................
> > >
> > > This also means, if my understanding is correct, my digital PID loop
> > > should not apply or provide control changes at a rater faster than the
> > > motor can respond to.
> >
> > ***Oh, I don't see why not if you have the compute power - if what you
mean
> > is the drive voltage to the motor. Actually, the issue is that it might
not
> > have an *adequate* rate!
>
> I am slightly confused here(more below). My system has enough
> computational resources to issue an update rates probably on the order
> of a kHz or so.
>
> I also have enough drive voltage and drive current, so that isn't what I
> was getting at.
>
> > > My feeling is if I continue with my existing control-loop approach
> > > (using the tachometer output) I would have to provide some kind of
> > > hysteresis or slew-rate limiting so even if my motor is spinning at
say
> > > 50Hz (meaning I get new errors at a rate ~50 Hz), and I know my 0 dB
> > > frequency is say 10 Hz, I would not issue updates any faster than 10
Hz.
> > >
> > > Is my reasoning correct?
> >
> > ***I don't think so. You probably want to generate them even faster
than
> > that! Our concern was that one indication per revolution might be
> > undersampling. Jerry's rule of thumb of a factor of 5 times
oversampling is
> > a good thing to focus on. That is, 5 times the Nyquist rate or 10 times
the
> > bandwidth of the data. If the shaft rate is 50Hz then this would mean
a
> > single sample per revolution would be OK if the motor could not
appreciably
> > change speed with a superimposed drive voltage at 5Hz - more or less.
This
> > translates into a motor step response that's much slower than 0.2
seconds.
> > That's a little hard to imagine.
>
> > Turning the numbers around:
> > If you sample at intervals around 1/50=0.020 seconds then the <bandwidth
has
> > to be less than 1/(10*0.020) or 5Hz.
> > Hysteresis or slew-rate limiting generally make things worse.
>
> What you are saying is that if my motor bandwidth is around 5Hz, 50Hz
> would be an acceptable sampling rate for errors.
>
> My point of confusion is if my motor bandwidth is only 5Hz, and I
> receive error information at the rate of 50Hz, process the error and
> produce a new output at a rate of 50Hz with some slight time delay from
> when I get the error does this not mean that I could end up with a limit
> cycle since I am driving the motor at a rate faster than it can keep up
> with?
>
> An illustration of the condition *I think I want to avoid* is shown on
> this page:
>
> http://www.engin.umich.edu/group/ctm/freq/freq.html
>
> search for "higher than the bandwidth frequency".
>
> If I'm missing something or have something flipped in my head, I'll
> gladly welcome any corrections!
>
> > .....snip the details.....
> > Take advantage of the full tachometer output! The phase lock control
chips
> > that I'm familiar with do the rough velocity control that you describe -
so
> > that part sounds OK. You adjust the frequency coming out of the motor
tach
> > until it's close.
>
> > Then, when it's close, the controller switches to a different mode of
> > operation - so you really have two control loops to analyze: the rough
> > control and the fine control. I guess as long as the rough control gets
you
> > into the fine range, it's OK if the rough control has a limit cycle (it
may
> > oscillate around the desired velocity if left by itself).
>
> Right, my idea is to bring the motor up to the desired speed or very
> close to it so phase lock occurs quickly.
>
> > For the fine control, what if you do a typical phase detection between
the
> > clock and the tach? That would be a more normal thing to do rather than
to
> > use counters. Surely the FPGA is plenty fast enough to do that. Then
you
> > phase lock the two in a normal sort of phase-locked loop approach. I
should
> > think that all of this would be in the FPGA. Something like the single
> > ended falling edge detector in:
> > http://www.cs.binghamton.edu/~csekhar/AN8017.PDF
>
> Actually this is *exactly* the kind of setup I have now. I have a
> Phase/Frequency detector in the FPGA, as I mentioned in my original
> post.
>
> Normally the edge-type phase detectors just provide the Up/Down signals
> and the duration that the Up/Down signals are on signifies the amount of
> error between the reference and clock(until both of them are in the on
> state).
>
> My "addition" to the edge type detector was to take the Up/Down signals
> and XOR them. The XORed output is used as an Enable to a counter clocked
> around 1.5MHz or so.
>
> The result is the counter holds the error between the reference and the
> motor tach output in terms of counter ticks which could be converted to
> a numerical time or a numerical phase error rather easily. My goal in
> using the counter was to have the control-loop chew on the error which
> is now numerical instead of being a square-wave of varying duty cycle.
>
> > Of course, in your case, the motor and its drive is the VCO and the
> > reference clock is the reference into the PLL, etc. And, I believe, the
> > integrator in the PID is the integrator in the VCO, right? I haven't
seen a
> > block diagram of what you're doing.....
>
> My original approach to this solution was just to treat the motor as a
> VCO and use the PFD to produce an error signal(or error count) used by
> the control-loop and just to approach the whole problem as a PLL design.
>
> But this sort of brings us back all the way around to my original
> variable Ts problem. See the error information from the Edge
> Phase/Frequency detector is only valid when the motor spins around once
> and the reference clock comes by.
>
> Even if I don't use a counter to numerically keep track of the time
> difference between the reference clock and the motor tach, I would still
> need some meaningful way to use the Up/Down signals...
>
> > I'm not the expert in how to implement this but here's a wild guess:
> > Build the single ended falling edge detector as above. Use the output
to
> > count up and down. While the phase is too positive, count up. While
the
> > phase is too negative, count down. The result is an integration of the
> > errors which should integrate to zero when it's locked. The count
drives a
> > DAC that creates the motor control voltage. I imagine the whole thing
looks
> > something like this. So, whether the counter is in the FPGA or in the
uC,
> > is up to you but I imagine that the responsiveness will be better if
it's in
> > the FPGA. Then the PID in the uC *can* be implemented with a fixed Ts
> > because you might sample the counter output regularly from the uC -
which
> > puts the sampling control in a better place. This all assumes that you
use
> > the full capability of the tachometer and have 1000 or 2000 pulses per
> > revolution of the motor shaft. It looks like it means that your
reference
> > clock will increase in frequency by a factor of 1000. Well, anyway,
this is
> > really a "cartoon" of what might work.... and there must be some fixed
> > output from the DAC somehow - maybe from the rough loop.
>
> What you're suggesting is sort of what I threw together in an hour (just
> to demonstrate to myself the PFD and all the logic in the FPGA was
> working).
>
> My one hour setup:
>
> First bring the output* to a value so the motor speed is very close to
> the reference clock.
>
> Then, each time the PFD circuit produced a new error (which meant one
> reference clock came by and the motor had spun one revolution), I had
> the uC read the error counter in the FPGA(which also provides
> leading/lagging information).
>
> If the motor was leading the reference signal, I decreased the output*
> by one binary count. If the motor was behind the reference clock I
> advanced the output* by one binary count.
>
> * The output in my case is the output from a 16-bit PWM controller
> housed in the FPGA. The PWM output drives an H-bridge whos output goes
> to the DC (brushed)motor.
>
> What I found is that the motor tach would hover around the reference
> clock but would never stop or lock. In my case I had set the reference
> clock to 20 Hz and I noticed +/- 100 deg variation in the motor output
> with respect to the reference.
>
> I figured that this approach was too simplistic and I wasn't taking into
> account the phase/frequency response of the motor, so I started on the
> PID approach.
>
> I don't see how what you are suggesting (+/- the output based on
> leading/lagging) could really be extended to using the quadrature
> outputs(as I think you are suggesting) unless I do something like what I
> suggested in my previous post where I use the quadrature counts as a
> positional error(established by the motor 1 pulse-per-revolution and the
> reference clock).
>
> I say that because if I use the quadrature output simply as a
> "tachometer", I would also have to multiply my reference signal
> frequency by a factor of 2000, which I don't have the facilities to do
> easily. In my case the reference clock is provided by an external
> circuit and I don't have the room for a normal PLL to perform frequency
> multiplication.
>
> Technically it is possible for me to build some kind of DDS in the FPGA
> but having THAT phase lock to the reference signal, etc, etc seems like
> a lot of trouble.
>
> I appreciate your help(and everyone elses) so far, it has been very
> valuable. As usual I welcome comments, criticisms and suggestions =).
>
> Thanks!
> -- Jay.
>

[Jerry Avins]

Jay wrote:
> Jerry,
>
> In article <[email protected]>, jya says...
>
>>delay low enough for stability. What kind of angular accuracy is wanted
>>at lock? Either the speed of the motor changes so slowly that the time
>>of the last revolution is an adequate estimate of the current speed, or
>>the system can't work. There's not even a way to directly measure the
>>direction.
>
>
> I am aiming for 1 deg accuracy.
>
> I am not sure what you mean by "direction". The Phase/Frequency detector
> does let me know if the motor is ahead of or behind the reference clock.

If your motor were wired to run backward, could you tell?
>
>
>>To make it work (it's seductively easy to make it almost work), replace
>>the once-around indicator with a quadrature position encoder that has an
>>auxiliary once-around track.
>>
>>And have a look at http://users.erols.com/jyavins/servo.html
>
>
> I'm trying to digest this...we'll see where I get.
>
> Thanks.
>
> -- Jay

If you use the encoder to keep track of the motor's position, you can
compute the phase error to within the resolution of the encoder. When
you use only the once-around index, that resolution is one turn. With a
512 position encoder -- you can measure that finely with 128 lines --
the resolution is better than a degree. You need to build a position
servo (at least as far as stability is concerned) and then let your
little greyhound chase a mechanical rabbit around the track. If the
servo works and you put the rabbit (command signal) where you want it,
the servo will follow it there.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Fred Marshall]

"Jay" <[email protected]> wrote in message news:61NDb.23$cj.11@fe01...
> Hi Fred,
>
> Thanks for the detailed response.

OK - responses are interspersed below with "***"


>
> I am slightly confused here(more below). My system has enough
> computational resources to issue an update rates probably on the order
> of a kHz or so.
>

***As Jim Gort also pointed out, this is good!

> What you are saying is that if my motor bandwidth is around 5Hz, 50Hz
> would be an acceptable sampling rate for errors.
>
> My point of confusion is if my motor bandwidth is only 5Hz, and I
> receive error information at the rate of 50Hz, process the error and
> produce a new output at a rate of 50Hz with some slight time delay from
> when I get the error does this not mean that I could end up with a limit
> cycle since I am driving the motor at a rate faster than it can keep up
> with?

***The normal things to cause limit cycles would be nonlinearity and some
delay. Like a bang-bang controller. So, high frequency updates won't cause
a problem.
NOW: if you're running the counter at 50Hz but don't update the feedback
data at the same rate - let's say the update rate is 5Hz - then you'd be
building in a nonlinearity and then you might have this problem. But, it's
not inherent in the update rate itself.

>
> An illustration of the condition *I think I want to avoid* is shown on
> this page:
>
> http://www.engin.umich.edu/group/ctm/freq/freq.html
>
> search for "higher than the bandwidth frequency".

***Well, that's right. They're talking about the frequency response of the
loop. My assumption has to be that you do understand the contents of this
paper and will be setting loop gains accordingly - which includes the phase
detector/counter/DAC transfer gain and the PID coefficients.
- If we assume that the tach and phase detector are using 1000 lines per
revolution - then that's plenty fast with no appreciable latency.
- If we assume that the counter updates directly with the phase detector
output - then that's plenty fast with no appreciable latency.
- If the counter least-significant-bit (LSB) represents too much control
voltage to the motor - then that's a nonlinearity that can cause limit
cycling but, if the update rate is 1000 times per revolution then the
counter output may limit cycle but the motor wouldn't respond to it - so
that would possibly be OK. Then the LSB would have a duty cycle that would
control the motor average speed. (In fact, with high rate updates you might
do this and get rid of the DAC. Just use the motor as a filter on a high
frequency rectangular wave input).
Given that all of these "ifs" are true, then a high update rate is just fine
and is the least of your worries.
NOTE: The phase detector/counter/DAC has gain measured in volts per degree.
This is part of the control loop gain. This can be broken down into phase
detector/counter gain in LSB/degree and DAC volts/LSB. Again, this assumes
that the counter is at a high enough frequency so that the slew rate limit
of the clock isn't important - it "looks like" it's capable of counting
instantaneously.

> > .....snip the details.....
> > Take advantage of the full tachometer output!

> .........I would also have to multiply my reference signal
> frequency by a factor of 2000, which I don't have the facilities to do
> easily. In my case the reference clock is provided by an external
> circuit and I don't have the room for a normal PLL to perform frequency
> multiplication.

***Oh! Well, then you may well have an untenable situation! We keep
telling you this and it's probably hard to accept if this is really your
situation.

................................

> My "addition" to the edge type detector was to take the Up/Down signals
> and XOR them. The XORed output is used as an Enable to a counter clocked
> around 1.5MHz or so.

***If you XOR them then it's not clear how you keep the up/down information.

................................

> The result is the counter holds the error between the reference and the
> motor tach output in terms of counter ticks which could be converted to
> a numerical time or a numerical phase error rather easily. My goal in
> using the counter was to have the control-loop chew on the error which
> is now numerical instead of being a square-wave of varying duty cycle.

***Well, somehow you need to convert phase difference to a number that
controls to the motor average speed. Duty cycle is a form of a number and
the output of a counter is another. Either should work in principle. But,
you are right, if you need to have the control equations, then you need the
number.

........................
> But this sort of brings us back all the way around to my original
> variable Ts problem. See the error information from the Edge
> Phase/Frequency detector is only valid when the motor spins around once
> and the reference clock comes by.

***This is because you've implemented or have access to a defined reference
clock - it appears - somewhat independent of the motor / tachometer
characteristics. Let's put it another way: How in the world do you justify
such a low frequency clock? Just because it's there? Perhaps that's not a
good enough reason.

***Actually you could do a little analysis on this type of system. If you
want to phase lock a motor to a clock where the clock is equal in frequency
to the desired motor shaft rate, then you have defined the sample rate.
- Let's call the clock interval Ts and let's call it 50Hz.
- According to our rule of thumb 1/Ts is 10x the system bandwidth so the
system bandwidth cannot be greater than 5Hz.
- Let's assume the motor has a bandwidth of 18Hz. If that's the case, then
this arrangement probably won't work. If there's some way to sensibly fix
it, I don't know what it is without working harder on your situation. Well,
you might filter somewhere in the feedback loop I guess (without analyzing
it) but higher frequency motor load variations wouldn't be dealt with by
this controller. Similarly, power supply variations in this frequency range
in the motor drive would not be compensated. It would be like saying that
you just don't care about high frequency variations in the motor speed.


> If the motor was leading the reference signal, I decreased the output*
> by one binary count. If the motor was behind the reference clock I
> advanced the output* by one binary count.

***How do you know that this is enough gain or too much gain in this part of
the system? Why not 2 counts or 4 counts or 1/4 count? Since you're
getting a limit cycle, maybe it's too much and looking nonlinear /
bang-bang.

>
> * The output in my case is the output from a 16-bit PWM controller
> housed in the FPGA. The PWM output drives an H-bridge whos output goes
> to the DC (brushed)motor.

***OK - that's the sort of thing I described earlier. I presume you're not
allowing the voltage across the motor to reverse in this implementation (in
that you have the capability in the H bridge).

>
> What I found is that the motor tach would hover around the reference
> clock but would never stop or lock. In my case I had set the reference
> clock to 20 Hz and I noticed +/- 100 deg variation in the motor output
> with respect to the reference.

***OK, so the frequency / speed control does work. That's good.
100 degree variation sounds like a lot! Of course, if it's in a limit cycle
due to 1 LSB, then it could be understandable.
100 degree variation says that the motor is changing shaft position by
nearly 1/3 a revolution per revolution. So, that's indeed a lot.
Here's what could be happening in words:

- Sense the phase is lagging by 100 degrees.
- Increase the count by 1 LSB. Increase the PWM. Increase the motor speed
in a jump to meet the PWM value.
- (How much did the motor shaft move (phase) in the next revolution?)
- Sense the phase is leading by 100 degrees.
- Decrease the count by 1 LSB. Decrease the PWM. Decrease the motor speed
in a jump to meet the PWM value.
- (How much will the motor shaft move (Phase) in the next revolution?)
This implies that the motor control gain is 200 degrees per revolution per
LSB. 200 degrees per revolution is a huge change in velocity.

>
> Technically it is possible for me to build some kind of DDS in the FPGA
> but having THAT phase lock to the reference signal, etc, etc seems like
> a lot of trouble.

***May well be worth it. Also ponder that paper on feedback control.

Fred

[Jay]

Hello again Fred, & Jim,

In article <[email protected]>, fmarshallx@

> ***The normal things to cause limit cycles would be nonlinearity and some
> delay. Like a bang-bang controller. So, high frequency updates won't cause
> a problem.
> NOW: if you're running the counter at 50Hz but don't update the feedback
> data at the same rate - let's say the update rate is 5Hz - then you'd be
> building in a nonlinearity and then you might have this problem. But, it's
> not inherent in the update rate itself.

I think what you're saying is that my motor will inherently low-pass
filter the data(with fc defined by the motor parameters) and if I feed
it a high frequency signal, the motor will just "low-pass" filter it and
not really make any changes...?

> control the motor average speed. (In fact, with high rate updates you might
> do this and get rid of the DAC. Just use the motor as a filter on a high
> frequency rectangular wave input).

Technically that's what's happening now. The PWM signal from the FPGA's
PWM controller is a square-wave of frequency around 800Hz or so. That
signal directly modulates the H-bridge and the bridge output drives the
motor. I have added small filtering capacitors to the output of the
bridge to help attenuate high-frequency noise so the motor *should* only
see the DC of the square wave.

I guess this means I have a delta-sigma DAC if I were to use today's
marketing!

> > My "addition" to the edge type detector was to take the Up/Down signals
> > and XOR them. The XORed output is used as an Enable to a counter clocked
> > around 1.5MHz or so.

> ***If you XOR them then it's not clear how you keep the up/down information.

I've designed the FPGA logic so on the rising edge of the XOR output, I
register the "Down" signal from the output of the phase detector.

If the output from the flip-flop is "1" then I know the Down signal is
what started the counter. If the flip-flop output is "0" I know that Up
is what started the counter.

> ***This is because you've implemented or have access to a defined reference
> clock - it appears - somewhat independent of the motor / tachometer
> characteristics. Let's put it another way: How in the world do you justify
> such a low frequency clock? Just because it's there? Perhaps that's not a
> good enough reason.

I guess I probably wasn't very clear on this when I started this thread.
The "point" of this system *is* to phase lock onto the slow reference
signal. That reference signal happens to lies in the frequency range of
1 - 50 Hz and this is not something I can control.

I'm not using the reference signal to be arbitrary, it's sort of the
point of this design and also why I'm treating the system as a PLL
(getting my motor/VCO to lock onto an external reference).

Note: The reference frequency is not time varying and is valid and
stable before the FPGA/uC power up.

> ***Actually you could do a little analysis on this type of system. If you
> want to phase lock a motor to a clock where the clock is equal in frequency
> to the desired motor shaft rate, then you have defined the sample rate.
> - Let's call the clock interval Ts and let's call it 50Hz.
> - According to our rule of thumb 1/Ts is 10x the system bandwidth so the
> system bandwidth cannot be greater than 5Hz.

> - Let's assume the motor has a bandwidth of 18Hz. If that's the case, then
> this arrangement probably won't work. If there's some way to sensibly fix
> it, I don't know what it is without working harder on your situation. Well,
> you might filter somewhere in the feedback loop I guess (without analyzing
> it) but higher frequency motor load variations wouldn't be dealt with by
> this controller. Similarly, power supply variations in this frequency range
> in the motor drive would not be compensated. It would be like saying that
> you just don't care about high frequency variations in the motor speed.

Are you saying that I would be in trouble with 50Hz sampling and 18Hz
motor bandwidth because the 10x rule means that my motor bandwidth
should be < 5Hz but if it were 18 Hz the high frequency components WOULD
affect it?

> > If the motor was leading the reference signal, I decreased the output*
> > by one binary count. If the motor was behind the reference clock I
> > advanced the output* by one binary count.

> ***How do you know that this is enough gain or too much gain in this part of
> the system? Why not 2 counts or 4 counts or 1/4 count? Since you're
> getting a limit cycle, maybe it's too much and looking nonlinear /
> bang-bang.

Actually I suspect it's way too small gain. I just set it up that way as
a rudamentary test of the FPGA hardware and not really as a final
control-loop.

Just to be clear, by count, I mean I incremented my PWM register value
by decimal 1; being 16-bit PWM, the register holds values in the range
of 0 to 65535.

Also, I don't see how I could get a "fractional count" unless I dithered
the duty cycle value -- have it jump between two or more values very
quickly so the "averaged" output makes it look like I have more
resolution that I actually do. I guess I could dither if need be, but
lack of resolution isn't my problem.

> > * The output in my case is the output from a 16-bit PWM controller
> > housed in the FPGA. The PWM output drives an H-bridge whos output goes
> > to the DC (brushed)motor.

> ***OK - that's the sort of thing I described earlier. I presume you're not
> allowing the voltage across the motor to reverse in this implementation (in
> that you have the capability in the H bridge).

Correct. Actually, the H-bridge is wired for unipolar operation (one
half of the H is hard wired off) and the PWM signal varies from to 0 to
100% with 0% meaning the motor is off and 100% meaning the motor is at
full-speed.

(I simply mention this because I know there are some PWM schemes which
use the center of the pulse to define 0).

I think Jerry also asked how would I know if the motor is spinning
forward(and I forgot to respond) the answer is because it's hard wired
that way! :)


> > What I found is that the motor tach would hover around the reference
> > clock but would never stop or lock. In my case I had set the reference
> > clock to 20 Hz and I noticed +/- 100 deg variation in the motor output
> > with respect to the reference.

> ***OK, so the frequency / speed control does work. That's good.
> 100 degree variation sounds like a lot! Of course, if it's in a limit cycle
> due to 1 LSB, then it could be understandable.
> 100 degree variation says that the motor is changing shaft position by
> nearly 1/3 a revolution per revolution. So, that's indeed a lot.
> Here's what could be happening in words:

I was probably unclear on what I meant. The +/- 100 deg variation occurs
over a LARGE number of error cycles, not in one count or one update.
That is, over a period of say a minute, the tach sense drifts from the
reference edge by +/- 100 deg.

The numbers(1 minute, 100 deg) aren't exact because it was a very slowly
varying process (given my gain was the smallest I could set it to) --
I'm trying to re-set it up to take some better measurements.

But just to be clear, if I make a change in the duty cycle by one count,
I see a VERY small change in the output on the order of fractions of a
Hz(which matches well with the paper based check knowing the Kv of the
motor and applied duty cycle).

> - (How much will the motor shaft move (Phase) in the next revolution?)
> This implies that the motor control gain is 200 degrees per revolution per
> LSB. 200 degrees per revolution is a huge change in velocity.

Re-iterating, the phase error does not change from -100 deg to +100
after a change in the duty cycle by one decimal count. The phase
variation or drift occurs over a large number of errors/updates.

To put some numbers to the currently faceless setup, the motor I am
using is a DC brushed type with a voltage rating of 12V. Currently I the
H-bridge driving the motor has 5V fed to it, so the motor voltage range
lies between 0 to 5V.

That also means that a change in the duty cycle by one count would vary
the motor RPM by a very small amount. Having 16-bit PWM may seem like
overkill, but I wanted to allow for better phase accuracy if my loop
would allow it.

I'll continue to sort out my understanding of the bandwidth, update
rate, etc.

Thanks again Jim and Fred for your responses, I'm really glad you guys
have taken the time to respond. I just hope by time I get it all sorted
out you don't leave in annoyance!

Best regards,
-- Jay.

[Fred Marshall]

"Jay" <[email protected]> wrote in message news:mhmEb.11$_S3.8@fe10...
> Hello again Fred, & Jim,
>
> In article <[email protected]>, fmarshallx@
>
> > ***The normal things to cause limit cycles would be nonlinearity and
some
> > delay. Like a bang-bang controller. So, high frequency updates won't
cause
> > a problem.
> > NOW: if you're running the counter at 50Hz but don't update the feedback
> > data at the same rate - let's say the update rate is 5Hz - then you'd be
> > building in a nonlinearity and then you might have this problem. But,
it's
> > not inherent in the update rate itself.
>
> I think what you're saying is that my motor will inherently low-pass
> filter the data(with fc defined by the motor parameters) and if I feed
> it a high frequency signal, the motor will just "low-pass" filter it and
> not really make any changes...?

***Right. If the frequency is high enough, it won't be reflected in the
shaft speed.
>
> > control the motor average speed. (In fact, with high rate updates you
might
> > do this and get rid of the DAC. Just use the motor as a filter on a
high
> > frequency rectangular wave input).
>
> Technically that's what's happening now. The PWM signal from the FPGA's
> PWM controller is a square-wave of frequency around 800Hz or so. That
> signal directly modulates the H-bridge and the bridge output drives the
> motor. I have added small filtering capacitors to the output of the
> bridge to help attenuate high-frequency noise so the motor *should* only
> see the DC of the square wave.

***I think you can forget about the caps unless it's to deal with electrical
noise - which could well be the case. A DC motor can be pretty noisy too.

***Yahbut, then where's the PID and how does the PID affect anything?

> > ***This is because you've implemented or have access to a defined
reference
> > clock - it appears - somewhat independent of the motor / tachometer
> > characteristics. Let's put it another way: How in the world do you
justify
> > such a low frequency clock? Just because it's there? Perhaps that's
not a
> > good enough reason.
>
> I guess I probably wasn't very clear on this when I started this thread.
> The "point" of this system *is* to phase lock onto the slow reference
> signal. That reference signal happens to lies in the frequency range of
> 1 - 50 Hz and this is not something I can control.
>
> I'm not using the reference signal to be arbitrary, it's sort of the
> point of this design and also why I'm treating the system as a PLL
> (getting my motor/VCO to lock onto an external reference).

***Then you gotta multiply it up methinks. I don't think you can avoid
doing this.

>
> Note: The reference frequency is not time varying and is valid and
> stable before the FPGA/uC power up.

***OK, and that's why Ts is fixed. At least it will be if you multiply up.
***Hmmmm. Why would that be? Well, the phase detector is essentially analog
isn't it? The output of the phase detector is either represented as a duty
cycle (analog) or a counter (which, if there are enough bits, then
approximates analog). Then, it may be the right idea to sample the counter
output at the (multiplied) ref clock rate.

>
> > ***Actually you could do a little analysis on this type of system. If
you
> > want to phase lock a motor to a clock where the clock is equal in
frequency
> > to the desired motor shaft rate, then you have defined the sample rate.
> > - Let's call the clock interval Ts and let's call it 50Hz.
> > - According to our rule of thumb 1/Ts is 10x the system bandwidth so the
> > system bandwidth cannot be greater than 5Hz.
>
> > - Let's assume the motor has a bandwidth of 18Hz. If that's the case,
then
> > this arrangement probably won't work. If there's some way to sensibly
fix
> > it, I don't know what it is without working harder on your situation.
Well,
> > you might filter somewhere in the feedback loop I guess (without
analyzing
> > it) but higher frequency motor load variations wouldn't be dealt with by
> > this controller. Similarly, power supply variations in this frequency
range
> > in the motor drive would not be compensated. It would be like saying
that
> > you just don't care about high frequency variations in the motor speed.
>
> Are you saying that I would be in trouble with 50Hz sampling and 18Hz
> motor bandwidth because the 10x rule means that my motor bandwidth
> should be < 5Hz but if it were 18 Hz the high frequency components WOULD
> affect it?

***Well, let's be clear. You will be in trouble, yes. However, it's not
because of high frequency components in the signal at any point exactly.
It's because the loop gain/bandwidth is higher than the sampling accounts
for. It means you are undersampling. It means there will be intolerable
delays from sensing to reacting. It could mean there is aliasing even.

Jerry is very good an explaining this.

>
> > > If the motor was leading the reference signal, I decreased the output*
> > > by one binary count. If the motor was behind the reference clock I
> > > advanced the output* by one binary count.
>
> > ***How do you know that this is enough gain or too much gain in this
part of
> > the system? Why not 2 counts or 4 counts or 1/4 count? Since you're
> > getting a limit cycle, maybe it's too much and looking nonlinear /
> > bang-bang.
>
> Actually I suspect it's way too small gain. I just set it up that way as
> a rudamentary test of the FPGA hardware and not really as a final
> control-loop.
>
> Just to be clear, by count, I mean I incremented my PWM register value
> by decimal 1; being 16-bit PWM, the register holds values in the range
> of 0 to 65535.
>
> Also, I don't see how I could get a "fractional count" unless I dithered
> the duty cycle value -- have it jump between two or more values very
> quickly so the "averaged" output makes it look like I have more
> resolution that I actually do. I guess I could dither if need be, but
> lack of resolution isn't my problem.

***Sorry if I misled you. Here's what I meant:
The LSB represents a voltage change at the motor (either plain dc from a DAC
or the average of a duty cycle). If that voltage is too large then the
control is more like bang-bang or on-off. First you control to too low a
speed, then you control to too high a speed, ad infinitum.
So, if the gain or LSB value is too large, then a smaller increment is
necessary. To get the equivalent of 1/4 LSB, you reduce the gain by 4; you
reduce the voltage per LSB by 4.

***You should not limit the count to 1 LSB per sample unless the sample rate
is very high indeed. You should increase/decrease the count by the value of
the error at each step. Otherwise there's a slew rate / nonlinearity in the
system. At least that makes it harder to analyze.

>
> > ***OK, so the frequency / speed control does work. That's good.
> > 100 degree variation sounds like a lot! Of course, if it's in a limit
cycle
> > due to 1 LSB, then it could be understandable.
> > 100 degree variation says that the motor is changing shaft position by
> > nearly 1/3 a revolution per revolution. So, that's indeed a lot.
> > Here's what could be happening in words:
>
> I was probably unclear on what I meant. The +/- 100 deg variation occurs
> over a LARGE number of error cycles, not in one count or one update.
> That is, over a period of say a minute, the tach sense drifts from the
> reference edge by +/- 100 deg.

***Well, OK then it's certainly not phase locked. So something is bad wrong
here. After all, if there's a 10-degree error one time, then a 20 degree
error the next time, etc. where the heck is the control system? Sounds
like the bandwidth of the controller is too low - which is accounted for by
the low sample rate and probably the single LSB correction.

***Ask this: if there is a 100 degree error with the present ref clock and
1 LSB change per sample, how long will it take for the voltage to change in
this fashion:
I assume the motor is 100 degrees ahead of the control point:
The motor is turning at 50Hz or 314 radians per second.
Let's assume that the nominal motor voltage at this speed is 4 volts.
So, linearized at this speed, the motor transfer function is 314/4=78.5
radians/sec/volt
We want to change the motor position by 1.74 radians.
We want to return the motor voltage to 4 volts after this excursion.
We want this excursion to happen in exactly one revolution - which may be
ambitious but demonstrative of this analysis.
So, it appears we want the motor to rotate 360-100=260 degrees in this one
revolution.
That is to have a speed of 226 radians per second.
So we will drive it with 2.88 volts for one revolution and then return to 4
volts.
This is 1.12 volts per 100 degrees per revolution.
If we applied a 0.112 volt change, it would have to be applied for 10
revolutions.

So, if I didn't get the numbers wrong, it appears you need a fair amount of
motor drive gain to account for variations in position. Does this help? Is
1 LSB anywhere nearly high enough per sample in view of these numbers?

So, if there's a perturbing torque on the motor shaft that drives it 100
degrees out, with 1 LSB it will take a long time to correct it appears.
Then, with the low sample rate, the correction may overshoot considerably
and you'd end up in a limit cycle perhaps. By the time the phase is
corrected, the motor speed is way off because the motor speed increase lags
the phase measurement so greatly.

You really need to do the stability analysis. That would make all of this
much clearer regarding gains, responsiveness, etc. I've not heard any
discussion about that.....

Two things to do:

1) Make the duty cycle or counter respond to the total error at one sample.
See what that does.

2) Multiply the reference clock so that it matches the tach frequency at the
set points.

3) Analyze the control loop gain/phase. Make sure to include the 1/s term
for the fact that you're doing a position servo.


Fred

[Tom]

>
>
> The DC motor I am using has an output that goes high once per revolution
> ("tach sense")

Surpised this works at all - this is in effect a sampling process so you
meed more pulses/revolution- at least 10 in fact for a decent bandwidth (the
10:1 rule of sampling within a control loop though you may get by with 5:1).



Tom

[Fred Marshall]

"Jay" <[email protected]> wrote in message news:mhmEb.11$_S3.8@fe10...
> Hello again Fred, & Jim,

Jay,

I'm curious about how you're doing with this. If you send me your email
address, perhaps we can take some of the discussion offline.

Fred

[Vince]

Fred,

> I'm curious about how you're doing with this. If you send me your email
> address, perhaps we can take some of the discussion offline.
>

Sorry for the delayed response (was out of town). I've realized what
everyone else was beating into me: the tach output is too "slow" for
what I need.

I'm modifying the design to use the quadrature encoder on the motor.
I'll give more details in a few days as I modify the design and do some
testing.

Thanks for your note of concern! It's really nice to have a resource
such as this newsgroup and help from people such as you.

Regards,
Jay.