# What is the advantage of a Z transform derived PID implemenation?

I've seen many PID articles, such as this, use a Z transform of the generic PID equation to derive some crazy difference equation which can then be implemented in software (or in this case an FPGA). My question is, what is the advantage to such an implementation versus the traditional and much more intuitive, PID without a PhD type implementation? The second seems easier to understand and implement. The P term is straight multiplication, the integral uses a running sum and the derivative is estimated by subtracting the previous sample from the current sample. If you need to add a feature such as Integral Windup protection, it is straight forward algebra. Trying to add Integral Windup protection or other features to a difference type algorithm, such as linked above, seems like it would be much more complicated. Is there any reason to use such an implementation, other than the "I'm a bad ass who likes to do Z transforms for fun" type bragging rights that go along with it?

EDIT: The PID without a PHD article I linked is an example of the simpler implementation that uses a running sum for the integral term and the difference between consecutive samples for the derivative term. It can be implemented with fixed point math in a deterministic manner and can include real time time constant information in the calculation, if desired. I'm basically looking for a practical advantage to the Z transform method. I can't see how it could be faster, or use less resources. Instead of keeping a running sum of the integral, the Z method appears to use the previous output and subtract the previous P and D components (to arrive at the integral sum by calculation). So, unless someone can point to something I'm missing, I will accept AngryEE's comment that they are essentially the same.

FINAL EDIT: Thanks for the responses. I think I've learned a bit about each but in the end, think Angry is correct in that it is just a matter of preference. The two forms:

