defining multiple triggers to detect individual pulses

[rd100]

Hi,

I have a PXI rack (1042Q) with two 5105 PXI slots.  I want each of the PXI channels to detect a 'random' sequence of voltage pulses that come from each of the anodes of my detector.  I say random in the sense that there is no fixed periodicity (however average count rate is ~1kHz) and each pulse will have varying rise/fall-times, duration and amplitudes (pulses will not overlap though).

To detect and subsequently process each incoming pulse, I want to implement two sequential analogue edge triggers, a rising-edge trigger to identify the beginning of the pulse and a falling-edge trigger to detect the end of the pulse. 

So far it has been trivial to write a LabView vi based on one trigger (say rising-edge) using NI-Scope sub-vi's.  But does anyone know how I can implement the double trigger case?  I have thought of using a flat sequence structure but I haven't seen a close enough example to get me going in the right direction.

So far my vi's have only been written to detect and plot one pulse.  Obviously I will have to implement a loop to continoulsy detect the incoming pulses on all 16 channels.  What constraints does my hardware put on how efficiently I can capture every pulse on every channel? 

Lots of questions too little time

Any help will be most appreciated!

Richard

[dansch]

Hi Richard,

One of the nice features of the 5105 and most of the other digitizers is the ability to perform multi-record acquisitions in hardware, meaning that once the device begins acquisition, it will have a very short re-arm time for the hardware to be prepared to capture the next trigger and acquire another record, without the need for a software loop or any kind of software intervention.

I am curious to know when you detect the rising edge of the pulse, what you are then interested in doing. Are you looking to measure the time of the pulse width by then detecting the falling edge and comparing timestamps, or are you interested in taking samples and being able to see the entire pulse? Or are you just interested in counting the number of pulses that occur? The reason I ask is that each of these could be implemented in a slightly different manner, some easier than others.

Assuming you would like to start sampling on a rising edge and stop taking samples on a falling edge, there is a way to implement this though it is slightly complicated and requires that a digital trigger input be used to start the acquisition (only the reference/stop trigger can be configured on the input channel). The other workaround is always to sample everything and process the data in software to get the exact samples or measurements that you want from the card. Either way, implementing the "double trigger" case is somewhat non-trivial. The best resource for understanding how the digitizer will respond to different events, I would suggest taking a look at the State Diagram found in the High-Speed Digitizers Help under Devices » State Diagrams » SMC-Based Digitizers. It may be somewhat complicated to interpret at first, but based on the details of your application, I can help explain the best method for implementing what you need according to this state model.

Edit: I forgot to mention that one of the big constraints of hardware triggering is that you can only trigger from a single source, whether it be a digital trigger from the single PFI line or an analog channel on a single channel. Even though the pulses will not overlap, you will have to know which channel you want to trigger on next so that you can configure the trigger for that channel appropriately. Even with the method i listed above to use a start trigger and then a reference trigger, you will be limited to only ever measuring pulses from a single channel. If the pulses are coming in at random on the multiple channels, then triggering in hardware is not going to work. In that case, the best option I see would be to continuously acquire and process in software. (Of course, you will be limited in how much data throughput you can handle when doing something like this.)

[zsj]

Hi Daniel, you metioned 'If the pulses are coming in at random on the multiple channels, then triggering in hardware is not going to work. In that case, the best option I see would be to continuously acquire and process in software. (Of course, you will be limited in how much data throughput you can handle when doing something like this.)'  I wonder if the software reference trigger is available in this case.   This means several channels are processed by software to find the trigger condition, the edge for example, and then sendout the software trig.