You are on page 1of 4


Raleigh, NC, USA

Data Bulletin

A PID Testing Example

Retain for future use.


This data bulletin describes how to test a software

proportional-integral-derivative (PID) controller with another PID controller.
The following hardware and software is required:

Unity Premium Processor (pre-configured in Unity)


Unity programming software version 2.0 or higher

User Comments

We welcome your comments about this bulletin. You can reach us by e-mail

PID Terminology

The PID is one of the primary feedback-control mechanisms available to the

software designer and typically has the following characteristics:

Process Variable: The current status of a process under control (such

as a sensor).

Setpoint: A target value that the PID controller is attempting to reach.

Integral Term/Gain: A summation of the differential error over time

multiplied by the integral gain.

Derivative Term/Gain: The rate of change of the differential error over

time multiplied by the differential gain.

Proportional Term/Gain: Makes a change to the output that is

proportional to the differential error input multiplied by the
proportional gain.

In many applications, the derivative term is simply set to zero, which

effectively turns the PID into a PI controller. All PID controllers need to be
tuned, which requires that the individual gains are set to maximize system
performance while maintaining stability.

2010 Schneider Electric All Rights Reserved

A PID Testing Example




In basic to moderate control scenarios using feedback, the PID is an

obvious choice. One of the issues in implementing a PID is the testing of the
system. When dealing with pure discrete logic I/O, the testing mechanism
becomes more complex. The following example steps through the process.
Refer to Figure 1 as necessary.

An Altivar 71 drive with a Controller Inside card is running the

Codesys PID block as a PI control.

Using a setpoint entered in the drive Human Machine Interface (HMI),

the Controller Inside (CI) card program converts this setpoint into an
ambient temperature target.

This temperature target is compared to a 420 mA temperature sensor


The PI control outputs a drive frequency based on the differential of the

two temperature values.

An additional pressure sensor is monitored:

if the pressure is in a deadband window of 10 PSI around a minimum
setpoint, the drive should shut off.
at a pressure lower than the minimum deadband, an output should
be set to open a valve which will stay open until the maximum
setpoint is reached. The drive should be shut off.
if the pressure is higher than a maximum setpoint, the drive should
run at maximum frequency.
in between the two extremes, the PI loop should run, modulating the
output frequency of the drive based on the sensed ambient
temperature and setpoint.

Figure 1:

Overview of the Basic Control Scheme

2010 Schneider Electric All Rights Reserved


Testing the Program PI Control

A PID Testing Example


The system described in the Introduction on page 2 is implemented and

now needs to be tested. Some of the testing can incorporate passive testing
techniques such as potentiometers to simulate sensors. This type of testing
is adequate to evaluate how the system is responding. However, due to
multiple sensors and caveats to the control scenario, automated testing
would be better. Use a PLC to simulate the system.
The extremes of the control system are easy to test as described in the
Introduction on page 2. Simulate the pressure sensor with a 420 mA
output from the PLC and verify that the drive turns off or on appropriately. It
is the PI loop modulation between the two extremes that presents a testing
problem. Consider that:

The ambient temperature sensor is simulated via a 420 mA output from

an external PLC.

When sending a temperature value that is known to be the same as the

target setpoint, the drive should home-in on the current output frequency
and hold that frequency.

Adjusting the simulated ambient temperature value increases or

decreases the output frequency.

Problems include the following:

It is easy to have the drive home-in on an extreme, such as the

maximum output frequency, and stay there.

By adjusting the simulated temperature, it is hard to predict what the

output frequency should be.

Since output frequency cannot be easily predicted, this may not be a

valid test of the solutions PI loop.

The ideal way to test the PI loop is to pick an output frequency for the drive
and have the system home-in on that frequency. For example, pick a
desired output frequency, such as 30 Hz, and have the drive achieve that
frequency using the PI loop. This is accomplished by the PLC test program
implementing its own PI loop using a frequency setpoint and drive output
frequency as the process variable.
Ideally, use another PI in the test PLC to force a desired output frequency.
This will test the PI loop of the drive controller and verify the response over
some period of time. This is accomplished by:

2010 Schneider Electric All Rights Reserved

To analyze the PI loop of the Altivar drive, the test PLC activates its
own internal PI control.

The test PLC PI control takes the output frequency of the drive as its
process variable. Setpoint for the output frequency is part of the iterative
test, so several different frequencies could be used.

Output from the test PLC PI control is temperature, which is sent out
through a 420 mA signal to the Altivar drive. This is simulating the
ambient temperature.

A PID Testing Example

Data Bulletin


The ambient temperature simulated by the test PLC is dictated by the output
frequency of the drive during PI loop testing. Figure 2 shows the test PLC
program in Unity programming software.
Figure 2:

Test PI Program in Unity

The test PLC program may appear as two PI controllers wrestling for control
of the system. There are a couple of points to remember when using this
testing methodology:

Schneider Electric USA, Inc.

8001 Knightdale Blvd
Knightdale, NC 27545 USA

One of the PI systems must have a slower response time. Begin with a
factor of 10. One of the PI controllers, the test PLC in this example, must
have its gains adjusted to be approximately a factor of 10 less than the
other. The test PLC proportional gain for this example was set at 0.4
while the Altivar 71 drive was set at 10.
If the response time of the two systems are set too close they will
compete against each other for control. In this example, it manifested as
the drive output frequency searching until either the desired output
frequency was reached or the test failed because the PLC PI controller
won the battle.

Scan times of the two systems should be similar.

Latencies such as networks, outputs, and so forth. In this example,

CANopen was used to read in output frequency values from the drive.

Acceleration and deceleration values within the drive can cause PI error
values to significantly increase if the response is set too high.

PID blocks have other settings, such as, integral and derivative timing.
Ensure the meaning of these values is understood as they can have an
impact on the performance of the PID loop.

The two systems must be calibrated to each other. In this example, the
temperature values simply have to be very close to derive test benefits.

Altivar is a registered trademark of Schneider Electric. Other trademarks used herein are the
property of their respective owners.
Electrical equipment should be installed, operated, serviced, and maintained only by qualified
personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of
the use of this material.

2010 Schneider Electric All Rights Reserved