<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=305105&amp;fmt=gif">
Industry: Energy
Application: NI LabView, Control and Data Acquisition


Genuen Challenge - Blue 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.


Genuen - Solution 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.

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. Genuen (formerly WTI) helped develop the controller and unit health monitoring system for the nominally rated 250 kW net power EPS250TDEMO heat engine (Figure 1). The initial unit is expected to be operational at one of the premier national utility providers in the United States in 2010.

Heat EngineFigure 1


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 2). 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.

heat engine 2Figure 2


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

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.


Data Archiving 

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. This was easily accomplished with the FTP VIs included in the LabVIEW Internet Toolkit. In addition, 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.



Real-Time Module, Modbus Library for LabVIEW, LabVIEW, Internet Toolkit, cRIO-9114, FPGA Module, NI 9476, NI 9219, NI 9265, NI 9203, NI 9213, NI 9144, NI 9426, PID and Fuzzy Logic, NI 9208


Ready to Get Started?

Learn more about our products or request a consultation with an experienced engineer.