Power Quality Reference Application

Publish Date: Mar 13, 2014 | 0 Ratings | 0.00 out of 5 | Print | Submit your review


The Power Quality Reference Application provides an extendible framework for cRIO embedded applications focused towards electrical power monitoring. The reference application monitors a single 3 phase circuit and reports the results via DNP3 over Ethernet. It will also record the time domain voltage and current signals at the specific time intervals. This reference application is a guide to be followed and extended to shorten development time. As such, not all features that would be expected in a completed application are included. Notable exceptions include dynamic configuration settings (either from file or over the network) and network communications other than DNP3 (i.e. TCP/IP or web service).

Table of Contents



Below is a list of the minimum software requirements for the application:

LabVIEW 2012


LabVIEW Real-Time 2012

Electrical Power Suite 2012

DNP3 Software for LabVIEW 2.0

Free Reuse Library:

NI Asynchronous Message Communication (AMC)

Included Libraries:

*Event Logger Library (ELL)

*Software Watchdog


Back to Top


Below is a list of the hardware used in the project.

Note: For the latest NI CompactRIO chassis see ni.com/compactrio and for the latest high voltage input modules see NI 9242 and NI 9244

NI CompactRIO 9074

NI 9225

NI 9227


Back to Top


The reference application uses a Hub-and-Spoke messaging architecture which means that all messages pass through the Controller who can decide where to route the message next.  There are two main advantages to this approach:

  1. Decouples sender and receiver which makes the individual processes more modular and allows for greater reuse.
  2. Reduces complexity since each process can only communicate with the controller (as opposed to each process being able to communicate with every other process).

There is cost with the extra routing and you may find this is not the best fit for your specific application.


Back to Top


The LabVIEW project is organized with folders for each individual process while the top-level VI (Main_RT.vi) directly under the cRIO target.  There is also a build specification for the RT exe which is set to run at Startup.  The FPGA portion of the project is setup exactly like the examples for the Electrical Power Suite.


The reference application leverages some existing libraries in order to create the framework.  All of the messages between the processes are sent or received via the AMC library which uses LabVIEW queues to transmit data.  The Software Watchdog library is a library which monitors each process to make sure that they are operating as expected.  If a process ever takes too long (i.e. gets hung), the Software Watchdog will catch it and attempt to force the process to stop.  Refer to the Watchdog section for more information.  The Event Logger Library writes application log information to disk.  The types of events which can be logged are defined by the application owner but common examples include errors, startup, shutdown, and trigger events.

In the Hub-and-Spoke architecture, the controller represents the “Hub”.  All of the messages come in and out of the controller.  The controller also is in charge of starting up all of the other services as well as shutting them down.  The controller should be the only process with access to the messaging queues to all of the other processes.  The controller also includes a few miscellaneous system level functions such as checking the CPU and memory usage and writing any outstanding events to disk.  These functions occur at defined intervals.  Make sure that any functionality that is added to the controller does not take too much time as this will add latency to the message routing and could cause your system to lag.

PQ Acquire

The PQ_Acquire process reads the voltage and current data from the FPGA DMA FIFO.  The configuration and reading of the FPGA is based on the Electrical Power Suite (EPS) examples.  For more information on the EPS VIs, refer to the context help and the associated examples.  The PQ_Acquire process is a message interrupted state machine.  This means that it listens for messages from the controller and if there is no message, then it proceeds to its next state.  The typical sequence of the states is Configure->Start->Read (repeating)->Stop.  The data is stored in a DVR which is then sent back to the controller.

PQ Analysis

PQ_Analysis is a message driven process in that it remains idle until it is told to do something.  The controller will forward any newly acquired data to the PQ_Analysis process.  The analysis will obtain the time domain from the DVRs and perform the electrical power analysis on it.  Refer to the Electrical Power Suite help and examples for more information on the analysis being performed.  The measurement results are bundled together with the time domain data and sent back to the controller.


DNP is also a message driven process.  The controller forwards this process all new analysis results.  These results are formatted into a specific DNP3 point map and then updated.  The specific point used in this application is documented in the “DNP Point List.docx” included with this code.


Trigger determines when a trigger event occurs.  The trigger is evaluated based on the timestamp of the time domain data or a force trigger from a user.  The time based trigger is configured with a CRON string and by default is setup to generate an event every 15 minutes.  Refer to Wikipedia for more information on CRON strings.


Blink provides the user with an indication of the state of the application.  It supports two blink modes (normal and error) which can be set from the controller.


Timer calls back processes that have registered a message with the Timer at specified intervals.  This is used by the controller to dictate when the “CheckSystemHealth” occurs.


Watchdog is a fail-safe process used to make sure that each of the other processes are executing at expected intervals.  If a process does not execute within the software watchdog timeout period, then the system will attempt a graceful shutdown.  If one or more processes does not respond to the graceful shutdown, then the Watchdog process will proactively reboot the system.  The HW watchdog is enabled on the system to make sure that the system can recover even if the Watchdog process stops responding.

Creating a New Process

Follow the steps below for adding a new process to the application:

  1. Open the “Process Template.lvlib” file and save the library with the name of the new process that you want to create.  Let’s assume the new process name is “WebService”.
  2. Open the newly created “WebService.lvlib”.  Right-click on the library and select “Properties” and change the Icon for the library.
  3. Open the Qnames.ctl and change the labels for the strings to be something more representative.  In this case, we’ll change “Own Qname” to “WebService” and “Other Qname” to “Controller”.
  4. Add the new queue name to the Controller.lvlib:Qnames.ctl for WebService.
  5. In the Controller.lvlib:Process.vi, obtain a reference to the WebService queue and wire it to the case structure.  Go to the “Exit” case and add the queue reference to the Build Array function of all the queues to send the “Exit” command to.  This will ensure that the WebService process shuts down nicely.
  6. Edit the InitalizeSystem.vi to create the new WebService Qnames.ctl and populate the new name in Controller Qnames.ctl.
  7. Add any new messages for WebService that need to come from the Controller.  These can be configuration messages or messages with data that needs to be updated and so on.

Download the reference application


Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No