Yes you can do this with a counter, provided you have unidirectional motion. Given your mention of 10000 RPM, that seems like a pretty safe assumption.
Here's how:
1. Configure a continuous pulse train using "Ticks" as the units.
2. Set the "Initial Delay" value to correspond to the desired angular position for the rising edge of your TTL output pulse (relative to the Z-index pulse)
3. Set the High Ticks value to be >=2. Set the Low Ticks value to be (1024 - High Ticks)
4. Configure a Start Trigger to make your pulse train trigger off the Z-index pulse.
What happens:
5. The task triggers on the next Z-index pulse
6. The first pulse starts after <Initial Delay> worth of encoder edges come in
7. The pulse lasts for <High Ticks> worth of encoder edges
8. The task then waits for <Low Ticks> worth of encoder edges before starting the next pulse, thus placing it at the same angular position as the previous pulse
9. Steps 7 and 8 keep repeating as long as you run your app in the presence of unidirectional encoder motion
Notes:
10. You're only using 1 channel of your encoder for this. My numbers above assume 1024 cycles for each encoder channel. If instead you only have 256 cycles per channel (for an overall quadrature resolving power of 1024 positions per rev), you'll need to substitute 256 for 1024 in the calc for Low Ticks
11. The Initial Delay is set one time only before starting the task. It can't be changed on the fly. If you need to change the pulse position, you'll need to stop the task to be allowed to reconfigure it. While stopped for re-configuration, you'll be missing many revs worth of opportunities to fire your TTL pulse. You'll need to decide whether this means that you should stop the motion of your machinery first (to avoid such misses).
-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.
