Software Triggering | |||||||||||
Home | DAQ Techniques | Download as a PDF | View as one page<< Previous 1 2 3 4 5 6 Next >>
Software Triggering, Part 1This 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.
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.
Background: Hardware TriggeringThough 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.
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 BufferingTo 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!
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 TriggeringRather 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
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 |