CompactRIO Temperature Controller Reference Application

[cpeacock]

Description

Description-Separate-1

Overview

A temperature controller is a device that controls the temperature of a system or process.  This is typically done by measuring the current temperature (process variable), comparing that value against a desired temperature value (setpoint) and generating an output to affect the system or process such that the current temperature moves toward the desired temperature.  While this makes up the fundamental requirements of a temperature controller, many have additional features like alarming, setpoint profiles, data logging, etc.

Description

Fundamental Requirements of a Temperature Controller 

All temperature controllers must measure the current temperature, run a control algorithm to determine an appropriate output and generate that output.

Temperature Measurement Types

Various sensors are used for measuring temperature.  The most common are RTDs, thermocouples, and thermistors.  All temperature controllers must handle at least one type of sensor but some handle all three.  

Control Algorithms

Once the temperature has been measured, a control algorithm must be used to determine the output.  Typical control methods are as follows.

On/Off Control:

This is one of the most basic types of control.  This method compares the current temperature to the desired temperature and sets the output to full on or full off.  Some on/off controllers have features such as deadband or hystersis to prevent systems from quickly switching between on and off to prevent premature wear or damage.  This control type is used in slowly responding, low cost systems, or systems that doesn’t require precise temperature control. 

PID Control

This is a slightly more complicated approach that to control.  A PID controller works in a similar fashion to on/off controller in that it looks at the error between the current temperature and desired temperature to calculate the output.  The main difference is the PID algorithm allows for three coefficients to be entered, namely P, I , and D, which each affect the control system in different ways.    This gives the engineer flexibility in setting how the controller performs.  PID is typically more expensive than on/off control but provides a much higher level of precision and can handle most real world systems. 

Output Types

Once the temperature acquisition and control algorithm have been completed, the controller needs to generate an output that affects the system being controlled.  These outputs are typically connected to heater elements, fans, vents, valves, etc. which require large levels of power.  The output for an on/off controller can be as simple as a mechanical relay that turns on and off a heating element where the output of a PID controller can generate a digital pulse train that control the speed of a fan or an analog signal that is used as a process variable for a larger control systems (motor drives, etc.).

Additional Features

While the above features are the basic requirements of temperature controllers, additional features are often provided.

Setpoint Profiles

Some controllers implement the ability to update the desired temperature or setpoint through a series of steps, ramps, and soaks.  This puts the devices under test through real world circumstances.  As an example, some home thermostats include this option so that a house can be kept at different temperatures at different parts of the day.  

Data Logging

It is often desirable to go back and view temperature control data from a process or system over some duration of time.  Therefore, some controllers have the ability to record the temperature, desired temperature, output, etc to a file.

Safeties

Another common feature is the ability to set limits that trigger a particular event.  This event could be as simple as a notification to the user and as severe as putting the temperature controller and its outputs into a safe state.

CompactRIO Temperature Controller Application

The following section discusses an implementation of a temperature controller using CompactRIO.  This application has two top level VIs.  The first set is called Temperature Controller_Main VI, which runs on the CompactRIO and the second is called Temperature Controller Interface_Main VI, which runs on a Windows computer.  These two VIs are discussed below.

Temperature Controller_Main VI - Software Architecture

The Temperature Controller_Main VI is a 16 channel temperature controller application with data logging and setpoint profiling.  The application runs on a CompactRIO target and utilizes the NI Scan Engine.  Therefore, any analog input modules supported in the NI Scan Engine can be used for measuring temperature.  The NI 9211 or NI 9213 are designed specifically for measuring thermocouples.  PID control or on/off control can be selected on a per channel basis as the control algorithm.  This means that any (NI Scan Engine supported) digital output modules that support PWM or analog output modules can be used as the output channel for PID control while any digital output module can be used as the output channel for on/off control.

The Temperature Controller_Main VI can be broken up into the following six sections: IO (input/output) engine, control engine, profile engine, data logging engine, command engine, and network communication.  From a high level, each section or process has specific responsibilities to perform.  Often this requires information from other processes.  There are two ways in which processes can send or receive information.  Messages and/or commands are sent and received through queues using the Asynchronous Messaging Communication (AMC) reference library and data is shared through a central memory table using the Current Value Table (CVT) reference library.  For a high level diagram of the code layout, see the images below.

High Level Temperature Controller Architecture

Temperature Controller_Main VI Block Diagram

IO Engine

