Counter/Timer
Finite Pulse Train Generation - Exceeding Counter Limits
What's your hw device? Lacking any other info, I'll start by supposing something like a 6602 counter/timer board that has a 80 MHz max timebase and has more than 4 counters onboard.
1. On that device, a finite pulse train will (invisibly) require the use of 2 counters, both the one you program for the output and the adjacent one. The adjacent "helper" counter generates a single pulse which acts like a pause trigger for the output counter. It's the duration of the helper counter pulse that controls the # of pulses generated by the output counter.
So you need to be sure the adjacent counter is available. Based on the error message you're seeing, I'm pretty sure this isn't your problem, but figured I should mention it just in case the adjacent counter is only available by *coincidence* rather than by explicit choice.
2. I would expect (but can't say for sure) that DAQmx would try to use the same timebase for both the output counter and the helper counter. Here that's 80 MHz.
3. An 80 MHz timebase will overflow a 32-bit counter in less than 54 seconds (2^32 / 80e6). Have you seen success with use cases where the master clock runs for a minute or more?
4. It's also possible that DAQmx is smart enough to use the slowest onboard timebase, 100 kHz, for the helper counter. This will overflow a 32-bit counter in just under 12 hours. Perhaps *this* is the breaking point between successful and unsuccessful use cases?
5. I'll suppose for now that the breaking point is ~12 hours. So now the next question is: when a use case lasts for 12+ hours, how *exact* must the # pulses be? In other words, is it conceivable you could live with running your master clock in Continuous mode, and then use software timing to decide when to stop it? You'd need to allow for several seconds worth of uncertainty in your pulse generation duration if you choose this approach. Some of it due to normal software timing uncertainty, most of it due to timing skew between the counter timebase and the real-time clock used to make the software decision.
6. If you *must* have a more nearly exact # of pulses over the course of 12+ hours, you'll need a more complicated approach. Instead of using 2 counters to generate a finite pulsetrain from your master clock you'd need 3. *And* you'll need to manage the finite aspect of pulse generation more manually rather than letting DAQmx do it automatically.
7. You'll configure output counter A for continuous pulse generation and also configure it to be pause-triggered by the single pulse output of "helper" counter B. In turn, counter B will need to derive its pulse timing from a timebase that can be slower than 100 kHz. Let's use counter C to generate that timebase, and when you need 1+ days worth of pulses, let's set it to generate pulses at 5 kHz (that'd give you ~10 days long single pulse from counter B meaning ~10 days of output counter A pulses).
8. Counter A can continue to use the internal 80 MHz timebase for precise output pulse timing. Counter C should be in continuous generation mode and should be started first.
Next you should *commit* Counter B to force its output signal to be in its defined "idle state". (Counter A needs to be configured to pause when Counter B is in idle state.) Next start Counter A, and then finally start Counter B.
So, you can see why it'll be nice if approximate software timing can be "good enough" for use cases >12 hours. 
All this complicated stuff can be used for the general case if necessary, but it's gonna take some work to wring out all the debugging details. In my opinion, the best-case scenario is if your current breaking point is ~12 hours, and longer use cases are not so strict about exact #'s of pulses. Your use of a master clock will *always* guarantee that the other 4 *meaningful* counters start and stop in sync.
-Kevin P
Now THAT is a thorough reply. 😉
@Kevin_Price wrote:
What's your hw device? Lacking any other info, I'll start by supposing something like a 6602 counter/timer board that has a 80 MHz max timebase and has more than 4 counters onboard.
Yes, it's a 6602, and it works fine with lower counts or faster ticking
1. On that device, a finite pulse train will (invisibly) require the use of 2 counters, both the one you program for the output and the adjacent one. The adjacent "helper" counter generates a single pulse which acts like a pause trigger for the output counter. It's the duration of the helper counter pulse that controls the # of pulses generated by the output counter.
So you need to be sure the adjacent counter is available. Based on the error message you're seeing, I'm pretty sure this isn't your problem, but figured I should mention it just in case the adjacent counter is only available by *coincidence* rather than by explicit choice.
Do you know what property would reveal which counter is being used? I am explicitly using counters 0-3 for the signals, and explicitly using 4 for this... so it would have to be ctr5. But how to verify? Maybe not worth the trouble, but nice to know.
3. An 80 MHz timebase will overflow a 32-bit counter in less than 54 seconds (2^32 / 80e6). Have you seen success with use cases where the master clock runs for a minute or more?
Absolutely. I have run it for a couple hours. Playing with the settings, With 1000Hz it tops out at 42,950,000 steps; just under 12 hours
4. It's also possible that DAQmx is smart enough to use the slowest onboard timebase, 100 kHz, for the helper counter. This will overflow a 32-bit counter in just under 12 hours. Perhaps *this* is the breaking point between successful and unsuccessful use cases?
Again... would that be ctr5? I can check it.
5. I'll suppose for now that the breaking point is ~12 hours. So now the next question is: when a use case lasts for 12+ hours, how *exact* must the # pulses be? In other words, is it conceivable you could live with running your master clock in Continuous mode, and then use software timing to decide when to stop it? You'd need to allow for several seconds worth of uncertainty in your pulse generation duration if you choose this approach. Some of it due to normal software timing uncertainty, most of it due to timing skew between the counter timebase and the real-time clock used to make the software decision.
So yeah, it looks like 12 hours; And you are correct... right now the solution is a software timed loop. And this is acceptable for this situation... however I'd like to find a generalized HW solution, since now I have to figure out how to let the operator know when to use either code base. Ugh.
6. If you *must* have a more nearly exact # of pulses over the course of 12+ hours, you'll need a more complicated approach. Instead of using 2 counters to generate a finite pulsetrain from your master clock you'd need 3. *And* you'll need to manage the finite aspect of pulse generation more manually rather than letting DAQmx do it automatically.
7. You'll configure output counter A for continuous pulse generation and also configure it to be pause-triggered by the single pulse output of "helper" counter B. In turn, counter B will need to derive its pulse timing from a timebase that can be slower than 100 kHz. Let's use counter C to generate that timebase, and when you need 1+ days worth of pulses, let's set it to generate pulses at 5 kHz (that'd give you ~10 days long single pulse from counter B meaning ~10 days of output counter A pulses).
8. Counter A can continue to use the internal 80 MHz timebase for precise output pulse timing. Counter C should be in continuous generation mode and should be started first.
Next you should *commit* Counter B to force its output signal to be in its defined "idle state". (Counter A needs to be configured to pause when Counter B is in idle state.) Next start Counter A, and then finally start Counter B.
So, you can see why it'll be nice if approximate software timing can be "good enough" for use cases >12 hours.
OK, I'll code that out to wrap my head around it. Sounds straighforward. thank you!
-Kevin P
