Looking to help, but think we need to back up a couple steps first. Let's try to get clarity on some low-level building block counter concepts, much like learning vocabulary and grammar as a start toward learning a language. And like real-world languages, there can be synonyms where more than one bit of terminology has the same meaning and there can be other cases where the same term has different meaning in different contexts.
Counters really are a little different than the other kinds of DAQ this way. Several things they can do aren't analogous to any of the other DAQ types (AI, DI, AO, DO).
In the hardware, a counter can respond to multiple input signals. (For simplicity, I'm going to ignore the special quadrature encoder mode for now). One such input is known as the Source and its edges cause the count register value to change by 1. It typically increments, but can be configured to decrement instead. When you see the term Timebase Source, it means almost the same thing but it's a little farther upstream from the counter. When you define a Timebase Source, you have the option to divide it down before it reaches the counter Source pin.
Another input at the hardware level is called the Gate, and its purpose relates to control over the counting process. The most intuitive thing it can do is to act as level-sensitive AND gate to either pass or block the Source signal before reaching the counter. It can also act as an edge-sensitive signal that samples the count value, much like a Sample Clock. It can also act as an edge-sensitive trigger (triggered or retriggerable pulse generation) or reset mechanism (freq or period measurement).
Under DAQmx, the term Gate doesn't get much visibility. On the one hand, this prevents the confusion arising from having one term that carries very different meanings depending on the context of the counter's operating mode. On the other hand, it prevents the deeper understanding of equivalency that helps counters solve problems in non-intuitive ways.
A typical binning operation would send a fixed frequency clock to the Gate pin to act as a Sample Clock. The photon pulses would go to the Source and cause the count register value to increment. Each Sample Clock edge would sample and buffer the instantaneous count register value, and the count would keep incrementing without reset. You might then post-process these cumulative counts with a simple finite difference to see how many *new* counts were accumulated in each time bin.
The code in msg #8 goes one better by making sure the count resets and counts from 0 within each individual bin. It does so by exploiting the equivalency I referred to. It's kinda non-intuitive, but it works just fine.
In msg #8, the counter is put into period measurement mode. The intuitive way to use period measurement mode is to feed a known fixed rate clock to the Source and an unknown or variable rate pulse signal to the Gate (here known as the "Period Terminal"). Each edge at the Gate ("Period Terminal") samples the count register value and resets the count back to 0. So each sample represents the # of fixed-rate edges seen at the Source since the last edge at the Gate. That # easily translates into a measurement of the period of the unknown signal. It's literally the # of Source edges seen between consecutive Gate edges.
So now msg #8 exploits that knowledge to interchange the signals. It still sets up Period measurement. And that's still going to measure # Source edges between consecutive Gate edges. Only now, the unknown signal is fed to the Source while the fixed rate clock is sent to the Gate. Now each "period" is a measure of the # of pulses of the unknown signal seen within a fixed interval of time. Those intervals *ARE* the bins, and the integer count values are the # photons per inividual bin.
Down at the hardware, there's almost nothing different between this and the simplest kind of edge-counting (except that in period measurement mode, the count value resets each time it's sampled). Back in the old legacy driver, the way you configured these things in software made this equivalency much clearer (though it had a steeper learning curve). Under DAQmx, the terminology used to configure these things looks quite different though. The same kind of thing is happening down in the guts of the hardware, but the config method kinda conceals that.
The purpose of the 2nd counter is solely to generate the fixed-rate clock needed by the 1st counter. If you have an accurate external TTL clock signal, you could use that and not need the 2nd counter at all. (I tend to like using the 2nd counter if I can spare it b/c I then have programmatic control over the clock signal, which is often useful.)
Counters can be tricky to get the hang of, but they're also very flexible and that's what makes them pretty cool too. There's a lot of info here and other places to absorb. It probably won't sink in all at once. That's ok, you're kinda learning a language here. Build tomorrow on what you learn today.
-Kevin P
P.S. Here's another old msg I posted in the early days of DAQmx. It has largely the same purpose as this one, but is worded a bit differently. In case that wording is more helpful...
ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
