How to use multiple counters in the 6602 to measure cycle length, calculate delay and generate triggered pulse.

[Dave DeFily]

Hi,

I need to measure the cycle length of a pulse, calculate a delay based on this value, and then generate a triggered pulse with that delay value. The input and output pulses will be continuous. The best case would be to use the cycle length from one pulse in the calculated delay for the next pulse. One of my biggest problems has been getting the calculated delay value into the pulse specs.vi for the triggered output.

This output pulse will be used to trigger an IMAQ video acquisition; therefore, the solution to this problem will be part of a larger video acquisition application. This has posed a problem, in that accessing the counters has interfe
red with the triggered video acquisition.

Any suggestion will be welcome.
Thanks

Dave

[Filipe A.]

Dave;

The main problem with that setup is that, as you will need to do some opeartions in Software (to calculate the new delay at each new cycle time), you might have some overhead (delay in the trigger pulse generation) inserted by the Software operation.
I don't have enough information about your application, but the ideal situation would be to do all the operation in hardware if possible.
Regards
Filipe

[Dave DeFily]

Filipe,

The overhead is the problem I'm trying to get around.

Specifically, what I need to do is to generate an output pulse after a trigger pulse, which is a given percentage of the cycle length. The input pulse is from heart rate, so it will have some variance, and the output pulse will be at a stationary point in the cardiac cycle. For example, for an input pulse of 2 Hz (500 ms) the user would likely request the output pulse be delayed by 75%. Therefore, the generated pulse will have a 375ms delay after the trigger.

In the past I have had hardware built to do this, but I am hoping I can accomplish the same thing with multiple counters on the 6602. I have been able to accomplish this with 3 counters (2 to measure period and 1 for output
) but the overhead prevents adequate triggering of the IMAQ video acquisition. I am hoping another method would solve this problem.
Thanks
Dave