You are on page 1of 4

8000DB1003

06/2010
Raleigh, NC, USA

Data Bulletin

A PID Testing Example


Retain for future use.

Overview
Requirements

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:
Hardware

Unity Premium Processor (pre-configured in Unity)

Software

Unity programming software version 2.0 or higher

User Comments

We welcome your comments about this bulletin. You can reach us by e-mail
at oem.solutions@schneider-electric.com.

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


Introduction

Introduction

8000DB1003
06/2010

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


value.

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

8000DB1003
06/2010

Testing the Program PI Control

A PID Testing Example


Introduction

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

8000DB1003
06/2010

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
www.schneider-electric.com/your-business/oems/

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