Help with Digital PLL motor control

Jerry,

In article <3fdf0e8b$0$4742$61fed72c@news.rcn.com>, 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

"Jay" <invalid@127.0.0.1> 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

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" <invalid@127.0.0.1> wrote in message news:61NDb.23$cj.11@fe01...
> Hi Fred,
>
> Thanks for the detailed response.
>
> In article <9fqdnRLwzZTAGEKiRVn-vA@centurytel.net>, 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:

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" <invalid@127.0.0.1> wrote in message news:61NDb.23$cj.11@fe01...
> Hi Fred,
>
> Thanks for the detailed response.
>
> In article <9fqdnRLwzZTAGEKiRVn-vA@centurytel.net>, 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 wrote:
> Jerry,
> 
> In article <3fdf0e8b$0$4742$61fed72c@news.rcn.com>, 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.
&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;

"Jay" <invalid@127.0.0.1> 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

Hello again Fred, & Jim,

In article <BoidnQtaZPChXn2iRVn-ig@centurytel.net>, 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.

"Jay" <invalid@127.0.0.1> wrote in message news:mhmEb.11$_S3.8@fe10...
> Hello again Fred, & Jim,
>
> In article <BoidnQtaZPChXn2iRVn-ig@centurytel.net>, 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

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

"Jay" <invalid@127.0.0.1> 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