03-11-2010 01:56 AM
03-11-2010 11:34 AM
I only program counters from LabVIEW, but I'm pretty sure that what you want to do isn't possible.
I wouldn't call it a limitation of the hardware, it's more in the concept of the different types of
measurement.
Measurements like pulse widths and periods will latch their values into the hardware register on active
edges of the signal being measured. This will likely happen at an unpredictable and variable rate,
otherwise, why measure?
Measurements like event counting will latch their values into the hardware register on active edges
of the sample clock. This should happen at a known and constant rate so you can interpret that
# of edges as a rate.
Here's what I'd do to correlate the two measurements in time:
1. Config both tasks to start off a common "arm start" trigger.
2. Measure semi-periods instead of pulse widths. The cumulative total time of the semi-periods
gives you "time since trigger." You won't be able to figure out this cumulative total if you only
measure pulse widths. So measure semi-periods, even if your app doesn't want to care about
half that data.
3. Do event counting at a constant sample rate. Then (sample #) / (sample rate) gives you "time
since trigger."
-Kevin P