The IO engine is based on the NI Scan Engine, NI Scan Engine Advanced IO Access API, and the cRIO IO Engine (CIE) reference library.  It samples all the CompactRIO input modules and updates a central memory table with the results while, at the same time, updating all the output modules with data from the same central memory table.  This table makes the IO data available to other processes, like the data logging engine and control engine.  The central memory table is implemented with the Current Value Table (CVT) reference library.  

The IO engine also has the ability to average multiple input channels together and to scale input channels.  This option is only possible if the result of the averaging and scaling is to be used as the process variable in the control engine.  This data is kept separate from the raw channel data in the central memory table so that both processed and raw data can be accessed.

Below is the block diagram of the IO engine.

IO Engine Block Diagram

Note: Currently, the IO engine executes at 10 Hz and is timed off the NI Scan Engine to ensure that the central memory table is updated as soon as data is available.

Control Engine

There are 16 control channels available in this application with a control engine per channel.  The control engine is where the control algorithm resides.  Each control channel has general settings like temperature inputs, control type, and output channel.  The control engine uses these settings to read the appropriate data from the central memory table, run the control algorithm, and update the central memory table with the resulting output.  Below is the block diagram of the control engine.

Control Engine Block Diagram

Note: The control engine is a re-entrant VI copied 16 times, which allows for the same VI to be used for 16 control channels.

Profile Engine

A profile engine resides inside of a control engine, which means there is a profile engine per control channel.  It updates the temperature setpoint based on a user-defined profile.  Currently, profiles can consist of ramps, steps and soaks.  If no profile is selected, an initial setpoint is used from the control channel configuration.  Below is the block diagram of the profile engine.

Profile Engine Block Diagram

Data Logging Engine

The data logging engine is based off the CVT Data Logger (CDL) reference library.  It records all raw input and output channel data, process variable data, setpoint data, output data and operational status data to file by accessing this information in the central memory table at 1 Hz.  The data logging engine starts when any control engine is started and stops when all the control engines are stopped.  If the data logging engine logs for over an hour, it closes the current file, transferred the file to a new folder, and starts logging to a new file.  This allows for older data files to be FTP’ed from the controller to a host interface application (discussed below) without worrying about file corruption.   The data logging engine logs to TDMS files which can be viewed in Diadem or Microsoft Excel using a plug in (TDM Excel Add-In for Microsoft Excel Download).

The block diagram of the data logging engine is pictured below.

Data Logging Engine Block Diagram

Command Engine

Each process in the temperature controller application has a queue associated with it through which commands can be issued on.  The command engine is the only process that is allowed to send commands on these queues.  This architecture allows for a centralized command set for all processes in the application.  The command engine itself also has a queue, which allows access to this centralized command set.  The network communication section of this application takes advantage of this to allow for commands to be issued from the Temperature Controller Interface_Main VI.  While most commands come from the host interface application, the command engine does have the ability to start correctly configured control channels upon reboot and to handle local errors/shutdown cases.  The command engine block diagram is pictured below.

Command Engine Block Diagram

Note: The command queues referenced above are implemented using the Asynchronous Message Communication (AMC) reference library.  

Network Communication

There are two different network connections that occur in the temperature controller application.  The first connection is for sending and receiving messages to and from the host interface application.  The second connection is used for sharing data between the host interface application and the temperature controller application.  Both connections are implemented with the Simple TCP Messaging (STM) reference library.  A high level diagram of these connections is displayed below.

High Level Network Connection Architecture

Messages Connection

As stated above, a network connection is used for sending and receiving messages.

Receiving Messages

The temperature controller application listens for a connection from the host interface application so that messages can be sent and received.  When a connection is made and a new message received, the message is packaged and sent via a queue to the Command Engine (described above) to be acted upon.  If the connection is lost, the application goes back to listening for a connection.  The connection management and message reception is implemented using the Simple TCP Messaging (STM) reference library and message forwarding is implemented using the Asynchronous Message Communication (AMC) reference library.  Its block diagram is displayed below.

Network Comm_Receive Messages Block Diagram

Sending Messages

The sending of messages to the host interface application occurs over the same TCP connection as message reception.  Outgoing messages only come from the Command Engine.  If no connection exists, outgoing messages are discarded.  This functionality is implemented using the STM reference library to handle the TCP connection and the AMC reference library to receive messages from the Command Engine.  Its block diagram is below. 

