Controlling an Echogen Power Systems Waste Heat Engine with NI Software and Hardware

  Read in   |   Print Print

"We selected the CompactRIO real–time controller based on the need for tight I/O synchronization."

- Darryn R. La Zar, Wineman Technology Inc.

The Challenge:
Developing a real–time application for controlling and monitoring an Echogen Power Systems heat engine and a Windows OS application for remote and local monitoring of the health and operational data of the overall system.

The Solution:
Developing a custom NI LabVIEW application to control the Echogen Power Systems EPS250TDEMO waste heat engine using the NI CompactRIO platform to provide deterministic system control with multiple proportional integral derivative (PID) control loops, and configuring the system to collect data from a variety of sensor inputs as well as numerous analog and digital I/O.

Darryn R. La Zar - Wineman Technology Inc.

The EPS250TDEMO waste heat engine, a proprietary system developed by Echogen Power Systems, can recover thermal energy from a variety of sources and is primarily targeted to recover industrial waste heat. The EPS250TDEMO heat engine uses supercritical carbon dioxide, either alone or in combination with other working fluids, to create a power-generating cycle. This technology is significantly more efficient because it generates power at the point of use. Another advantage of the system is that by not transferring power over long distances, it eliminates transmission loss and reduces carbon emissions. NI Gold Alliance Partner Wineman Technology Inc. helped develop the controller and unit health monitoring system for the nominally rated 250 kW net power EPS250TDEMO heat engine (Figure 2). The initial unit is expected to be operational at one of the premier national utility providers in the United States in 2010.

Figure 2: The Echogen Power Systems EPS250TDEMO Heat Engine during the Development and Build Phases on the Factory Floor

The patent-pending EPS250TDEMO heat engine is comprised of five primary components: heat exchangers, working fluids, pumps, an expansion device, and a generator, which allow it to uniquely produce power from a range of thermal sources. The working fluid is pumped around a closed loop via the primary system pump. A heat exchanger adds thermal energy to the working fluid before the fluid is introduced to the expansion device, which converts the energy in the working fluid into electrical energy by way of the generator. Additional heat exchangers condense the fluid before returning it to the system pump and recycle heat within the system.

We selected the CompactRIO real–time controller based on the need for tight I/O synchronization. The EPS250TDEMO is a unit primarily designed for testing; system requirements include acquiring data from more than 75 sensors and controlling more than 40 devices through Modbus, analog, and digital signals. Additionally, we used multiple PIDs to control the system based on various readings including system pressure, fluid heat, system mass, flow, and turbine load at different locations within the system.

Additional requirements include monitoring more than 50 digital feedback signals; monitoring, logging, and taking action on 90 process alarms; logging data for more than 150 signals; data archiving; manual control; Modbus communication to a variable frequency drive (VFD); mass flow sensor and turbine load control; monitoring from remote locations; and performing real-time computations of more than 25 process parameters.

LabVIEW Applications for a Windows OS

We architected the system to run remotely, but designed a human machine interface (HMI) for local control and monitoring. We developed a Windows application so an operator can interface with the thermal engine controller from a PC with a network connection. With the HMI for this application, the user can view the current status and acquired signals from the controller and set user input variables. The HMI also provides manual control of the heat engine (Figure 3).

Figure 3: The Automatic and Manual Control User Interface Screen for the Echogen Power Systems EPS250TDEMO Heat Engine Developed Using LabVIEW 2009

In addition, we developed a second Windows application to remotely view data taken from the real-time controller. The HMI for this application consists of a multitabbed interface that properly groups readings by similar channels and controls. We implemented network-published shared variables for process data communication (sharing data) and message-based communication (sending commands) across the Ethernet connection between the controller and the Windows PCs running the custom LabVIEW applications. The use of the shared-variable engine running on the real-time controller greatly reduced our development time.

LabVIEW Real-Time Application

The LabVIEW Real-Time application running on the CompactRIO controller consists of multiple core processes including command process, control logic, PID control, field-programmable gate array (FPGA) communication, Modbus communication, limit checking, data logging, and data archiving.

Command Process

A network-published shared variable with enabled buffering creates a first-in, first-out (FIFO) and is used as the transport layer for the commands from the HMI to the controller. By incorporating the relevant data with the command, we can provide parameter coherency to the command and avoid race conditions. The command received from the host is passed to the control logic loop via a queue.

Control Logic and PID Control

Using a state-machine-based architecture, we designed an extensible and manageable procedure for handling automatic startup, controlled and emergency shutdown, and manual operation. Stepping through the control logic is driven from the queue fed in the command process loop, and the current system state is passed up to the Windows HMI for display.

Using the LabVIEW PID and Fuzzy Logic Toolkit, we easily controlled more than five PIDs simultaneously. The PID control parameters are loaded dynamically from a configuration file maintained by Echogen through another custom LabVIEW configuration application.

FPGA Communication

For signals requiring sample times greater than 1 kHz, we used the FPGA to acquire the data and stream it to the real-time controller via direct memory access (DMA). Additionally, we used the FPGA as a coprocessor to analyze complex signals while freeing up the real-time processor for other critical threads. For signals not requiring fast sample rates, we used NI Scan Engine, which saved significant development time because the majority of signals were able to use NI Scan Engine. CompactRIO hybrid mode gave us the advantage of fast FPGA acquisition rates and fast NI Scan Engine development time.

Modbus Communication

Using the NI Modbus Library for LabVIEW, we easily communicated with our customer’s external devices. The acquired Modbus data was passed to the control logic and data-logging loops via single-process shared variables with real-time FIFO buffers.

Limit Checking

We limit checked each monitored I/O alias against multiple user-definable ranges maintained with the configuration application. Each range had a corresponding user-defined action ranging in severity. When a limit was exceeded, the appropriate action was sent to the control logic loop for processing. Because the I/O alias contains all the scaling information, the user was able to define the limits in engineering units. Additionally, by using the I/O aliases, physical devices could be changed within the system without having to modify the code.

Data Logging and Archiving

All monitored and calculated data is written to a file created at the beginning of every day. By having a piece of code that automatically closes the existing file and creates a new one at a user-defined rate, the user can access the previously written files before the application completes. All previously created data files are zipped and transferred via FTP to a remote server for analysis, storage, and/or writing to an SQL server. Using this archiving method minimized hard disk usage.

Leveraging the Power of NI Technology

To access the data read and written in various loops throughout the application, we used single-process shared variables with real-time FIFOs. The single-process shared variable was a cleaner and simpler solution than managing real-time FIFO references. Using the NI Distributed System Manager during development gave us a central location for monitoring systems on the network, managing published data, and accessing network-published shared variables and I/O variables without needing a custom LabVIEW application. Also, we can write to network-published variables to remotely tune and adjust process settings without the explicit need for a dedicated user interface. Lastly, with the NI toolkits and modules, we quickly adapted the system to our customer’s evolving requirements.

Author Information:
Darryn R. La Zar
Wineman Technology Inc.

Bookmark and Share

Explore the NI Developer Community

Discover and collaborate on the latest example code and tutorials with a worldwide community of engineers and scientists.

‌Check‌ out‌ the‌ NI‌ Community

Who is National Instruments?

National Instruments provides a graphical system design platform for test, control, and embedded design applications that is transforming the way engineers and scientists design, prototype, and deploy systems.

‌Learn‌ more‌ about‌ NI