How to Get Started with Derived Channels in LabVIEW

How to Get Started with Derived Channels in LabVIEW

Your system has all the hardware to measure all your signals. Now how do you get measurements from relative channels, such as a Rosette strain measurement, which are dependent on three physical channels? Is there a way to measure cumulative volume or even a delta pressure? These formulas vary by the test, so how can you create a dynamic calculator to get these results in real time? Typically, these channels are calculated in post processing.

Derived or calculated channels perform calculations on the fly from other physical channels. For large-channel-count systems, this is vital. The calculations can be as simple as applying a scale and offset or as complex as performing calculations of multiple channels, such as delta calculations or Rosetta strain gauge measurements. You need to be able to edit these formulas at test time so you can measure real test data. This allows the derived channels to be “measured” at the same time as the “real” data on the same time base, especially when instruments have different time bases.

A tag engine or Current Value Table (CVT) is important to use when calculating because the current value is the only value needed. There are many ways to incorporate a CVT, including some off-the-shelf toolkits. The “calculator” – at its most basic level – needs to reference the current value for all necessary channels. This is challenging because sometimes the channels have different sample rates. Often constants such as R, V0, or Initial Temperature are needed; however, these are only updated in the CVT once at the beginning of the test.

One way to get these calculations is by using a little-known library in LabVIEW called G Math. The basic front panel is shown below with a simple formula that adds the previous value and the current volume. The G Math VIs can’t handle spaces and I didn’t want to limit the end user with naming restrictions, so I chose to enclose the names with brackets, like [User Defined Name]. I then created a parser that strips these names down so the G Math VIs will work. Here is an example of the code:

blank blank

 The first parser takes the names of the variables, which are defined within brackets “[User Defined Name]” and changes them to a simple name like “a”, “b”, “c”. The other VIs are native to LabVIEW and parse the formula and evaluate the formula respectively. The X Values come from the CVT for the channels needed for the formula. Ideally the parsing of the variables and formula should be done at the beginning of the test and not at every iteration. The Value returned here should then be written to the CVT.

You can edit this formula before a test to reflect the current hardware setup and it doesn’t require a rewrite of the software.

Additional methods for performing calculations are listed below.


When defining the channels in the system configuration they need to include the following:

  • Calculation type or name
  • Required channels (channels to read)
  • Required channels for publish (i.e. need to wait for new data on all these channels before publishing, constants and initial values shouldn’t prevent the channel from publishing)

When setting up the channels, you should consider circular dependency: where A depends on B, and B depends on C, and C depends on A. In some ways this can be advantageous. For example, if you want the previous value (n-1), you can reference yourself. The order of channels to update can also lead to reading “old” data.

When designing the Calculation VIs, standardize on a common connector pane so that different methods and calculations can be performed. This could easily convert to LabVIEW classes.

Another tip when working a large channel count system is to create channel groups. These groups can be defined in a text file or in a central database and can then be called to display on a single graph or table. 

Once you have integrated the derived channels into your data acquisition, you can have the system make decisions or set alarms based on the results at run time. This also greatly simplifies post processing, saving you valuable test time.

Learn more about how to ensure your high-channel-count systems are designed to be highly configurable and easy to integrate with other systems in your facility in our latest white paper, Three Must-Have Features for High-Channel-Count Test Systems.

Latest Posts


Automated Test System for SunPower

G Systems, known for their expertise in test system development, was granted the task to help SunPower develop a solar power automated test system to test new printed circuit boards (PCBs). Through this project, G Systems aided in the increase of production line accuracy, reliability, and efficiency, all while decreasing costs to SunPower.