Reading encoder data and determining the RPM

[Abbishek94]

Kevin,

The motion is unidirectional and hence I can use the TTL signals from one of the channels. But if the frequency of the TTL signals is varying, it would mean that the camera would capture the images at different angles as well. Right?

Also, if we are using the X1 encoding, I can use the previous program and send the TTL pulses synchronized with the encoder acquisition as well right? 

I had another question as well. Can the use of a digital filter in labview reduce the noise from the encoder and hence some of these quantization errors?

Abbishek

[Kevin_Price]

We're getting close now, I can feel it.  😁

RPM comes from distance/time.  Yes the encoder pulse frequency will vary some, but it's because the *time* intervals vary.  The physical angular distance between pulses is fixed and constant (plus or minus "real world" tolerances).  Whatever speed you go, however much it varies, each pulse represents the same incremental distance of motion.

I suspect the previous program isn't quite the right thing to use any more.  That one generated a constant rate clock to drive both your encoder capture and frame grab.  I'm *now* suggesting you use the encoder itself as a *variable* rate clock to drive your frame grabs.

As I said before, if you *need* to capture encoder position in sync with the frame grabs, then you'd just specify the same encoder signal as the sample clock 'source' in the call to DAQmx Timing for your encoder task.  Make a reasonable guess for the 'rate' input, but if anything, err on the side of overestimating.  Note also that you'd no longer need a pulse train generation task.

No, a digital filter will not reduce quantization errors.  If anything, it might increase them.  What digital filters do is suppress pulses whose duration is below a specified threshold.  Short pulses are blocked, preventing the counter task from reacting to them.  And if pulses get suppressed, the nominal # of counter reactions goes down and the % error from quantization goes up.

Speaking of quantization, once you use the encoder to drive your equidistant frame grabs, is there really any more purpose to measuring RPM or worrying about quantization?  You know the nominal RPM and you also know that it's pretty smooth but not perfect.  Is it really value-added to go any further?

Using the encoder pulses as a clock means you no longer have hardware-precise timing information available.  There are ways to add it, but do you really *need* to?

-Kevin P

[Abbishek94]

Kevin,

Thank you for the clarification.

With respect to the RPM, if this is the smoothest we can get without any more processing or coding, then I will have to go with it.

However, for using encoder pulses, the problem is I need to send the pulses to the camera as well as a light source, and the light source needs a specific pulse width to operate properly. In the previous program, I was able to set that with the help of duty cycle and the frequency. If the same can be done with this method as well, then it would be helpful.

Abbishek

[Kevin_Price]

Wow, you hit me with a late plot twist!  Ok, here goes.  You could use a counter task to generate a pulse of your desired width in reaction to the encoder's falling edges.  Then use this generated pulse to drive frame grabs and the light source.  Here's an old post of mine that shows how.  

You could also find your RPM by using another counter task to do frequency measurement.  This would capture encoder pulse time intervals with very high hardware-level precision and drastically lower the quantization effects.  The motion won't be any smoother, it'd still have the same kind of variation and fluctuation, but the data won't be quantized nearly as coarsely.   There's a shipping example for frequency measurement.

Since your device only has 2 counters, you can't do both of those things and also capture encoder position.  But if you aren't using a once-per-rev Z-index to establish an absolute reference point for angle, it doesn't seem like you should need to.  The sample # alone will tell you just as much as a task that captures position.

-Kevin P

[Abbishek94]

Kevin,

Thanks for directing me to your older post.

With respect to getting the angular position, I can get the position from the RPM and timing between the data points as well. Right? If this the case, it would be same as that as the previous program with the difference being that the acquisition rate will be defined by the frequency of the encoder pulses?

Abbishek

[Kevin_Price · Accepted solution]

There's been more than one "previous program", I can't answer without knowing what you're referring to.

If you set up a counter task for frequency measurement, RPM is just a scaling constant multiplied by encoder frequency.  (Note: you should include a call to DAQmx Timing, specifying "Implicit" timing and Continuous Samples so that you'll be buffering a freq measurement for *every* encoder pulse interval.)  Then neither RPM nor interval time are needed to determine position.  The cumulative sample # tells you position because you get 1 sample per interval.

-Kevin P

[Abbishek94]

Kevin,

By ''previous program'', I was referring to the other program which I have uploaded in my first post of this thread, where I acquire the encoder data as angular position, and the data is acquired at the rising edge of the pulse train generated from labview which is used as the frame clock for the camera as well. 

I will try what you suggested with the RPM measurement as well.

Thanks a lot for the help with the clarification you provided with the RPM measurement. It really helped me in understanding the whole situation and now I can move forward without worrying too much about the RPM itself.

Regards,

Abbishek