Network Comm_Send Messages Block Diagram

Data Sharing Connection

As previously mentioned, a central memory table exists in the temperature controller application to make certain items, like IO data, globally available for use in other processes (ie Data Logging and Control engines).  It is often desirable to view this data on the host interface application.  The second connection is used to transfer the current values of the temperature controller application's central memory table to a central memory table residing in the host interface application.  The same also happens in reverse allowing both applications to have the latest values from the other application.  As mentioned above, the CVT reference library is used to implement the central memory tables in both applications.  The CVT Client Communication (CCC) reference library is used to share the central memory table values over the network and between applications.

Temperature Controller Interface_Main VI

The Temperature Controller Interface_Main VI is a host interface application for Temperature Controller_Main VI and provides configuration, deployment and data viewing/retrieval functions.  This VI can be broken up into the two topics; the first being software architecture and the second being how an operator would interact with the application.  

Software Architecture

The software architecture can be broken into two sections: UI Event Handler/Command Engine, and Network Communication.  Similar to above, these sections communicate using queues for messages and a central memory table for data.  Below are two images that show the high level architecture.

High Level Host Interface Architecture

Temperature Controller Interface_Main VI Block Diagram

UI Event Handler/Command Engine

The UI Event Handler/Command Engine is responsible for handling everything related to front panel operations.  This can be updating controls and indicators with new information received from the temperature controller application or responding to button clicks.  This engine is also were all the messages to the temperature controller application originate.  This is because most user interface interactions result in messages that need to be sent to the controller.  The basic architecture is an event driven state machine that uses a queue (via the AMC reference library) to manage the state.  This architecture provides for a centralized location for all temperature controller messages and user interface operations.

UI Event Handler Engine Block Diagram

Network Communication

There are two different network connections that occur in the host interface application.  These are the same connections as the temperature controller application.  The first is for sending and receiving messages and the second is for sharing data between applications.

Messages Connection

As stated above, a network connection is used for sending and receiving messages.

Receiving Messages

The host interface application attempts to establish a connection for sending and receiving messages with the temperature controller application.  When a connection is made and a new message received, the message is packaged and sent via a queue to the UI Event Handler/Command Engine (described above) to be acted upon.  If the connection is lost, the application cleanly exits.  This connection management and message reception is implemented using the Simple TCP Messaging (STM) reference library and while message forwarding is implemented using the Asynchronous Message Communication (AMC) reference library.  Its block diagram is displayed below.

Network Comm_Receive Messages from CompactRIO Block Diagram

Sending Messages

The sending of messages to the temperature controller application occurs over the same TCP connection as message reception.  Outgoing messages only come from the UI Event Handler/Command Engine.  This functionality is implemented using the STM reference library to handle the TCP connection and the AMC reference library to receive messages from the Command Engine.  Its block diagram is below. 

Network Comm_Send Messages from Host Block Diagram

Data Sharing Connection

As discussed above, a second connection is implemented to share central memory table values between applications using the CVT Client Communication (CCC) reference library.  Upon receipt of new data, charts are updated and the control channel statuses are checked for changes.  This happens outside of the UI Event Handler/Command Engine so that getting and displaying data from the temperature controller application is de-coupled from operator interactions.  The CVT Client Communication Engine implements this and is shown below.  

CVT Client Communication (CCC) Engine

User Interactions

While the above sections explain the software architecture of the Temperature Controller Interface_Main VI, it does not explain how the operator interacts with application.  The operator interactions can be broken up into four main sections: Initialization, General Channel Configuration, Setpoint Profile Creation, and System Operation and Status.  These sections all relate to user interface objects such as dialog boxes or front panels.  The later three sections are front panels made viewable by selecting Configuration, Setpoint Profile or Status under the Control Channels tree control.

Initialization

The initialization of the host interface application starts by clearing previous data and prompting the user to enter the IP address of the temperature controller.  This allows the host interface to connect to the temperature controller and retrieve the current configurations, setpoint profiles, and status of the control channels, which are then displayed to the user via the three remaining sections described below.

Target Connection Prompt

General Channel Configuration

The general channel configuration section is where the user can define individual attributes for a control channel like initial setpoint, loop rate, and control type.  There are input and output combo boxes that are automatically populated with the available CompactRIO inputs and outputs (IO).  The Refresh Module button causes the temperature controller application to search for new modules and to reply with an updated CompactRIO IO list.

