Time between successive readings

[raghav06]

Hi! I'm using two IRC to get the rpm of two shafts of a gearbox, inturn which would give the transmission error which is the difference between the distance rotated by the gear vs distance it should actually cover. So currently I'm using semi period to get the time between consecutive rising and falling edges since I know that the distance between rising pulse is 1° and semi period would yield readings of 0.5°. But if I could use angular position measurement with X4 encoding and compare the time between each pulse read by the loop as the time of rotation, i.e., minimizing or removing the time for other tasks of the loop, I can get the reading for every 0.25° because the A and B channels are separated by 0.25°. So is there any way to do that? 

I hope I didn't confuse you with my explanation.

[cbutcher]

Although conceptually your idea might sound fine, I think that the accuracy you'll achieve will be much lower.

Even though you may have a signal every 0.25 degrees, if the uncertainty in the timing rises to more than ~0.25 degrees, you'd be better with the more accurate DAQmx-based timing outputs that you already have.

Without an FPGA, I wouldn't imagine your chances for getting that good timing accuracy, at least for high-ish rpms, are that great.

Although we still don't know what hardware you're acquiring with, the task does say cDAQ. Is it running WES (Windows Embedded Standard) or LabVIEW Real Time OS? Even with RT I'm not sure you'd get the timing you need if the rotation speed is high.

[Kevin_Price · Accepted solution]

Super-precise timing measurements of encoder semi-periods sounds like a nifty way to get high-res and high-speed characterization of transmission error.   Now let me give you a little "voice of experience" to go with it.

One way or another, you're going to have some quantization error.  The faster you sample, the worse the signal-to-noise of any given measurement interval.  So the attempt to get "perfect" data is gonna run into the wall of reality, at which point you'll likely find that you can settle for "really good" data.  So let's skip the part where you run into that wall, and instead start by figuring out what's good enough to settle for.

IMHO, the most straightforward approach will be to have 2 tasks doing X4 angular position measurement.  Both will use the same signal as a sample clock.  They should also both be configured to use another same signal as an "Arm Start" trigger (probably one of the Z-index pulses).  This will help sync the measurement data from the 2 tasks.

    Most of the transmission error you track will probably correspond to either a once-per-rev error of one of the rotating axes or a once-per-tooth error from the various tooth meshes.  If so, you can predict what kind of mechanical bandwidth you need to capture and do some lowpass filtering to suppress high-freq noise from encoder accuracy tolerances.

   Long, long ago in the pre-Y2K days before the 660x cards introduced support for quadrature encoders, I did analogous measurements based on periods & semi-periods.  Once I was able to do the simpler quadrature position capture with a 6602, I found that it didn't make me sacrifice any measurement precision that I needed to care about.  It was typically more reliable to run position tasks because I could generally use a perfectly clean signal internal to the board as a sample clock.  With period / semi-period measurement, the external signal being measured *is* effectively the sample clock and electrical "noise" can lead to data anomalies or task errors.

Note:  what I recall seeing most of the time in encoder specs was that 

period_error < semiperiod_error < quadrature_phase_error.   So it was not always a good idea overall to use the maximum possible encoder resolution for the measurement.  And if it *was* used, I would usually filter such that most of its high frequency contribution was suppressed.

-Kevin P

[raghav06]

Hi! Thank you very much for the explanation! I understood your point well enough. It's running on RT and based on everyone's suggestions I'll stick to semi period measurement for better results. 🙂

[raghav06]

 wrote:

Super-precise timing measurements of encoder semi-periods sounds like a nifty way to get high-res and high-speed characterization of transmission error.   Now let me give you a little "voice of experience" to go with it.

One way or another, you're going to have some quantization error.  The faster you sample, the worse the signal-to-noise of any given measurement interval.  So the attempt to get "perfect" data is gonna run into the wall of reality, at which point you'll likely find that you can settle for "really good" data.  So let's skip the part where you run into that wall, and instead start by figuring out what's good enough to settle for.

IMHO, the most straightforward approach will be to have 2 tasks doing X4 angular position measurement.  Both will use the same signal as a sample clock.  They should also both be configured to use another same signal as an "Arm Start" trigger (probably one of the Z-index pulses).  This will help sync the measurement data from the 2 tasks.

    Most of the transmission error you track will probably correspond to either a once-per-rev error of one of the rotating axes or a once-per-tooth error from the various tooth meshes.  If so, you can predict what kind of mechanical bandwidth you need to capture and do some lowpass filtering to suppress high-freq noise from encoder accuracy tolerances.

   Long, long ago in the pre-Y2K days before the 660x cards introduced support for quadrature encoders, I did analogous measurements based on periods & semi-periods.  Once I was able to do the simpler quadrature position capture with a 6602, I found that it didn't make me sacrifice any measurement precision that I needed to care about.  It was typically more reliable to run position tasks because I could generally use a perfectly clean signal internal to the board as a sample clock.  With period / semi-period measurement, the external signal being measured *is* effectively the sample clock and electrical "noise" can lead to data anomalies or task errors.

Note:  what I recall seeing most of the time in encoder specs was that 

period_error < semiperiod_error < quadrature_phase_error.   So it was not always a good idea overall to use the maximum possible encoder resolution for the measurement.  And if it *was* used, I would usually filter such that most of its high frequency contribution was suppressed.

-Kevin P

---

Thanks a ton for the help!! 🙂 I'll try this too! I learnt something new today! 😄