Reading encoder data

[Abbishek94]

Hi,

I am a graduate student in Auburn University. I am working with a magnetic rotary encoder and a stepper motor. I am using a labview code to synchronize the encoder acquisition with that of a camera, The code has been uploaded here as well. When I am reading the encoder data and converting into RPM, I see fluctuations in the RPM, which goes up and down by 0.3RPM about the mean. The problem is that I am observing the fluctuations only by this amount irrespective of the microstepping I set on the stepper driver or the acquisition rate or the rotation rate. The devices I am using are as follows:

DAQ device: USB 6218

NEMA 34 stepper motor

DM860T Stepper driver

PMX-TBS motion controller

REV-11-1271 magnetic rotary encoder

The plot of the RPM v/s time is attached as well and there you can observe the fluctuations in the steady state RPM. Can someone please help with this problem that why I am seeing these fluctuations and is this a problem with the data acquisition, and if so, a way to rectify these?

Thank You

Regards,

Abbishek

[Kevin_Price]

1. Initial thought -- kinda looks like the real world to me, with somewhere in the ballpark of +/- 5% speed variation using stepper at very low speed (and unknown possible other transmission elements like gears, belts, etc.)

2. Your quantization effects are quite significant though.  Notice the discrete interval of ~0.3 RPM.   *Some* quantization is inevitable with encoders, but this seemed like a bit much. So I tried to break it down.

    With a nominal 5 RPM and 4x decode on a 2048 cycle/rev encoder, you're at around 680 counts per sec.  You appear to be sampling at 20 Hz which makes for a nominal 34 counts per sample.  So an expected amount of quantization would be 1 part in 34 or about 3%.  Your data shows about 6%, pretty much exactly twice that.

3. Your math to get from degrees to RPM looks hinky.  Just guessing now, but I'm a little inclined to think your math might be wrong and your *actual* RPM is more like 2.5.   That'd explain your data's ~6% quantization because you'd then have a nominal 17 counts per sample.

4. Summing up: the shape of your data looks like reality.  Your rotational speed has some real variation, and quantization effects make this look more dramatic on your graph.

5. If motion is unidirectional during a given run, you can get *MUCH* better quantization performance by doing frequency measurement on your encoder.  At some 100's of counts per sec and a 80 MHz measurement timebase, your quantization would be less than 1 part in 100000.

What's the ultimate goal about sync'ing encoder acquisition with a camera?  Would there be a way to do it in hardware?  Many industrial cameras can either capture a frame on receipt of an external pulse and/or emit such a pulse when a frame is captured.  Such pulses can let you sync with hardware-timing precision which will be much dramatically better than anything you can do in software.

-Kevin P

[Abbishek94]

Hi Kevin, 

Thank you for the quick response.

Let me provide a brief background about the data that is shown here. The data was acquired at 200 Hz and a X1 encoding was used. I tried using the X4 encoding, but that indicated much more fluctuations. X1 encoding gave a constant RPM of about 4.98 RPM which is the rotation speed that was set in the motion controller. But, in X1 encoding, we see these kind of 0.3 RPM fluctuations which does not change even if the settings like speed, acquisition rate etc. are changed.

Regarding the RPM calculation, it is wrong in the program. I corrected it and it is giving me the right RPM now. In case of the motion system, the motion is unidirectional. By frequency measurement, do you mean like using a counter input frequency mode instead of the angular position mode?

The ultimate goal about syncing is that we want to capture the encoder data at the same instant as that of the images so that we know the exact angle between each images. The camera which we are using has a bidirectional port, i.e., it can receive as well as output a TTL pulse at which the images are being acquired. In the present program, the TTL pulses generated from labview are being used to trigger the camera. Should we do it the other way round and get the pulses from the camera as the acquisition rate for the encoder?

Regards,

Abbishek

[Kevin_Price · Accepted solution]

These are *offhand* comments as I don't have any specific knowledge or expertise about your particular field of study.

Ok, that's the caveat.  Here's my thinking:

If you merely need to *measure* rather than *control* the angle at which frame captures happen:

1. Go ahead with something like your original program where you generate a constant-rate sample clock for encoder position measurements.  Just be sure to *also* use the same signal to generate the camera frame capture.  Then each camera frame cap will correspond to a specific (measured) encoder position.

2. The alternative is to *control* the positional spacing of camera frame caps.  In this kind of scenario, you let the camera operate at a chosen frame rate while outputting a clock-like frame-capture signal.  Your LabVIEW DAQ programming would then use this signal as a sample clock for an encoder measurement task.  (And potentially also any additional analog task.)

-Kevin P

[Abbishek94]

Thank you very much for the clarifications Kevin.

Regards,

Abbishek