servo control: two PID loops or three?

djdelorie wrote:

The RPM measuring hardware works fine.[\quote]
No, if it can't read speeds below 6 RPM, then I suggest it is NOT working fine.
What does your logic do when the position shows a change (encoder count)
but the velocity reads as zero? Or, what happens when the velocity suddenly
reads above zero? This may be the cause of your jitter. When I said
"reliable" I meant that you may have some imprecision in the velocity
calculation due to variation in the width of each encoder state.

Jon

Its of the error but since differentiation is linear it amounts to the same thing

heres the relevant code in the PID comp:

352 /* and calculate derivative term as difference of derivatives */
353 *(pid->error_d) = *(pid->commandv) - *(pid->feedbackv);

I implemented a separate velocity loop, mostly to be able to tune it separately. My test rig has a wimpy power supply so I need to put in more logic to react accordingly (i.e. less I windup so less overshoot) when the output current is at max, but I'm getting decent results out of it:
www.delorie.com/cnc/pos-PI-1.html

Thanks!

Note: the windup overshoot is still only 10 counts at 4000 counts/rev, or 1/2 step compared to a normal 200 count stepper

I double checked the RPM measuring setup. I'm using a 2.5 MHz clock and measuring the pulse width of one encoder signal (each edge). At 3000 RPM, that's 25 clocks per measurement, or 4% precision. Minimum detectable speed is 1.15 RPM. At that speed, I'm getting 38 edges per second, or about one RPM update per 520 pid loops. At that speed, each measurement is "precise" to about 0.0015% but in that many loops the motor's speed could change enormously. Note: the hardware does not return a "zero" RPM until the pulses are too far apart to measure; there's no "sudden" motion just because the encoder changed. There's a global RPM register that's updated by hardware at each encoder edge. So effectively, I *am* timestamping each edge, I just don't have an infinite precision timestamp.

djdelorie wrote:

I implemented a separate velocity loop, mostly to be able to tune it separately. My test rig has a wimpy power supply so I need to put in more logic to react accordingly (i.e. less I windup so less overshoot) when the output current is at max, but I'm getting decent results out of it:
www.delorie.com/cnc/pos-PI-1.html

Thanks!

Note: the windup overshoot is still only 10 counts at 4000 counts/rev, or 1/2 step compared to a normal 200 count stepper

I don't know what your time scale is in the chart, but it appears you are commanding instantaneous
moves, so there must be lag and overshoot. You might try a trapezoidal accel ramp and see how
much better it does. So, it is doing the best it can for unachievable command.

Jon

Time is seconds, Position is 1/4000 of a rotation. Yes, it's an impossible move, but I figure the better "impossible" looks, the better the whole system will look. I'm also working off the test rig too, which has a wimpy power supply and no motor load. Mostly I want to make sure the system is tunable to be stable under various conditions. I'll do a trapezoid too, as I'm pretty sure I need an RPM feed-forward on the position loop to keep it tracking properly. At least, I needed that in the old code.

There may be a subtle difference depending on how the hardware works.
The time stamping hardware/driver in Pico systems, Mesa, and the software encoder measures the time between multiple edges if there are multiple counts per sample period (so its a period average over the number of edges that occured during the sample time)

If the ucontroller hardware just reports the last period, it will be noisier at speeds that generate more than one count per sample period

For refefence, here's how the hardware works...

The chip is an RX/62T microprocessor, which has hardware specificlaly for motor control (the T series == extra timers). The third-generation multi-timer unit (MTU3) chains two 16-bit timers, three capture registers, and three other control/buffer register together to both track phase counts and measure speed. The speed portion works as follows:

There's a 16-bit counter that runs at a high MHz (2.5 MHz in my case). At each edge of one of the incoming encoder signals, the count value is copied to one of the other registers and then cleared. This means that other register always has the width of the most recent period, to whatever accuracy and range your clock allows.

At 2.5MHz and 16-bit counters, that means the RPM range is 70,000 RPM down to 1.1 RPM, with precision improving from 0.3% at 3000 RPM (my motor's top speed) up to 0.003% at 1.1RPM. With my 20 KHz inner loop rate, that means "one measurement per loop period" happens at 600 RPM. Note: for consistency, I pre-read all my measurements at the start of the loop and use the stored values, rather than re-read that register every time. Since the new PWM values take effect at the start of the *next* loop, that means I'm pretty much always one loop behind on the correlation between measurements and control output. Oh well. The ADC, RPM, and PWM measurements and calculations are carefully choreographed to fit within the PWM waveforms, since my hardware can only measure phase currents when the low-side PWM driver is on (er, Fairchild FNB41560 inverter chip).

Given that my control loop is always a loop behind, which is better? Always using the latest RPM and letting the motor's inertia (at 600+ RPM) do the averaging, or averaging some even-older RPM readings? (hypothetical question, since I can't change my hardware anyway) My opinion is that the hardware is accurate enough that the "noise" is really actual changes in RPM and I should just use the latest values, adjusting the master clock to get the precision I need at my common working RPMs.

Unfortunately this is not ideal since quadrature error will contribute a fair amount of error (say 5-30% every edge)

N/Tn or period averaging is better, that is its as good as it can be at low speeds and improves with higher speeds