This article will be of interest to anyone doing hardware testing using a data acquisition device. It is not specific to engine dyno testing. I started the Open Dyno project last year. The goal of the project was to develop a freely available control system that is capable of performing an unmanned automatic test of a device. The term test in this case refers to performing some sequence of operations on a physical piece of hardware. In my particular case, the devices being tested are internal combustion engines. The Open Dyno control system could be used to test any type of hardware or component with some simple modifications to a couple of dialogs. It could even be used as a substitute in some PLC applications. The control system runs at a default rate of 100Hz and has a calculation engine and alarm system that execute at the same rate. This is typical of most commercial applications that are used for the same purpose. Some well known commercial applications with a similar purpose are NI Test Stand / Veristand, Horiba ADACS/Stars, AVL Open Puma, D2T Morphee.
The project originated from a masters thesis project that I completed in 2011 (not in computer science). The original work started as a hobby project while researching how to create a video game (somehow the video game morphed into this project!). A lot of the concepts came from previous work that I have done programming PLCs and HMIs. Although this project is not anywhere near the level of a commercial application, it does provide a good starting point to work from. The most likely end user for this project would be a university lab, a hobbyist project, or someone looking for an inexpensive way to retrofit an old engine test cell. The first version of this application from my masters thesis is currently being used in a commercial application running 24x7. One of the key benefits of the Open Dyno control system is that nearly every part of it can be modified while the system is running. This includes all the scripts, points, alarms and HMI screens. The only things that can't be modified were specifically designed that way for safety reasons.
This is the first article in a series that I intend to write about the Open Dyno project. It is written in a format that is intended to introduce what the control system is and what it is capable of doing. I will focus the material in the future articles to match any interest expressed from this introductory article. I also have a website named Open Dyno that has some additional material available. A lot of the code is already located on SourceForge. My current goal is to publish the following sequence of articles on CodeProject within the next few months. Some of the material will probably include excerpts and images from my thesis. The list may change or be reordered. I haven't started any of the remaining articles yet.
- Introduction to the Open Dyno Real Time Control System (this article)
- Open Dyno Configuration Manager
- Open Dyno Real Time Controller
- Open Dyno Visualization and HMI
- Data Viewing and Analysis
- Laboratory Dashboard Website
The Open Dyno project is a work in progress. A lot of the work is completed, but like many projects a lot of the work still remains. The basic operation of the control system is functional and an offline simulator is available that can be used to develop a working control system. In order for the applications to be truly useful, a data acquisition device is required. Some knowledge of how to collect data from the device is also needed. I prefer to use devices that can be distributed using a field bus or Ethernet communication of some kind. Some examples of devices that I have used are NI 9144 cRIO EtherCAT chassis
, United Electronics Ethernet PowerDNA
, Sensoray 2600 Ethernet devices
, and many CAN bus devices. I have no relation or ties with any of the companies mentioned. All of them have their own pros and cons.
The Open Dyno control system is a generic application that collects physical measurement data and acts upon it. Some examples of measurements could include engine speed, torque, and temperatures. It can be used to control a process using a PID loop. Or simply turn on a light in response to a switch. It has a fairly sophisticated test designer that can be used to develop a complex sequence of test steps. As well as full data logging ability. Using engine testing as an example, the following simple test sequence could be defined and executed by the system.
- Start engine (Turn on ignition power)
- Set engine coolant temperature to 195 Degrees F (PID setpoint)
- Set engine speed to 1000RPM and throttle position to 15% (Commands to dyno controller)
- Set engine torque to 250Nm (PID setpoint)
Each step typically lasts for a specific amount of time but could be limited by some other condition. The minimum step time is 10ms even if a value of 0 is entered. It is also possible to jump from one step to another. This is all specified using the test editor which is shown below. The test editor contains a few fields for setpoints that are directly related to engine testing. The rest of the dialog is useful for any kind of testing. All of the data that is entered for the test is passed through a code generator that outputs an Angelscript code file. Each data field on the form can contain a numeric value, point name, or even valid C++ code. The generated test script can then be executed by the real time control application.
The software design is separated into three broad applications. The applications are an input/output data collector, real time control application, and a
graphical user interface (GUI). The data collectors are used to capture data
from a data acquisition device and can be written in any language.
Typically the data collector would be written in C/C++ or LabVIEW so that it is possible to run in real time. The real
time control application is written in C++ and is designed to run on
Linux with the PREEMPT_RT patch installed. It can also be executed on
Windows if real time is not a requirement. The Open Dyno Simulator application runs entirely on Windows. The GUI is written in C# 4.0 using the Windows Forms library. It currently uses
National Instruments Measurement Studio for some gauges and graphs. It
also uses a syntax highlighter and intelli-sense control from Quantum
Whale for the human machine interface (HMI). These two items could be removed or replaced as required. I personally think the cost of both items is more than worth the time they saved me. An alternative HMI using the Qt framework is also
being developed for those who prefer to stay completely open source. Both of the HMIs feature a runtime screen designer with scripting abilities. The HMI screen designs are stored in an XML file along with all of the script code.
applications communicate with each other using Ethernet UDP datagrams and ZeroMQ. It is
therefore possible to host each application on a different computer and
operating system. Typically two computers are used much like a PLC and
HMI would work together. The real time control application could even
run on an embedded device such as the BeagleBone or UDOO. The HMI could be used without the real time control application to communicate with a custom piece of hardware such as an Arduino.
The work that I have done on Open Dyno is licensed under the MIT license. I have made use of many amazing open source libraries that all come with their own licenses. I have also used the information contained in a number of articles on Code Project during development. Some of the open source projects used include:
- Angelscript (Andreas Jönsson - Modified Zlib License
- muParser (Ingo Berg) - MIT License
- Poco Project (Günter Obiltschnig) - Boost License
- CS-Script (Oleg Shilo) - CS-Script License
- SQLite (Dwayne Richard Hipp) - Public Domain
- ZeroMQ (iMatix Corporation) - LGPL
The Open Dyno Simulator
To get an idea of what this project is all about and what its potential is, I developed a simulator that runs on Windows. In order to run the simulator, you need to have the .NET Framework 4.0 installed. The simulator consists of four applications. The real time control application is called OpenDyno.exe and is the heart of the system. It is a text based console application which is shown below. It is the first application that should be started.
The real time application is a configuration based system. All of the configuration is stored in a single SQLite database named katerina.db3. The name of the database is for historical reasons. The name of the first generation of this control system was called Katerina. The OpenDynoConfiguration.exe application is used to manage all of the configuration details. The configuration application has a multiple document interface with a bunch of forms used to modify data in the database. This application also contains the test editor which was shown previously. Below is a screenshot of the main window.
Configuration consists of defining the following items:
- Points - Calculated numerical values
- Alarms - Used for monitoring safe conditions
- Tests - Sequence of operations to be performed
- Scripts - Scripts are used to control non sequential operations (test cell control)
- Datalogs - Lists of points to write to data logs
All of the user interaction with the real time control system is done using the OpenDynoVisualize.exe application. Visualization provides the communication link to the real time application. It also contains two top level dialog windows for managing the execution of a test and monitoring alarms. These windows are displayed below. The test manager contains a few items that are related to engine dyno testing but for the most part the dialogs are generic.
The Visualization application also launches the final application called OpenDynoScreen.exe. This is a general purpose HMI with a run time dynamically modifiable screen. The run time design feature is needed since the operator will often need to perform actions that could not be known ahead of time. Any number of screens can be opened at one time. The Screen application has two modes of operation. In edit mode, new controls can be added or modified as needed. Because of the nature of the system, all of the controls are operational even in edit mode. It would be undesirable to be in edit mode and not be able to have full control of a unit under test. The other mode is run or locked mode. In run mode, none of the controls can be modified. The image below shows the screen application with a number of controls displayed. Each control can either display or update a point in the real time application. The points each control uses are configured by drag and drop operations from a point list. The original concept for the movable controls on the screen came from the article Customs Windows Panel by Alireza Soleimani.
The screen is stored as an XML file which is displayed below. The XML can be edited directly and then reloaded if mass text replacement is required. This is also useful if your preference is to work with text rather than using a mouse. Storing the screen as an XML file makes it easy to identify modifications using a diff application.
The screen has the ability to execute a C# script using the CS-Scripting engine from Oleg Shilo. The current method of calling a script is by assigning the name of a function to a button control. This could easily be extended to include many other scripting abilities. An example of a hello world script is shown below. Any valid C# code could be used in the screen.
The source code for the script can be modified and reloaded without reloading the entire screen. This is extremely useful during screen design. All of the compilation is done dynamically using the functionality of the CS-Script engine. The source code is stored in the XML file for the screen. This was done to keep all of the data in a single file. It helps when copying a screen from one computer to another. The same thing is done for any images that are stored as part of the screen. Although the screen has the ability to use scripts, it is not required for any of the HMI controls included.
Running a Test
The procedure used to load and run one of the sample tests will be illustrated below. The following steps assume that both OpenDyno.exe and OpenDynoVisualize.exe are both running.
- Select a test. This loads a test into local memory.
- Choose the PowerTest from the Test Browser.
- Start the test. This processes all of the test information though the code generator and creates a script file named script.as. The script.as file is then loaded into the real time application and compiled.
- Reset the Step and Step Time to 0. The reset step and step time dialog is always displayed when starting a test. This operation would only be performed when starting a new test. If changes are made to a test sequence and then reloaded, the No button should be selected to continue from the current test position.
- Run the test by clicking the Run button. This starts the test by setting the Step counter to 1. With a Step value greater than zero automatic test functions will be called.
- At this point, the test is running but put into hold by the actual test sequence. Notice that the Step is now 1 in the dialog below. Setting a test to Hold from the test sequence is done so that the operator can check to make sure everything is functioning correctly before continuing.
- Click Run again and then Continue Test. Clicking Run while a test is on hold will display a continue test tab with options for how the test should continue. In this case, it should simply continue from the current position. It is also possible to continue with a new step or step time.
The test is now executing in fully automatic mode which is indicated by a green Run button. The Test Time is decremented from its original value of 30 seconds. A number of messages are also displayed to show the status of the test. These messages are part of the test sequence.
Points of Interest
The Open Dyno control system is slowly progressing into a useful application. I'm still in the process of completing the real time application. It is currently functional but missing the communication code to accept data from the data collectors. The GUI applications are all functional but could contain bugs. Please report any bugs if you try the software. I'm sure there are a lot of features that could be added or modified as well. I am going to start writing the other articles in the series. My intention is to document how the application works as well as identify the issues that I had and any places where I could use some help. I've learned a lot of programming concepts while working on this project. I'm hoping to learn a lot more and extend the system further.
The first version of this software which was called Katerina has been running 24x7 for many years now. The Open Dyno project uses many of the same concepts so I believe it will function equally as well. I will discuss more details of the performance metrics of the system as the articles progress. Currently, I am able to process all of the real time calculations in the sub millisecond range on a Core I7 2.8GHz machine. CPU usage is typically in the 1-2% range or even less depending on the number of calculations. This performance is on par or better than many of the commercial applications that I have used for the same purpose.
- Initial release April 4 2014