Gated count edges cDAQ-9188 with NI-9402

[_Basil_]

Hi! This discussion is a branch from this one.

Shortly, I want to count random pulses from a photon counter, which emits pulses only when its gate is activated (and this should be done in HW-timed manner), only when the gate is active.

I separated this task in two: to HW-timed emit gate pulses and to count edges when the gate is active. For the second task I created a VI:

could anyone who is more experienced please tell me, if I am doing it in a right manner? I am a little bit confused about how to wire my device: random TTL from the photon counter should go to PFI0 of ctr0 (in NI-9402 this is the 0 pin) and what I generte from the first task (actually, HW-timed gate pulses) then should be wired both to the gate terminal of my counter (left unwired above) and to the gate input of the photon counter... There must be a mistake in this, I guess (otherwise I must split a wire giving my output from the first task and connect it to the PFI1 and to the photon counter gate input).

[John_P1]

The input task should look like one of the following:

The first example using the Pulse Width task will reset the count after every pulse, while the second example using Cnt Edges will not (though if you replace the Pause Trigger with a count reset using the rising edge of the gate signal it will behave like the first).

The "Duplicate Count Prevention" feature is only configurable on older hardware, it is always "On" on the 9188.

Best Regards,

[_Basil_]

Dear John, thank you so much! I tried to implement both approaches (attached), but only one is working (the first, with implicit timing):

With the second I have a trouble, however, it gives me an error -201314: Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal. If you are using an external Sample Clock, ensure that clock signal is within the jitter and voltage level specifications and without glitches. And this is despite that I tried really small sample clock rates:

Additionally, I made a timechart for the first example:

Would you be so kind to tell me, if I uderstood right, that I can loose some counts because of the wire delays? Can I cope somehoe with this? I thought, that the   approcah from the second example could work, but it gives me an error, as I mentioned above.

[John_P1 · Accepted solution]

In your implementation of the second example, you have selected Ctr2Source as the sample clock, instead you should use Ctr2InternalOutput.

The way I read your initial post it sounded as if you wanted to restrict counting during the low time of the gate signal.  However, if the photon counter does not output any pulses during this time, there wouldn't be a need to configure the pause trigger.  Indeed, as you have mentioned it wouldn't be desirable to do this.

To modify the examples I posted to count regardless of the gate status, you can make the following modificaitons:

Example 1:  Change the Pulse Width task to a Period task (and change the corresponding property node as well).

Example 2:  Remove the Pause Trigger.  Change the sample clock to sample on Rising edges.

So now you will be clocking in the samples on each rising edge of the gate signal.  The count will represent the number of photons during the previous gate pulse.  The returned data will be slightly different depending on which approach you take--the sample-clocked version will return a sample on the first rising edge (which should read a count of "0") where the period version will not return this sample.

Best Regards,

[_Basil_]

Dear John, thank you very much for your help! Following your last advice I finally constructed the VI

and checked the statistics of photons coming from the PD in the darkness - it seems to be in agreement with the vendor's datasheet. This is a victory, I think. But there is still one problem: every time I click on the "Stop" button, VI measures twice more doesn't get interrupted immediately. I can understand one additional run, but why two?

Moreover, are there any possibilities to stop it earlier (aqusition time is depending on "Separation" value, which might be up to 10 minutes - it is not that user-friendly to make him waiting for 20 more minutes after pushing "Stop").

I tried several approaches: the most prominent should had been with the pause trigger, but it gives me the error of incompartible settings (against Count Reset, why?).

However, even without count reset but with Pause Trigger it still measures twice more.

I also checked, if another approach we were discussing - with pulse width measurement may help, but it seems to work similarly. Are there any possibilities to interrupt the CI measurement if it is running?

P.S.: Another strange surprise for me is that if the configuration of the Count Reset is changed to "Falling Edge" - measurements don't show any normal results anymore: the amount of photons collected is very small and is distributed weirdly...

[John_P1]

Glad to hear you're closer to getting this working.

---

But there is still one problem: every time I click on the "Stop" button, VI measures twice more doesn't get interrupted immediately. I can understand one additional run, but why two?

---

As it is in your attached VI, the stop button is read from in parallel with the DAQmx Read call.  So stopping the loop might look something like this:

Iteration 1:

Stop button is read (False)

DAQmx Read call is made (blocks for up to 60 sec)

<user presses stop button>

<iteration stops after DAQmx Read call finishes>

Iteration 2:

Stop button is read (True)

DAQmx Read call is made (blocks for up to 60 sec)

<iteration stops after DAQmx Read call finishes--loop exits>

I think the best way around this for you would be to simply configure a lower timeout value (say, 0.1 seconds or something) and handle the timeout error (check the error wire, only write to the data indicator and process the sample in case there is no error, discard the timeout error afterwards so as not to stop your loop or report the timeout--which is now expected--to the user).  

