Software Triggering | |||||||||||
Home | DAQ Techniques | Download as a PDF | View as one page<< Previous 1 2 3 4 5 6 Next >> Software Triggering, Part 4This page considers how you can use software triggering as an event detector to control acquisition on many data channels. This is perhaps the most common application of software triggering. Or go back to start at page 1 of Software Triggering. Multiple Channel Acquisition with TriggeringThe application is a vehicle crash test. You will observe data for stress, buckling, and fractures at 100 sensor locations on an instrumented vehicle – and in a fraction of a second it is all over. You have just one chance to capture the measurements. There is too much data to collect it all continuously, but you cannot afford to miss any relevant data or risk drowning your system with irrelevant data before the crash event has occurred. Suppose that you are using a DAP 5400a/627, sampling 8 channels simultaneously, with each of the 100 channels sampled at each 100 microsecond interval. During an experiment covering 0.5 seconds, you will collect about 4 million samples. The host interface can transfer about 2.5 million samples under ideal circumstances. Depending on what your application processing does with the data, you might be able to move perhaps 1 million samples into your application software during the event. The other 3 million samples are captured and buffered on the DAP, and sent when the host software is able to accept them. Reliable Triggering
A high-speed transient glitch propagating along a sensor wire could easily set off an electronic triggering circuit. A glitch of that kind would not be persistent. The real signals of a crash event would be very different. When using software triggering, you can combine processing with triggering, so that real events are distinguished from the meaningless noise glitches. Suppose you select one of the microphone channels that
will respond to early contact, and connect it to signal
channel On the other hand, you don't want a single "spike" to prematurely trigger. You can use a running average with a short time window to smooth out noise spikes. To trigger, the signal must reach the triggering level and stay there for a few samples. The following configuration cancels DC offsets, smoothes out spikes, and triggers when the signal level deviates from the baseline level consistently through a window of 7 samples. pipes pDCoff word, pCleaned word pipes pDiff trigger tCrashEvent ... pdefine CrashCapture raverage(IPipe0, 400, pDCoff) raverage(IPipe0, 7, pCleaned) pDiff = pCleaned - pDCoff ... Now you can trigger reliably on the processed Limit( pDiff, OUTSIDE, -20000, 20000, tCrashEvent ) ... Accounting for Many ChannelsThe crash is detected on just one channel, but data are collected in many channels. As we saw in Part 3, the position of the data in a triggering channel must be used to determine the associated position of the data in channels where data are taken. The ... Wait(IP(0..99), tCrashEvent, 12000, 4000000, $Binout) end All examples so far have shown the measurement process terminating after recording a known, fixed number of samples. The next part will show an example where intelligent triggering is also used to terminate the sampling when the number of samples cannot be known in advance. << Previous 1 2 3 4 5 6 Next >> View as one page |