Software Triggering, Part 6

Software triggering can allow intelligent decisions about when to capture meaningful data, without any intervention from the host system. But there are times when only the host system knows when it is appropriate to measure.

Or go back to start at page 1 of Software Triggering.

Host-Triggered Measurement

In most data acquisition systems, the software triggering is just a slow means for activating hardware triggering across a host interface bus. With a Data Acquisition Processor board, the same kind of triggering is available, and it remains slow. The bus interface is fast, but it has unpredictable setup delays. There is nothing that can be done about this.

For example, suppose that the purpose of a test is to measure how well shielding material protects against hard impacts.

Application configuration for impact test

There is no point in collecting impact data until the firing mechanism is ready for release. The PC host could activate the release mechanism and at the same time tell the Data Acquisition Processor to expect the event. The problem is, the signals to the release mechanism and to the DAP take different hardware signal paths, and the operating system delays for delivering the messages on each channel are unpredictable.

Suppose that the following timing constraints apply:

The setup delay to send a new message to the Data Acquisition Processor is 0 to 25 milliseconds.
The setup delay in signalling the release mechanism is 0 to 25 milliseconds.
The time delay to reach impact is 5 milliseconds.
The impact event finishes in 10 milliseconds.
The sampling rate is 1000000 samples per second.

The following diagram illustrates the two most extreme cases for timing.

In the first case, the Data Acquisition Processor receives its notification almost immediately, while the release mechanism message is delayed 25 milliseconds. The DAP will not start to see any meaningful data until 30 milliseconds later. In the second case, the release mechanism receives its message 25 milliseconds ahead of the DAP, and the entire experiment is completed 10 milliseconds before the DAP is notified.

To make sure that the DAP captures all of the data in the case that its notification arrives late, it should retain data starting 20 milliseconds before its notification time. To make sure that the DAP captures all of the data in the case that its notification is early, it should continue to retain data until 40 milliseconds after the notification. The total data collection interval is 60 milliseconds, and 60000 samples are collected.

Converting Messages to Events

Related
Test and validate data acquisition configurations independent of your software application.

A message is easily transferred from PC host software into the Data Acquisition Processor using pre-defined communication pipe $Binin . In the following application coding example, the DAP_outhandle variable points to the $Binin pipe, and the transfer value is taken from the arbitrary buffer – in this case, a 2-byte integer variable. The value doesn't matter. It is the transfer that signals the external event.

  DapBufferPut( DAP_outhandle, 2, &arbitrary );

When this number reaches the Data Acquisition Processor, an event is constructed in the software trigger T_PCevent using the PCASSERT command.

  PCASSERT( $Binin, T_PCevent )

The PCASSERT command solves the problem of determining the position in a data stream when the input data come from an external source. It assigns an event position based on the current sample count of the sampling process.

For the impact test example, after the trigger event is posted, a WAIT command can be applied in the DAPL configuration as usual, preserving 20000 samples before the event and 40000 samples after the event.

  WAIT( IPipe0, T_PCevent, 20000, 40000, $Binout )

Extensions

In the example, a captured data set will include 60000 samples, of which only 10000 are relevant. The rest allow for the uncertainties in PC host timing. Intelligently isolating relevant data is the specialty of software triggering. The fact that the selected data came from a triggering process doesn't matter. You could apply an additional LIMIT and WAIT command pair as described in previous sections to isolate the relevant parts.

An alternative solution is to let the DAP detect the impact event by testing a data channel in the usual manner. To prevent extraneous triggering events between experiments, use the TRIGARM command to disable triggering until the next experiment is ready.

This concludes the series on software triggering, but hardly exhausts all of the possibilities. Some additional topics covered in the manuals but not covered here include:

logic to coordinate and merge event sequences from multiple sources
using software triggering on multiple slaved boards
custom programming of trigger processing commands

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

A Data Acquisition Processor board can be an excellent platform for technologies and techniques beyond the scope of this article. Take a look at other data acquisition and control techniques. Or take DAPstudio out for a spin.