An alternative is to poll for available samples per channel rather than making a blocking read call (or to use the Every N Samples event), but I don't recall if these options will behave correctly on the ethernet chassis (I'm worried that the data will be stuck in the on-board FIFO and not be transferred until the read call is made).

---

P.S.: Another strange surprise for me is that if the configuration of the Count Reset is changed to "Falling Edge" - measurements don't show any normal results anymore: the amount of photons collected is very small and is distributed weirdly...

---

The photon counter only generates pulses when the gate is high, correct?  If you reset the count on the falling edge, you'll be resetting the count right at the end of the window when you might have been generating counts.  The only counts that you will record would be those that occur between the time that the falling edge is seen by the counter input task and the time that the same edge is seen by the photon counter.

Best Regards,

[_Basil_]

Dear John,

if you have some time and desire for further discussions, I attach to this reply some results and corresponding questions regarding of what I have been doing all this time. I would appreciate if you could assess these and continue a discussion.

First of all, I followed your advice: I decreased the timeout for read vi and implemented the error handling (it must be stressed here, that the period of the gate is the value that defines for how long read is blocked, not this value, actually. At least at long gate periods - up to minutes) - see the VI attached.

It works fine, but I am afraid of not handling this error not because of the special case I handle. Do you think, that my concerns are pertinent?

Another issue: in one of your replies you mentioned, that form the first glance my aim was to count pulses from the PD only when the gate is activated. This is actually true, and in the current version we don't do this - in both approaches, either with period measurement or with counter edges, we count PD's pulses all time long, since this is the only way not to loose some pulses because of the wire delays. Am I right that this is the main reason, actually, for blocking the while loop for a long time (I mean, indirectly, - because I have to set this timeout value at read vi to the value which is bigger than the biggest available gate period)?

If yes, then we have to consider a solution with the pause trigger on the falling edge of a third counter, which is synchronized (for example, by sharing a start trigger) with the counter responsible for pulse generation for the PD's gate; moreover, this third counter should be shifted for a value of a wire delays (back and forth from/to the PD). However, when I tried this (see the second attachment) approach, I discovered several surprizes: first, an initial delay of the counter is set to 25 ns despite that I explicitly set is to zero. Second, the pause trigger property conflicts with the count reset property (I received an error at this point).

Would you please be so kind to comment on these strange issues?

[John_P1]

Can you post a screenshot or save it back to LV 2011?

The timeout can be shorter than the gate signal as long as you discard the timeout error.

Best Regards,

[_Basil_]

Dear John,

here it is attached.

[John_P1]

---

I attach to this reply some results and corresponding questions regarding of what I have been doing all this time. I would appreciate if you could assess these and continue a discussion.

---

I assume you're referring to the questions in the comment of your VI.

Why pause trigger doesn't work with count reset?

They use the same internal counter terminal.  You shouldn't need the pause trigger though since the detector is externally gated.

Why do I have not zero, but 25 ns delay even though I've set 0 delay?

There is a minimum delay of 2 timebase ticks.

Can I be sure, that my count reset operation doesn't take time in the moment I put the value of edges counted in a buffer?

You mean that there is some uncertainty whether the count reset happens before or after the sample is taken (given that they are actually the same signal)?  From what I've observed the reset happens after the sample is taken, but I'm not sure if that is in the specs anywhere.  You don't actually need the reset signal if you don't like configuring it this way, you could instead subtract the previous count value from the current count value (if the data is read as U32, then the overflow won't be an issue as long as you don't have over 2^32 counts between samples).

How to calculate a wire delay?

Propagation along a wire should be on the order of 1 ns / foot (the exact rate depends on the properties of the wire and the surrounding dielectric).  Active components (e.g. buffers) will introduce extra delay on the order of several ns.

Why does my application with a shifted counter not work as expected?

You'll have to elaborate, I'm not sure what you mean by this.

---

First of all, I followed your advice: I decreased the timeout for read vi and implemented the error handling (it must be stressed here, that the period of the gate is the value that defines for how long read is blocked, not this value, actually. At least at long gate periods - up to minutes) - see the VI attached.

---

Are you saying that the read blocks for significantly longer than ~0.5 seconds in the program you have attached?  That shouldn't be the case.

---

It works fine, but I am afraid of not handling this error not because of the special case I handle. Do you think, that my concerns are pertinent?

---

-200284 is a read timeout--discarding it should be fine.  I'm not exactly sure what you are worried about (it looks like when the read times out you are correctly ignoring the returned data).

---

Another issue: in one of your replies you mentioned, that form the first glance my aim was to count pulses from the PD only when the gate is activated. This is actually true, and in the current version we don't do this - in both approaches, either with period measurement or with counter edges, we count PD's pulses all time long, since this is the only way not to loose some pulses because of the wire delays. Am I right that this is the main reason, actually, for blocking the while loop for a long time (I mean, indirectly, - because I have to set this timeout value at read vi to the value which is bigger than the biggest available gate period)?

---

I'm not sure I follow--you don't have to set the timeout to a value bigger than the biggest gate period.

Best Regards,