English is currently available.
Mechatronics Engineering DISCUSSION
My microcontroller runs a PI speed loop for a DC motor at 100 Hz, and I am aiming for a closed-loop bandwidth of about 20 Hz. The continuous-time simulation is well damped, but the real motor overshoots and rings at the same gains.
I assumed that sampling at five times the bandwidth was comfortably above the Nyquist limit of two. How fast does the loop really need to run, and is there any harm in simply running it as fast as the processor allows?
Nyquist tells you what you need to reconstruct a signal, not what you need to control with it. In a loop, sampling shows up as delay. The zero-order hold on the output behaves like a delay of half a sample period, and if the controller reads the sensor in one tick and writes the output in the next, there is a further full period of computation delay.
Delay costs phase: lag in degrees = 360 × f × t_d. At 100 Hz sampling, T = 10 ms. At a 20 Hz crossover the hold alone costs 360 × 20 × 0.005 = 36°, and with one sample of computation delay the total is 360 × 20 × 0.015 = 108°. Your continuous simulation has none of that, which is why it looks well damped.
The working rule is to sample at 10 to 20 times the closed-loop bandwidth at least, and textbooks often recommend 20 times or more for smooth response. At 20 times the bandwidth the hold costs only 9°, and a delay of 1.5 samples costs 27°. For a 20 Hz loop that means 400 Hz as a minimum and 1 kHz to be comfortable.
Reducing computation delay is as useful as raising the rate: sample, compute and update the PWM duty within the same interrupt, instead of applying the result one tick later.
Faster is not free, mainly because of measurement quantisation. If speed is computed as encoder counts per sample, the smallest step you can see is one count per period. With a 2000 count/rev encoder at 1 kHz, one count per sample is 1000 counts/s, or 30 rpm; at 10 kHz it is 300 rpm. The speed signal gets coarser as the loop gets faster, and the controller amplifies that as torque ripple and audible noise.
Fixes are to measure the time between encoder edges at low speed, average the speed over several samples, or run the speed estimate at a slower rate than the current loop.
Timing consistency matters as much as the rate. Run the loop from a hardware timer interrupt, not from the main loop with a software delay, because jitter in the sample instant acts like noise injected into the loop and makes the integral and derivative terms wrong, since both assume a fixed period.
For analog feedback such as motor current, trigger the ADC from the PWM timer so the sample is taken at the centre of the PWM period, where the ripple current passes through its average. Sampling at random points of the PWM cycle aliases the ripple into the measurement.
To make simulation and hardware agree, put the sampling into the model. The quick way is to add a pure time delay of 1.5 sample periods to the continuous loop and retune until the phase margin is back to 45° or more; the rigorous way is to discretise the plant with a zero-order hold and design in the z-domain.
Remember to rescale the gains when you change the rate if your code uses per-sample forms: the integral increment is Ki × T × error and the derivative is Kd × (change in error) / T, so moving from 100 Hz to 1 kHz without touching those constants changes the effective integral and derivative gains by a factor of ten each.
