Packaged model-based control system

In most process applications the user must implement regulatory control loops to maintain the process at a specified state. These loops most often consist of an analog input value (temperature, pressure, etc.), a control function, and then an analog output to bring it to the desired state. The most common control function in use today is the PID loop or Proportional-Integral-Derivative control.

Though PID control is heavily utilized, it does have limitations. In cases where straightforward application of this method does not meet the needs of the process, the user must find an alternative. This can range from addition of supervisory control to the PID loop, to extensive model based control schemes.

BeyondPID

Oakleaf Engineering (Redwood City, Calif.) has developed a model-based control device, BeyondPID, which is targeted at these complex control situations. The system consists of a controller and a Graphical User Interface (GUI) package that runs under Microsoft Windows 95 or NT.

A standalone electronics unit typically provides the controller functionality with eight analog inputs and eight analog output points that can be configured as required. As an alternative approach, the model can be implemented in an existing control system using a standard API package.

The model definition is accomplished using the GUI package provided or through an interface to an existing control system using the RS-232 port. Information needed to use the model is entered simply by completing the necessary fields for the application on the setup form. While completion of the fields is simple, the user needs to adjust to the terminology as the GUI defines terms from the loop perspective and not the controller, which is the more customary approach. Because of this, Loop output is identified as an Input to the process while the Process Variable is called an Output (from the process) and the setpoint is called the Reference.

Once the model parameters are entered, the user establishes communication between the controller and the interface (GUI) by clicking on a display target. To build the model, the user then commands the Autotune function to start and waits for the controller to cycle the process to determine the actual response that finalizes the model. While Autotune is working, the package provides good trending capabilities. However, preference would be to show the loop output and process variable on the same trend rather than on separate pages.

Care needs to be taken in the Autotune function as the controller requires the process to be in a stable state before it introduces designed upsets or “bumps” to gauge system response. The user must set the magnitude and duration of these upsets such that the controller obtains the needed data for model formation while maintaining the safety of the process. While in Autotune the controller box and GUI advise the user of system status so there is no question as to what is happening.

Responds well in ‘auto’

Once the process model is tuned the system notifies the user it is ready for service. Selecting the “Auto” mode for each input to the GUI does this. Once in “Auto,” the controller software responds well to process changes and maintains control in conditions where traditional PID loops are unsuited. Response can be tested through the GUI using a recipe function that allows the programming of a series of setpoint changes. In support of this and the tuning operation, the GUI also has an easy to use data acquisition feature. Once activated, it gathers the data in a native format, then supports data export in ASCII text format.

This review is based upon version 1.0 of BeyondPID control hardware and GUI software.

For more information on BeyondPID, visit www.controleng.com/freeinfo .

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.