Short answer: quite possibly, you can't.
Longer answer: the source of this problem is a combo of the tiny 2-sample FIFO on the 6602 and the use of the shared-access PXI bus. You're running into a PC system limitation. About all you can hope to do is find ways to reduce other usage of the PXI bus while this task runs, but even that may not end up helping enough to prevent the error.
The best solution would be to use a newer DAQ device with a DAQ-STC3 timing chip (such as the PXIe-6612, or any PXIe-63xx X-series multifunction device). These would give you a much bigger FIFO and dedicated access to on a faster bus.
Alternately, you can try the suggestion in the error text to divide the signal to create a lower frequency, then scale it back up. This will limit your measurement resolution, but that's likely to be a better tradeoff than a fatal error that prevents you from getting any measurement at all.
An easy way to divide by 4 or more is to set up a continuous counter pulse train using the external signal as the "timebase source". Define the pulses in units of "Ticks" and set Low, High, and Initial Delay (just to get in a good habit) to at least 2 each. The sum of Low + High will be the integer division factor.
Use a different counter to measure the frequency of that first counter's output, then scale by the sum of Low + High to calculate the original frequency.
-Kevin P
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
