Lost trigger in specific conditions

[Danny_res]

Hi all, 

I lost a trigger in my configuration using Ni 660X cards as a trigger generator and counters

I have a trigger pulse generator configured to raise a pulse rain with the follow configuration.

SampPerChan = 7502

HighTime = 0.029990625

LowTime = 2.5E-6

The counters (5), have been configured as Buffered Pulse With Measurement and 7502 as a samples per channel.

The point is that with the previous configuration the counters takes 7501 counts instead 7502, I have counted the triggers with a oscilloscope and the triggers as expected (7502).

If I change the samples per channel to 10000 for example, the setups works fine.

Any Idea?

thanks!

[Kevin_Price]

I want to make sure I understand the details first.

It sounds like you've confirmed with a scope that you generate the specified # of pulses (7502).

You've got 5 counters doing buffered pulse width measurement.   On a 660x device, at least 2 will need to be configured to use interrupts rather than DMA.   I assume you've got that in place already as well.

It isn't clear what you're measuring the pulse width *of*.   Are you measuring the pulse widths of the constant-width pulse train you're generating?   Are all 5 counters doing this same measurement?

It also isn't clear how you are sequencing the task starts and whether there's any kind of further triggering signal involved.  If the pulse generation task starts before the pulse width measurement task,  it's no surprise if you miss *at least* 1 measurement.

What other details can you provide to fill in the blanks?

-Kevin P

[Danny_res]

First of all, Thanks!!

---

@Kevin_Price I want to make sure I understand the details first.

It sounds like you've confirmed with a scope that you generate the specified # of pulses (7502).

---

All the counter are configures as "Interrupts"

---

@Kevin_Price

You've got 5 counters doing buffered pulse width measurement.   On a 660x device, at least 2 will need to be configured to use interrupts rather than DMA.   I assume you've got that in place already as well.

---

All the counters are doing the same measurements, I'm counting photons while a Gate signals is in High state, buffering the counts at every Gate received.

---

@Kevin_Price

It also isn't clear how you are sequencing the task starts and whether there's any kind of further triggering signal involved.  If the pulse generation task starts before the pulse width measurement task,  it's no surprise if you miss *at least* 1 measurement.

---

Of course, counters tasks are started before the pulse generation task, there aren't any kind of further triggering signal involved.

The procedure is basic, Start the counter in buffered pulse width measurement mode, the sources are photons, and the counter counts photos while the Gate signa is in high state, buffering the value and waiting to the next Gate signal.

The point is that if I use 7501 sample per channel instead 7502 the system works fine, if I expect 7502 the counters lost one trigger.

Thanks for your help!

[Danny_res]

First of all, Thanks!!

 I want to make sure I understand the details first.

It sounds like you've confirmed with a scope that you generate the specified # of pulses (7502).

All the counter are configures as "Interrupts"

You've got 5 counters doing buffered pulse width measurement.   On a 660x device, at least 2 will need to be configured to use interrupts rather than DMA.   I assume you've got that in place already as well.

All the counters are doing the same measurements, I'm counting photons while a Gate signals is in High state, buffering the counts at every Gate received.

It also isn't clear how you are sequencing the task starts and whether there's any kind of further triggering signal involved.  If the pulse generation task starts before the pulse width measurement task,  it's no surprise if you miss *at least* 1 measurement.

Of course, counters tasks are started before the pulse generation task, there aren't any kind of further triggering signal involved.

The procedure is basic, Start the counter in buffered pulse width measurement mode, the sources are photons, and the counter counts photos while the Gate signa is in high state, buffering the value and waiting to the next Gate signal.

The point is that if I use 7501 sample per channel instead 7502 the system works fine, if I expect 7502 the counters lost one trigger.

Thanks for your help!

[Danny_res]

First of all, Thanks!!

I have confirmed with a scope that all the pulses are generated (7502) and all the counter are configures as "Interrupts".

All the counters are doing the same measurements, I'm counting photons while a Gate signals is in High state, buffering the counts at every Gate received.

The counters tasks are started before the pulse generation task and there aren't any kind of further triggering signal involved.

The procedure is basic, Start the counter in buffered pulse width measurement mode, the sources are photons, and the counter counts photos while the Gate signa is in high state, buffering the value and waiting to the next Gate signal.

The point is that if I use 7501 sample per channel instead 7502 the system works fine, if I expect 7502 the counters lost one trigger.

Thanks for your help!

[Kevin_Price]

Do you explicitly try to read 7502 samples or do you use the convention for Finite Sampling that you request -1 (which means the entire buffer full, presumably also 7502 samples)? 

Do you also get a timeout error when only 7501 samples are returned?   

Have you observed other magic #'s of samples that return 1 less than expected?  Any kind of odd/even/power of 2 pattern?

Something I'd experiment with is setting either the generation *or* measurement tasks to Continuous sampling and explicitly requesting 7502 samples.  (As long as either the input *or* the output is a Finite sampling task, you can limit the # samples that get buffered.)

Another thing might be to look into "Duplicate Count Prevention".   There's a deep-down DAQmx property that lets you set it on or off.  Try it both ways, I can never totally remember how to interpret the meaning of the phrase.  (See also here if doing text-language programming.)

-Kevin P

[Danny_res]

Do you explicitly try to read 7502 samples or do you use the convention for Finite Sampling that you request -1 (which means the entire buffer full, presumably also 7502 samples)? 

I'm explicitly generating 7502 gates and explicitly taking 7502 samples in the counters using finite sampling task.

Do you also get a timeout error when only 7501 samples are returned?   

No, the Tasks are waiting triggers to finalize the 7502 samples, the counters are waiting with 7501 samples in the buffer.

Have you observed other magic #'s of samples that return 1 less than expected?  Any kind of odd/even/power of 2 pattern?

Nop, this is the magic number that I have found, and it is incredible because we are using this cards for many years ago without any problem but now on use this magic number 7502 we have found this strange behavior... I'm trying to find some kind of pattern with this number unsuccessfully.

Something I'd experiment with is setting either the generation *or* measurement tasks to Continuous sampling and explicitly requesting 7502 samples. (As long as either the input *or* the output is a Finite sampling task, you can limit the # samples that get buffered.)

I'm limiting the samples that get buffered to 7502 in the counters...

Another thing might be to look into "Duplicate Count Prevention".   There's a deep-down DAQmx property that lets you set it on or off.  Try it both ways, I can never totally remember how to interpret the meaning of the phrase.  (See also here if doing text-language programming.)

Mmm, I will investigate about this ...

Thanks @Kevin_Price