I think the answer is probably. However, you can't do it with hardware timing from the acq. board. You'll need to depend on software reprogramming, which means that at best, you may be able to change the delay time before *most* of the input triggers.
Method:
1. Configure counter for "Retriggerable Pulse Generation", but you probably already know this.
2. Detect when first pulse has been generated after its delay has expired. Poll "Counter Get Attribute.vi" for "output state" (or maybe "TC reached" -- I'm not at my acq. PC to test it right now) until you detect the transition.
3. Call "Counter Set Attribute.vi" with "pulse spec 1" as the Attribute ID, and your new delay value (in timebase cycles) as the Attribute Value Number.
4. Call "Counter Control
.vi" with "switch cycle" as the action.
5. Hopefully, you got all that done before the next input trigger! If not, I *think* the pulse will still be generated, but based on the prior delay value.
6. My multi-year running gripe with NI on counter/timer functionality: When oh when will NI-DAQ support the ability to generate buffered pulsetrains where the delay and/or pulsewidth can change for every cycle?
The output equivalent of buffered semi-period input measurements would be *very* helpful. Then I could capture a pulse timing pattern observed on a full-up prototype unit and *re-create it* as a stimulus in a controlled lab environment. The same sort of thing we've been able to do with analog i/o for years. It's a very real and obvious hole in functionality for the 6602, a device that is otherwise quite impressive.
End of gripe.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
