Data Acquisition (DAQ) and Control from Microstar Laboratories

Software Triggering

data acquisition filtering data acquisition software channel architecture enclosures services

Home | DAQ Techniques | Download as a PDF | View as one page

<< Previous 1 2 3 4 5 6 Next >>

smart data acquisition icon

Input Triggering & Timing

Software Triggering, Part 1

This begins a six-part article on software triggering. First, the basics: what is it, and when does it matter to you?

Triggering: When Is It Time to Measure?

Some measurements can be taken pretty much any time, and it isn't terribly important when you start and stop. For example, if you are measuring the size of an object, it will be roughly the same size regardless of when you measure it. But not all measurement applications are like this.

data acquisition hardware board
Software triggering is provided as part of the support package for every DAP.

For some applications, the phenomenon you need to measure is not always present. Until it is, there is no point in recording measurements. These are examples.

  • Chemical reactions. When a reagent is added to a solution, things start to happen. Mix the chemicals first and then start measuring, you miss measuring the important initial phase of the reaction. Start measuring first and then mix the chemicals, and you collect lots of extraneous measurements before the relevant data.
  • Synchronizing events. The power stroke of a engine follows firing events. Measuring just any old time, you are equally likely to measure a fuel injection cycle instead of a firing cycle.
  • One-time or rare events. There is little point in collecting and sorting through masses of data where nothing happens.

Background: Hardware Triggering

Though this series is about software triggering, it is helpful to contrast it with hardware triggering, which is simpler, more familiar, and more limited.

If you have just the right digital electronic signal, you can use it to start (and sometimes to stop) data collection. This kind of hardware control of the measurement process is called hardware triggering.

Hardware triggering
Hardware triggering

If you don't have an appropriate digital signal, hardware triggering becomes more complicated. Some data acquisition products provide a voltage comparator amplifier for converting an analog signal into a digital form, which might be sufficient.

Pre-Event Data and Buffering

To record data before an event occurs, you need two things: 1) sampling that occurs whether or not events occur and 2) memory to record past measurements just in case they are needed.

Preserving data requires memory. Hardware-based schemes typically use a circular buffer configuration. In concept, special addressing logic selects memory locations for new measurements sequentially, advancing around a circle. By recovering stored values from the circular buffer, you can obtain measurements preceding the time of an event.

When an event signal arrives, the hardware records the address of the most recent sample value, placing this address in a special event register. Also, the hardware informs the host of the event, to let it know that it had better do something – fast!

Circular buffer scheme
Circular buffering scheme

Actual memory addresses are not circular, rather they are linear up to some maximum, at which point there is a sudden "address wrap around" to zero. Hardware devices typically leave the host software with the burden of tracking the wrapping behavior and dynamically unwrapping it to select stored values.

The circular buffer scheme is highly dependent on software to respond to signals for events, determine how to address the data, and fetch data across the data bus into host memory. There is a race condition, and any delay in responding to the hardware event signal results in overwriting and loss of some of the buffered data.

Software Triggering

Rather than using hardware circuits to determine when to measure, it is tempting to configure a software program and let it determine when to measure. This is the idea behind "software triggering."

Software triggering leads to a kind of "chicken or egg" paradox. You don't want the measurements captured until you trigger; but there is no point in triggering until you know you want the measurements!

Most data acquisition software that claims to support "software triggering" merely initiates the triggering action using a software command. This leaves you with the decision about when to issue this command – back to the "chicken or egg" paradox. Without seeing the data, how can you know whether you want to trigger or not?

The DAPL system breaks the paradox much as hardware circular buffering does. Measurement activity is started well in advance of capturing data. Past data are retained in memory buffers, and the DAPL system manages the data memory. You don't need to worry about how, and you don't need to worry about data locations. Unused data are automatically released to make storage available for new data. The buffering is completely automatic, and can expand to the limits of available memory as needed. There is never a race condition, and new data can never overwrite old data despite any delays that might occur.

The principal advantage of the DAPL software triggering is that you can analyze data and detect events intelligently, directly in buffer memory. All of this takes place on the Data Acquisition Processor board, without transferring anything to the host PC. This doesn't eliminate the need to scan through masses of data looking for events, but it avoids overloading your host with intense data transfers and computations when there is nothing of interest.

For detecting and reporting events, the DAPL system keeps a streaming record of event locations in a queuing mechanism called a trigger pipe. You can extract the information about events in much the same way that you would read from a data stream.

Software triggering scheme
Software triggering scheme

There is one drawback to software triggering. A trigger event determines the location of interesting data in a continuing stream of data, but does not initiate responsive action. There remains a time lag until the event is processed. If you need fast real-time response, software triggering is probably not the right tool for the job.

In part 2 of this series, we show how you can add software triggering to an application with a few DAPL configuration lines.

<< Previous 1 2 3 4 5 6 Next >> View as one page

dap 5200a