*Does anyone know why the LabVIEW PID takes the derivative of the process variable instead of the derivative of the error ?

**

*Does anyone know why the LabVIEW PID takes the derivative of the process variable instead of the derivative of the error ?

**

You’re right, that doesn’t make sense.

Perhaps that error wasn’t caught because people don’t use very large coefficients for Derivative, and this VI is not very maintainable.

If the intent is to get rid of noise in the Setpoint (that is, variation in the Setpoint much faster than the mechanism can respond), then the 2nd derivative of the PV could be used.

It’s not uncommon to use the derivative of the output (since the output is continuous, you don’t have problems with step changes, and the output generally moves in a constant direction relative to the error). But the derivative of the PV doesn’t make a lot of sense unless the VI was designed with a non-moving setpoint in mind.

I’ll try to ask one of the authors or maintainers today. Skimming through Wikipedia on PID, it lists this along with integral windup as common modifications to the algorithm and state the same reason as Jared.

Greg McKaskle

Jared and Greg are correct. The modification is actually very common on industrial PIDs to avoid the ‘derivative kick’ from setpoint changes. In the literature, this is also called PI-D controller or even 2-Degree of Freedom PID. Here is some literature that could be useful in the future:

Yes, and that would be me… Greg and Jared are correct about this feature. We use the derivative only from the measured variable to avoid the so called ‘derivative kick’ when you try to change its setpoint. This type of configuration is also called “PI-D controller” or “2 degree of freedom” PID.