Quite a few of the key vi's I see (buffer, Gate, source, Read) are not NI's built-in calls so it's impossible to be certain what they do. However, based on the symptoms you describe, I have a strong hunch that most of the issue (very possibly all of it) has to do with the "Read" calls.
You describe a symptom where 2 of the 3 counters' values start in sync with the 3rd being delayed a bit. Then this situation changes over time. That does not sound like a hardware-sync kind of problem. That sounds like a software flaw in reading the acquisition buffers.
It is definitely correct to start the 3 source-counting tasks BEFORE starting the gate-generating task. After that, you should make sure you read the SAME # of samples from each of the 3 counting tasks. Unless explicitly programmed otherwise, by default this will always keep reading the earliest buffered data that hasn't already been read before. HOWEVER, I've got a lurking suspicion that the custom "Read" function just might not do the default thing. I notice that there's an output value which goes to a shift register to be used as an input value to the "Read" function on the next iteration. This has the look of a NON-default way to read from the acquisition buffer where the shift register value is a cumulative index where the last buffer read left off, and where the next one should start.
In other words, it kinda looks like the "Read" function might be based on a non-default user-software-based management of the index into the acquisition buffer. And if the user software doesn't manage the index properly, the data will appear out of sync. The hardware would still be buffering data in sync, but the way the software reads and accumulates it doesn't maintain the order.
One simple thing to check just in case -- make sure all those shift register wires are connected to the appropriate input and output terminals of the "Read" functions. All 3 look similar, so if only 2 of them maintain sync I wonder whether one of those wires is not actually connected to one of the "Read" output terminals. Maybe the "Read" function icon just sits on top of the wire without being properly connected to it?
Finally, "backlog" usually would tell you how many samples are in the acquisition buffer that you haven't yet read. You don't want to see that number keep growing and growing, and you should expect the backlog value for all 3 count tasks to be approximately equal each pass through the loop, though it may vary from one iteration to the next.
-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.
