I see one likely problem and one potential one, depending on your config settings.
First the potential one. As posted, your front panel defaults set up "count reset" on a rising edge. If you reset on the rising edge of the detector signal and *also* latch & sample on that same rising edge, you might find yourself with a circuit-based race condition.
I'm wary of using the same edge to perform 2 functions if I care which of those 2 things happens nanoseconds before the other. Here you should. You want the count value to latch *before* it gets reset, so I'd recommend resetting on the falling edge of the detector pulse.
Now the likely one. In your reading loop, you seem to be requesting a specific # samples from each of 2 counter tasks. Well one of your detectors is almost certainly going to take longer than the other to register the specified #. After the faster one returns values and you're waiting on the slower one, new data will continue to build up in the task buffer of the faster one. Sooner or later, you're likely to end up with a buffer overflow error.
There are different ways to avoid this. The simplest code mod would be to request the magic # of samples: (-1). In a continuous sampling task, this will retrieve all the samples available at that moment without any waiting. You'll get different #'s from each task, but you won't be at risk of the buffer overflow. If you do this, you should add a msec Wait timer to your loop to give your CPU some breathing room. 100 msec per read iteration is a pretty good place to start.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