$$u(k) = u(k-1) + K_p(e(k) - e(k-1) + K_i T_i e(k) + \frac{K_d}{T_i}(e(k)-2e(k-1)+e(k-2))$$ $$e(k-2) = e(k-1), \quad e(k-1) = e(k)$$ $$u(k-1) = u(k)$$

or

$$\mbox{sum} = \mbox{sum} + e(k)$$ $$u(k) = K_p e(k) + K_i T_i\cdot \mbox{sum} + \frac{K_d}{T_i}(e(k)-e(k-1))$$ $$e(k-1) = e(k)$$

will evaluate to essentially the same thing. Some mention the first can be implemented in a DSP or FPGA faster, but I don't buy that. Either could be vectorized. The first requires two post operations, the second requires one pre and one post operation, so it appears to even out. The first also requires 1 more multiplication in the actual calculation.

• Did you mean "Differential equation"? Mar 23 '11 at 1:28
• I must have misunderstood your comments, based on this feedback I did at least. I will remove my comment! Mar 24 '11 at 3:13
• Please move to dsp.stackexchange.com Feb 3 '12 at 15:48

You're getting befuddled by all of the fanciness of the Z-transform. The two approaches are fundamentally the same - the PID without PHD approach just has fewer subscripts. They perform the same basic function and use the same basic math.

The only major difference between the two that I can see is that the PID without PHD doesn't take sampling time into account. For doing anything that might be unstable, sampling time is a very important consideration. The benefit of the Z-transform approach in this case is that you can't use it without taking sampling time into account - it forces you to show your work and helps you design a more stable system.

It also looks like the case study you found implementing the Z-transform approach was designed to be highly deterministic. This explains their use of FPGAs - the calculations will always take the same amount of time. The PID without PHD implementation is decidedly not deterministic. The use of doubles as variables instead of a fixed-point implementation is sure to cause non-deterministic behavior on any microcontroller without a floating-point unit (and probably on uCs with an FPU as well). The case study is working on a whole different level of complexity compared to the PID w/o PHD approach.

So fundamentally the math and control approach is the same, but the case study/Z-transform approach is more rigorous and theoretically grounded. The PID w/o PHD approach will only work for very simple, non time-critical system that are relatively stable.

• The PID without a PHD article is just an example of the simpler implementation, which uses a running sum for the integral and the difference between consecutive samples for the derivative. The article states that sample time should be consistent. Sampling time could easily be added to the I and D calculations, but in most instances it isn't done in the actual calculation. The controller's GUI (or other interface) will present the I and D terms to the user in terms of seconds based off the loop time.
– bt2
Jan 22 '11 at 0:33
• @bt2 it sounds like you have a very specific case where the PID w/o a PhD is the best approach. Most systems don't have a display of I and D terms in any way. It is the result of the PID controller that has some change on the system as a whole that is then looped back on itself. If you are just displaying to a user then there isn't really any reason to worry about stability. Jan 25 '11 at 18:44
• "The PID w/o PHD approach will only work for very simple," -- I disagree. You can definitely optimize digital control systems using Z-transform analysis, but the flip side is you can get caught up into modeling your system so precisely that you miss the forest for the trees. Dec 16 '11 at 22:24

The Z-transform method of designing the PID controller will eventually yield a much more efficient implementation. This is critical if you are designing for the smallest FPGA/DSP/Microcontroller for you application.

The mentioned "PID without a PHD" is probably the easiest approach to implementing a PID control in software, but it becomes cumbersome at higher sampling rates.

Additionally, the Z-transform lends itself better to designing in a discrete (digital) domain. The traditional (Laplace transform) method of design is more for continuous time. There are multiple ways of converting between the two (Zero-Order Hold, Linear Interpolation, Pole Placement, Bilinear/Tustin), each comes with it's strengths and drawbacks in terms of stability and response of the system. It's generally just easier to do the entire design in the discrete domain.

Long story short, if you are using a relatively "slow" system (all of the major behaviors happen significantly under a 100kHz or so), then the first design is probably just fine. You can implement it on a microcontroller or PC and be done with it. As the systems get faster, then you may have to use the Z-transform method to get the speeds that you need (the article mentions 9.5MHz, assuming you have A/D and DACs that can keep up).

• Same number of math operations, different representation of numbers. Doubles are a much more complex representation of numbers than the fixed-point method used in the case study. Less complex means fewer operations (on the silicon). Jan 21 '11 at 16:04
• @bt2, I would say more efficient in the sense that DSP chips are set up for SIMD (Single Instruction, Multiple Data) instruction sets. While it is the same number of math operations, the Z transform allows you to do all of the multiplies in one instruction cycle, then sum all of the elements of the resultant vector in one cycle (platform dependent). So while the math is the same, the time complexity is significantly lower, yielding higher speedups. Jan 22 '11 at 2:21
• @bt2 the z-form lends itself to implementation as a difference equation, which depends only on past outputs and the current input, without requiring a running sum which will at some point overflow (or underflow). DSPs are designed to allow efficient implementation of digital filters via the differences equation approach. See en.wikipedia.org/wiki/Digital_filter esp. direct forms - that's what DSPs are optimised for. Jan 23 '11 at 3:26
• I think you are missing something. The running sum will never overflow under normal circumstances. IIR filters won't always saturate, and in the case of a PID control, that normally won't be the case. Saying it will with one algorithm but won't with another is false. The running sum is likewise based on previous outputs. If one causes overflow, they both will. Think of it this way, the 2nd implantation IS the first, with some math factored out...u(k-1) - kp(e(k-1) - kd/Ti(e(k-1) - e(k-2) == (running sum).
– bt2
Jan 23 '11 at 13:44
• -1: Z-transforms don't give you more efficient implementation. In fact, if you compare a 1-pole low-pass filter using the "naive" digital method to a 1-pole low-pass filter using the bilinear transform, you'll get a slightly less efficient implementation with this approach. Regardless of the filter derivation, the same # of state variables = about the same efficiency of implementation. In large part this is an independent quantity from the way the filter was designed. Dec 16 '11 at 22:26

Here's the deal, in my experience:

• Z transforms help for some analysis: the theory of discrete-time-sampled systems is best modeled through Z transforms.
• Design of PID controllers or low-pass filters can be done both via Z transforms as well as classical analysis, with one of several approximations used to transform derivatives/integrals from continuous-time to discrete-time. If your poles and zeros are at low frequencies compared to the sample rate, it doesn't matter. Stick with whatever approach you feel most confident with.
• Z transform derivation of filters and controllers often obscures the physical meaning of the parameters of those filters and controllers. If I have a PID loop with an integral gain, a proportional gain, and a differential gain, I know what each of those parameters does directly. If I use Z-transforms, they're just numbers that I had to derive somehow.
• Implementation of filters and controllers may or may not obscure the physical meaning of the parameters of those filters and controllers. This quality is in large part independent from the previous point: If I have a Z-transform-based design, I can convert it to a classical-looking implementation, and vice-versa. Your example under FINAL EDIT is a good one because the second implementation keeps the integrator ("sum") separate in its own state variable. That state variable has meaning. The first implementation keeps the state variable as past history of the error; that has meaning, but it provides less insight in my opinion.

Finally there are other issues involving nonlinearity or analysis that often make you choose one implementation over another (for me it's always the classical approach for controllers, for FIR filters it's the Z transform, and for 1- or 2-pole IIR filters it's usually the classical approach):

• For controllers, I always keep an integrator as a state variable, rather than past error samples. The reason is that real systems often require anti-windup where you have to clamp the integral from going too positive or too negative. (And if you're implementing in fixed-point, you have to do this anyway, because the wraparound condition when you hit overflow will do Bad Things to the behavior of your control loop)

• For the same reason, I also always calculate the integrator in an output-referred way: e.g. sum += Ki*error; out = stuff + sum rather than sum += error; out = stuff + Ki*sum. With the second approach, if you change the gain Ki, that scales the integrator's effect on the output up and down, which probably isn't what you want, and the limit changes depending on gain. If you multiply error by Ki before integrating, your units of the integrator are the same as the units of the control loop output, and it has more obvious physical meaning.

(update: I've written a blog entry on this topic in more detail.)

Edit:

Using the Z-transform makes it easier to combine and simplify LTI systems for analysis. For example, a cascaded series of k LTI systems with transfer functions H1, H2, ..., Hk will combine as a simple product H = H1*H2*...*Hk. Also, the transfer function of a negative feedback loop is T = G/(1 + G*H), where H is on the feedback path. Once you have an overall transfer function, you can analyze the stability (location of poles) and performance (transients, steady-state error), adding additional filters and feedback to optimize the design.

For higher order sub-systems, you can partition the system function and implement it as a series of cascaded biquads (i.e. by pairs of zeros and poles, such as complex conjugates or repeated roots), which decreases instability caused by quantization. A canonical-form biquad:

• Your answer sounds impressive, but I have pretty much no idea what you said. What is quantization stability, for example, and how is it superior for one form of the equation than the other?
– bt2
Jan 25 '11 at 4:15
• The transfer function H(z) is a rational function B(z)/A(z). Each polynomial in z is a factor of N zeros for an Nth order system. The zeros of A(z), the ones in the denominator, are called the poles (this is the feedback path). To a constant scaling factor, a Linear Time Invariant (LTI) system is described by its zeros and poles. Jan 25 '11 at 4:23
• A discrete-time LTI system is stable if all of its poles are inside the unit circle on the z-plane. But quantization with finite digital precision introduces noise that can cause a system to be marginally stable, unstable or drift into instability over time. By factoring H(z) into a product biquadratics (biquads), this kind of error is minimized. Jan 25 '11 at 4:29
• A biquad is the preferred minimum partition since the zeros of a polynomial with real coefficients are either real or in pairs of complex conjugates. The biquad B(z)/A(z) is (b0 + b1z^-1 + b2z^-2)/(a0 + a1z^-1 + a2z^-2). Jan 25 '11 at 4:34
• I added and then removed an example for the quantization noise comparing a cascaded quadratic to a direct 4th order poly. But it was too much. I need to get some sleep. Sorry, tyblu. Jan 25 '11 at 6:47

The hard part about a PID controller is not the code itself. The issues actually come in when trying to optimize controller. Sure you can do trial and error and get a pretty decent controller, but some systems are just far too complex for a trial and error method to be easy to perform. These same systems tend to be the ones that need a very good controller instead of just a decent one. In this case the Z-transform is much easier to analyze.

Another thing to think about is the stability of a system. You may be dealing with a system that is rather difficult to become unstable, or even if it does it doesn't hurt anything. But there are many systems that can have catastrophic results if the controller causes it to go unstable. The Z-transform is another place where it is much easier to identify if there will be any issues.

And 1 final note. When analyzing a system as a whole you will have to get equations for all of the components in your system. Sure you can get it from the PID w/o a PhD, but if you are already have been working with it in the Z-transform method there is far less back and forth work that you have to do.

Now, as a personal preference, I always use the PID w/o a PhD method. This is just because I am just using micro-controllers with systems that aren't terribly dependent on the controller.

There are several points why the Z-transform form has higher utility.

Ask anyone promoting the time-based/simple/sans-PHD approach what the set their Kd term to. They are likely to answer 'zero' and they are likely to say D is unstable (without a low-pass filter). Before I learned how all this comes together, I would have and did say such things.

Tuning Kd is difficult in the time-domain. When you can see the transfer function (the Z-transform of the PID sub-system) you can readily see how stable it is. You an also readily see how the D term is affecting the controller relative to the other parameters. If your Kd parameter contributes 0.00001 to the z-polynomial coefficients but your Ki term is putting in 10.5 then your D term is too small to have a real effect on the system. You can also see the balance between the Kp & Ki terms.

DSP's are designed to calculate finite-difference-equations (FDE). They have op-codes that will multiply a coefficient, sum to an accumulator, and shift a value in a buffer in one instruction cycle. This exploits the parallel nature of FDE's. If the machine lacks this op-code... it's not a DSP. Embedded PowerPC's (MPC) have a peripheral dedicated to calculation of FDE's (they call it the decimation unit). DSP's are designed to calculate FDE's because it's trivial to transform a transfer-function into a FDE. 16-bits is not quite enough dynamic range to easily quantize coefficients. Many early DSP's actually had 24-bit words for this reason (I believe 32-bit words is common today.)

IIRC, the so-called bilinear transform takes a transfer function (a z-transform of a time-domain-controller) and turns it into a FDE. Proving it is 'hard', using it to obtain a result is trivial - you just need the expanded form (multiply everything out) and the polynomial coefficients are the FDE coefficients.

A PI controller is not a great approach - a better approach is to build a model of how your system behaves and use PID for error correction. The model should be simple and based on the basic physics of what you are doing. This is the feed-forward into the control block. A PID block then corrects for error using feedback from the system under control.

If you use normalized values, [-1 .. 1] or [0 ... 1], for the set-point (reference), feedback, & feed-forward then you can implement one 2-pole 2-zero algorithm in optimized DSP assembly and you can use it to implement any 2nd order filter which includes PID and the most basic low-pass (or high-pass) filter. This is why DSP's have op-codes that presume normalized values, e.g. one that will output an estimate of the inverse-squareroot for the range (0..1] You can put two 2p2z filters in series and create a 4p4z filter, this allows you to leverage your 2p2z DSP code to, say, implement a 4-tap low-pass Butterworth filter.

Most time-domain implementation bake the dt term into the PID parameters (Kp/Ki/Kd). Most z-domain implementations don't. dt is put into the equations that take Kp, Ki, & Kd and turn them into a[] & b[] coefficients so your calibration (tuning) of the PID controller is now independent of the control rate. You can make it run ten-times faster, crank out the a[] & b[] math and the PID controller will have consistent performance.

A natural result of using FDE is that the algorithm is implicitly "glitchless". You can change the gains (Kp/Ki/Kd) on-the-fly while running and it is well-behaved - depending on the time-domain implementation this can be bad.

A lot of effort is usually spent on time-domain PID controllers to prevent integral wind-up. There's a simple trick with the FDE form that makes the PID behave nicely, you can clamp it's value in the history buffer. I haven't done the math to see how this affects the behavior of the filter (with regard to Kp/Ki/Kd parameters), but the empirical result is that it's 'smooth'. This is exploiting the 'glitchless' nature of the FDE form. A feed-forward model contributes to prevent integral wind-up and the use of the D term helps balances the I term. PID really doesn't work-as-intended with a D gain. (Slewing setpoints is another key feature to prevent excessive wind-up.)

Lastly, Z-transforms are an undergrad topic not "Ph.D." You should have learned all about them in Complex Analysis. This is where the university you go, the instructor you have, and the effort you put into learning the math and learning how to use the tools available can make a significant difference in your ability to perform in industry. (My Complex Analysis class was horrible.)

The defacto industry tool is Simulink (which lacks a computer-algebra-system, CAS, so you need another tool to crank out general equations). MathCAD or wxMaxima are symbolic solvers you can use on a PC and I learned how to do it using a TI-92 calculator. I think the TI-89 also has a CAS system.

You can look up z-domain or laplace-domain equations on wikipedia for PID & low-pass filters. There's a step here that I do not grok, I believe you need the discrete-time-domain form of the PID controller then need to take the z-transform of it. The laplace transform should be very similar to the z-transform and is given as PID{s} = Kp + Ki/s + Kd·s I think the z-transform would better account for the Dt's in the following equations. Dt is delta-t[ime], I use Dt as not to confuse this constant with a derivative 'dt'.

b[0] = Kp + (Ki*Dt/2) + (Kd/Dt)
b[1] = (Ki*Dt/2) - Kp - (2*Kd/Dt)
b[2] = Kd/Dt

a[1] = -1
a[2] = 0


And this is the 2p2z FDE:

y[n] = b[0]·x[n] + b[1]·x[n-1] + b[2]·x[n-2] - a[1]·y[n-1] - a[2]·y[n-2]


DSP's typically only had an multiply & add (not a multiply & subtract) so you may see the negation rolled into the a[] coefficients. Add more b's for more poles, add more a's for more zero's.

It is better to use the Z transform method in general, because by doing this, you preserve the exact behavior of the equivalent analog system. There are well-known tuning methods, like Ziegler-Nichols, which work in the analog domain just as published. If you use the Z transform method, you have a mathematically rigorous expectation that your resultant controller will do the same thing for the same values of the P, I and D gains, that it will do in the analog domain, given those gains. Plus you can draw a discrete root-locus for the system and predict stability for a given set of gains, which cannot do if you create an ad hoc controller directly in code.