Gated count edges cDAQ-9188 with NI-9402

[_Basil_]

---

You shouldn't need the pause trigger though since the detector is externally gated.

---

I used to think, that the CountEdges task is kinda "inactive" when pause trigger is on. This means, that if I'd use a falling edge of a gate signal (internal output of the counter for a gate) as a PauseTrigger source for the CountEdges task and the same signal (but the rising edge) as a CountReset, I could had counted almost everything, that I need, but not bothering system to count edges between the states with a gate opened. I assumed, that in such case, if a user would push a Stop button, he would then wait for not more than a time the gate is opened (which is then a gate width (max 100 ms); in the current versions he should wait for two gate periods (max 10 min)).

The additional problem is then, that even if all this would be true, we would loose some photons because of wire delays (we "pin" our CountReset and PauseTrigger to the internal output, so we disregard 2 x wire delay to/from the PD). That's why I thought of the third counter for CountReset, which would be shifted relative to the PDGate by the wire delay  and synchronized (in terms of counter start) with the PDGate counter (and my last question you had obvious troubles to comment on was about this vi I forgot to attach, I am sorry - it was not working as expected).

Anyways, I tested pause trigger without count reset and realized, that it doesn't decrease time of waiting. This is the thing I should had done first, not the last.

---

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).

---

Unfortunately, I have finally to stream my data to TDMS file and as far as I know reading and writing from/in the same one drastically decreases the performance of the logging.

---

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. 

---

Would you be so kind to explain why CountReset and Sampling is the same signal? Actually, I thought, that these are two different processes and they can overlay in time with a conflict or whatever. I am a little bit confused with when exactly in case of SampleClock the data is transferred to a chassis' buffer.

---

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.

---

Thank you for this answer!

---

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's not the case, it was more about the previous version: read is blocking max for 1min there, but in order to have no error of the read timeout I must have increased it up to 10 minutes according to the separration beteen opened gates.

---

-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). 

---

I am worried that now I can't know if I had this error for whatever another reason. I mean, I took an error of timout and disregarded it, after all. What if I had it not because of the controllable situation (in my case such controllable situation is to ask the buffer with no samples)? What if another reason can lead to the same error and I will just disregard it? It somehow resembles using a zero timeout in event structure - what if you have a real timeout for a longer times? This is a ittle bit hard to explain, but I hope that this error can happen only if we have a read timeout.

---

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

---

I do have if I don't want to implement this error handling I am mistically afraid of. Anyways, now I think there is no reason for this - thank you for your kind help and patience!