Once the configuration is set, selecting the Deploy Configuration button transfers the settings to the temperature controller application.  The CompactRIO saves these setting upon reception so they can be loaded upon reboot.  

All general channel configuration changes happen on the fly, which means that you can change which sensor you are controlling on, PID gains, etc. while the Control Engine is running.

Below is the general channel configuration screen, which was made visible by selecting the Configuration text in the Control Channels window.

General Channel Configuration Front Panel Screen

Setpoint Profile Creation

A setpoint profile is a series of actions applied to a control channel setpoint.  The two major actions provided are a ramp and a step/soak.

Ramps

A setpoint ramp is defined by an end setpoint and a duration.  The profile engine residing in the temperature controller application (described above) calculates the ramp slope based on the current setpoint, the end setpoint and the duration.  It updates the setpoint such that this slope is maintained until the desired amount of time has passed.

Steps and Soaks

Steps are defined by a setpoint and a duration.  This can be used at the end of a ramp to create a soak by setting the setpoint value to the value of the ramp end setpoint or it can be used as a step by setting the setpoint value to anything other than the current setpoint.

Combining Ramps and Steps/Soaks

As mentioned above, a setpoint profile is typically a series of ramps and steps/soaks.  Below is a picture of a potential setpoint profile.  Here, the setpoint has an initial soak (step) of 35 degrees, which holds for 10 seconds.  Next, the setpoint is ramped to 40 degrees in 20 seconds followed by another soak at 40 degrees for 30 seconds.  Then, the setpoint has a step down to 35 degrees with a soak of 10 seconds before finally returning to an initial setpoint of 32.5 degrees.

Example Setpoint Profile

The Setpoint Profile Creation screen shown below is made visible by selecting Setpoint Profile in the Control Channels window.

Setpoint Profile Creation Front Panel Screen

This screen allows for the operator to create, edit, save or load a setpoint profile.  It also allows the operator to enable or disable a profile.  There is a field that provides a text summary of the current setpoint profile.  Selecting an item in this field will display the relating parameters in a field to the right.  The profile settings in the temperature controller application aren't updated until the Deploy Profile button is selected.  

The creation or editing of a profile item is initiated by selecting the buttons with a plus sign or a pencil, respectively.  These buttons bring up the following window, which allows the selecting of a profile type and entry of the relating parameters.

Profile Creation/Editing Front Panel Screen

System Operation and Status

Once everything has been configured and deployed, select Status in the Control Channels field to operate the temperature controller application and to view the control channel status.  The front panel displayed below shows this status view screen.

System Operation and Status Front Panel Screen

The Start All button begins all control channels (if they are enabled).  The chart will start updating with setpoint, process variable, and output information about the currently selected control channel.  To stop all the control channels, select the button now labeled Stop All.  To view the data log files that were created, select the Retrieve Data Files.  This will open up a dialog box asking where to save the data files and will FTP the data files on the CompactRIO to the selected local folder.  The data files can then be viewed in Diadem or Microsoft Excel using an add-in (TDM Excel Add-In for Microsoft Excel Download).

Hardware and Software Requirements

Development Software Requirements

• LabVIEW 2009
• LabVIEW 2009 Real Time Module
• NI-RIO 3.2.1
• NI Scan Engine Advanced I/O Access
• Current Value Table (CVT) Reference Library
• CVT Client Communication (CCC) Reference Library
• Asynchronous Message Communication (AMC) Reference Library
• cRIO IO Engine (CIE) Reference Library
• Simple TCP Messaging (STM) Reference Library
• CVT Data Logger (CDL) Reference Library

CompactRIO Software Requirements

The image below shows the software used on the CompactRIO:

This is the minimum software requirement.

Steps to Implement or Execute Code

1. Download the reference application and unzip it into an empty directory.
2. Open the example project named CompactRIO Temperature Controller.
3. Add your CompactRIO target to the project, select Scan Interface as the Programming Mode and copy the contents of the Items to Move folder under the Example CompactRIO target to your system.
4. Add, configure and deploy your CompactRIO IO Modules.
5. Open and run the Temperature Controller_Main VI under your CompactRIO target in the LabVIEW Project.
6. Open and run the Temperature Controller Interface_Main VI under My Computer in the LabVIEW Project.

Additional Information or References

This reference application was created by the NI Systems Engineering group. 

Description-Separate-2

[Fedos]

Where i can download cRIO IO Engine (CIE) Reference Library?