Re: Electromechanical servo control & update rates
From: Robert Scott (no-one_at_dont-mail-me.com)
Date: 02/12/04
- Next message: bta3: "ethernet "stub""
- Previous message: Duy K Do: "Re: Bluetooth ACL Problems"
- In reply to: Jay: "Re: Electromechanical servo control & update rates"
- Next in thread: Ken Lee: "Re: Electromechanical servo control & update rates"
- Reply: Ken Lee: "Re: Electromechanical servo control & update rates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 12 Feb 2004 00:11:03 GMT
On Wed, 11 Feb 2004 06:17:35 -0600, Jay <invalid@127.0.0.1> wrote:
>
>Two counters are implemented. One counter counts quadrature pulses (and
>is reset every 1000 counts by the index pulse) and second counter is
>clocked by 1000x reference frequency. Second counter is mod 1000, so it
>wraps around at 1000.
>
>Counter outpus are subtracted to produce an error in terms counts.+
I thought that your target phase was determined by some external
event. But it is only determined by an internal counter. Is anything
else external locked to this reference counter? If not, then I wonder
why you specified an phase lock tolerance of .5 degrees to a reference
that is just an arbirary internal oscillator?
In any case, you must reduce all phase error readings to a range of
+/- 500 counts (half a rev), because in their raw form, these
differences are in the range of +/- 1000 counts. You must recognize
-999 counts as really just +1 count of phase error.
>My questions:
>
>1. Looking at the U-113 PDF, esp pages 3-134 (loop model) & 3-139
>(specific example), I am wondering what do I use for the the gain of my
>phase detector?
Use whatever you want. All that counts is the effective P, I, and D
gains at the end. Applying gain to the phase detector has the effect
of increasing the P, I, and D gains by the same amount. However you
may have phase detector gain considerations relating to your digital
implementation (range and resolution), assuming some sort of
fixed-point implementation. Of course if you have the luxury of a
floating-point implementation, then you really won't have to care
where you apply the gain.
>Do I claim the transfer function(or gain) is (1000 counts)/(2*pi
>radians)?
Sounds OK.
>Or is it actually (2*pi radians)/(1000 counts)?
No, the gain is how much the error signal changes for a given change
in the controlled parameter.
>2. In the same vein as #1, what do I claim is the gain for the PWM
>controller? For G(PD) (following the terminology of U-113) can I say
>that Vout/duty_cycle_value = 5V/16384?
Are you really planning on designing this control system using
theoretical modelling? By the time you finish fully characterizing
the complete tranfer function, I would have already closed the loop
and have a reasonably stable tuning using empirical methods.
>3. Considering #1 & #2, I am worried about the units that the actual
>control-loop will get as an input and numerically what it will output.
Don't worry. Just do it.
>Since my error(at least before any operations are performed) is a count
>(in terms of quadrature counts) and my "control knob output" is a duty-
>cycle value (which is translated to a voltage), I am unclear on how an
>error in terms of quadrature counts can be stuffed in a PID controller
>and how the output is translated into a value that the PWM controller
>can/will use.
The error is just a signed value. Whatever PID implementation you
choose will have an obvious place to stuff the error term. The PID
output will also be a number. If you have your gains set right, this
number will be in just the right form to put in the "on-time" register
of your PWM controller. Of course you will have to perform software
limiting since the PWM on-time register can only express 0 to 100%.
>
>I see in the U-113 the phase detector has a gain of .4V/radians and the
>control-loop has a transfer function of Volts/Volts and the power drive
>has a gain of 1 Amp/1 Volt, thus all the units work out nicely and the
>overall function is Amps/radians (radians of error in, Amps of current
>out).
>
>However, for my software PID implementation, do I need to translate my
>count error into an error in terms of radians? How do I handle the PID
>loop output to PWM duty cycle value translation?
Don't bother chasing down systems of units. It adds nothing to the
practical implementation.
>I recall Robert Scott's statement about needing 16 revolutions at
>1024counts/rev to get a 14-bit error, but I'm still confused about the
>gains and when "the rubber hits the road", how the PWM gain is actually
>accounted for.
That statement was just to suggest that you might have way more
resolution in your PWM controller than you needed. But there is
nothing terribly wrong with that.
I recommend the empirical approach. Start with a very low gain
I-loop. Revise your implementation as you learn more about the
required range and resolution of the values involved. Add a "P" term
and maybe a "D" term as required as you tune the loop.
-Robert Scott
Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)
- Next message: bta3: "ethernet "stub""
- Previous message: Duy K Do: "Re: Bluetooth ACL Problems"
- In reply to: Jay: "Re: Electromechanical servo control & update rates"
- Next in thread: Ken Lee: "Re: Electromechanical servo control & update rates"
- Reply: Ken Lee: "Re: Electromechanical servo control & update rates"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
