Chuck,
Looking over your vi and considering default values for Gate and Trigger specs, it looks like you're using rising edges of Ctr3 to be both the Gating signal (aka "sampling clock" in DAQmx) and the Trigger signal. I see two possible problems:
1. When the same edge of the same signal acts as both the trigger and the gate, there may be a race condition. You might buffer your first value at the same instant as the trigger (give or take some nanoseconds) or you may buffer it one cycle later. In your case, with a pulsetrain of 1000 Hz, that's exactly 1 msec. I suppose in theory that the behavior could be different for each of the two buffered counters, race conditions being indeterminate and all.
Now, I actually don't think this is the cause of your immediate problem, but it could come back to get you sometime. So I would recommend using the falling edge as a trigger signal if you want the rising edge to be the gate.
2. Very likely, the main problem is that your Ctr3 pulsetrain is started and running before your buffered counters are started. As your code executes, one of your buffered counters is started just before the other. It may well see a trigger and gate before the code to start the other counter can run.
This problem would go away if you start Ctr3
after starting the two buffered counters.
Good luck!
-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.
