3
$\begingroup$

In digital or discrete control, instead of continuous analog-type variables, a controller samples a process variable signal at regular discrete time intervals. So, effectively, the process variable does not change as far as the system is concerned between those samples, or if it does, the change won’t be detected until the next sample. And it will be abrupt if it changes at all.

One would think that the faster the sampling rate (the more samples in the same time interval, or shorter times between samples), the more closely the discrete control would emulate ideal continuous control. Apparently that is not the case. In fact, as I understand it, increasing the sampling rate past some critical point can actually make a discrete time or digital control system unstable, as it can push the transfer function poles out close to and even outside the unit circle of stability.

This seems to be counter intuitive, at least to me. Is there a simple explanation for this that I’m missing here?

$\endgroup$
4
  • 1
    $\begingroup$ I have never heard of the effect you have mentioned. Do you have a reference? (There might be a simple misunderstanding somewhere.) $\endgroup$
    – Andy
    Commented Aug 1, 2016 at 7:26
  • $\begingroup$ @Andy- See EEME574LectureNotes_2Up.pdf and scroll down to Part 7; Section 1 near bottom. I guess that answers my original question. $\endgroup$ Commented Aug 1, 2016 at 17:37
  • 1
    $\begingroup$ Hmm never noticed this problem on a real system, though I vaguely remember it in lectures in the distant past. I regarded it as a theoretical matter; if your signal is very noisy and the method of implementing the calculation is susceptible to numerical errors when large numbers are involved. I believe this problem would be avoided by filtering (ie averaging) samples to reduce noise/spikes before putting them through the equations. $\endgroup$
    – Andy
    Commented Aug 1, 2016 at 18:03
  • 1
    $\begingroup$ I haven't read all the PDF but in Part 7 Sec 1 it seems to be talking about designing a controller in the s plane and then converting it to the z plane. There are several ways to do the conversion (some more "accurate" than others), and if you are going to design a digital control system, why not do the whole design in the z plane? - except that the traditional introduction is via continuous systems and the s plane, which arguably links better to other "traditional" uses of the s-plane like solving ODEs by Laplace transforms (though nobody does that any more in real life) $\endgroup$
    – alephzero
    Commented Aug 1, 2016 at 19:49

1 Answer 1

2
$\begingroup$

Based on the reference cited in the question comments, this particular situation occurs when you implement a controller designed in the continuous time domain on a discrete time system with measurement or model uncertainties.

Designing the controller in continuous time means that the sample rate is not taken into account/is assumed to be infinitely fast. Therefore the controller can behave very differently for different sample rates, even if the control gains remain unchanged. In particular, increasing the sample rate can destabilize the system by making it more sensitive to noise/uncertainty in the measurements (especially with PD and PID controllers).

A simplified example

You have a proportional-derivative controller, with a derivative gain $K_d = 1$ (the proportional part is not really important for this example). Your control system has a sensor which gives you a measurement of your error with a random uncertainty up to $w = 0.1$ units. At a certain moment in time the true error signal is changing at a constant rate of $\frac{de}{dt} = 10$ units/s.

First you implement your controller with a sample time of $T=0.1$ s. You estimate the current rate of change using a first order approximation, and it just so happens that you experience the maximum error in this timestep:

$\frac{de}{dt}_{measured} = \frac{e(k)-e(k-1)}{T} = \frac{\frac{de}{dt}T + w}{T} = \frac{de}{dt} + \frac{w}{T} = 10 + \frac{0.1}{0.1} = 11$ units/s

Therefore the output of the derivative part of your controller is $11K_d=11$, i.e. 10% higher than the ideal output of the continuous controller ($10K_d=10$). Notice that the contribution of the error term to your controller output is inversely proportional to sample time, therefore smaller sample times (faster sample rates) increase its effect.

Then you decide, faster must be better, so you decrease the sample time to $T=0.01$ s. Now, in the same situation, the estimated rate of change of error is:

$\frac{de}{dt}_{measured} = 10 + \frac{0.1}{0.01} = 20$ units/s

The output of the derivative part of the controller is now $20K_d = 20$ i.e. almost double what it was before, and 100% higher than the ideal output. Your controller is now behaving more aggressively even though the true rate of change of error has not increased.

The problem is exaggerated in this example by using a first-order approximation, but more complex approximations of the derivative will only mitigate, not eliminate, the problem. The fact is that changing the sample rate of the system can have a negative impact in the presence of any kind of measurement uncertainty. Now, whether your controller performs better or worse when you increase your sample rate depends on the relative magnitude of the uncertainty versus the rate of change of the error signal, the relative magnitudes of your derivative and proportional gains, and the type of approximation you use for your derivatives.

Conclusion

If you are designing a system where the controller cannot be approximated as continuous and there are measurement or other uncertainties present, increasing the sample rate will not necessarily increase performance because the influence of the uncertainty on the control input will increase.

$\endgroup$
1
  • $\begingroup$ Thanks to all of you for your insightful comments and your thoughtful answer. I think I have a better understanding of the issue now. $\endgroup$ Commented Aug 3, 2016 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.