Trigger TTL at specific encoder position using DAQ counters

[PaskalM]

Hello,

I am not a beginner in LabVIEW, but I often struggle when working with new aspects of DAQ I/O.

Currently, I am trying to generate a TTL pulse at a precise angular position using an encoder (1024 PPR). My DAQ has several counters, and I am able to read the encoder counts over a revolution. I also have access to the Z pulse to reset the count each revolution.

For my application, I need to generate an output pulse at a user-defined count value, corresponding to a specific angular position of a motor rotating at high speed (up to 10,000 RPM).

From my research, I understand that I should use hardware-timed operations (counters) rather than software timing in a loop, especially given the high RPM and required precision. However, I am not sure how to implement this in practice.

Does anyone have experience with a similar setup or could point me to relevant examples or documentation?

Thank you,

[santo_13]

Based on my limited research, you may be able to achieve it using the Counter Output Event. Set the counter start value to be n counts less than the max value of the counter, so when your encoder reaches the desired position, the counter will rollover to 0, causing the Counter Output Event.

Using the Counter Output Event Property in NI-DAQmx - NI

[Kevin_Price]

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

[PaskalM]

The unidirectional motion assumption is indeed valid.

Stopping the task to change the initial delay is not a problem at all.

I tried your configuration and reached the stage shown in the picture below (also attached in the VI to this post). However, I am unsure about a few aspects:

Regarding step 4:

---

4. Configure a Start Trigger to make your pulse train trigger off the Z-index pulse.

---

Is this correctly implemented in my VI?

Also, on which port of my DAQ is this TTL pulse generated? Since I am using Ctr0, does the signal come out of the Ctr0 OUT terminal (PFI 12)?

Thank you !

[Kevin_Price]

---

Is this correctly implemented in my VI?

---

No.  As well as several other things.  Since a picture's worth a thousand words, try the attached version I made instead.

-Kevin P

[PaskalM]

Thank you very much!

I was indeed heading in the wrong direction.

I am now able to generate a TTL pulse and visualize it on my oscilloscope. However, I suspect there is still a synchronization issue that I am not sure how to resolve.

I have attached a video showing both the Z-pulse signal from the encoder (in yellow) and the generated TTL output (in blue).

It appears that the blue signal is out of phase with the yellow one, and this effect seems more pronounced at lower RPM.

I recorded videos at both 500 RPM and 2000 RPM, but due to file size limitations, I can only attach one video to this post. Here is the 500 RPM video attached

[PaskalM]

And  here is the 2000 RPM video attached

[Kevin_Price]

1. Are you using the code I posted without any changes to the block diagram?

2. Are you *absolutely* sure you are using the right value for "Enc Ticks per Rev"?   From the video, it pretty much appears that each scope screen refresh makes the apparent phase shift the same amount.  Each scope refresh only shows you a tiny time slice, then there's a (very likely) fixed delay until the next refresh.

    If you total "Enc Ticks per Rev" value is not *exactly* equal to what the encoder actually produces, a pattern of regular phase shifting would occur.  And because the two different speeds would accomplish more revs between scope refreshes, the amount of phase shift would vary with speed.

So that's my suspicion at this point -- your "Enc Ticks per Rev" value doesn't match what the encoder is actually putting out.

-Kevin P