Reading encoder data and determining the RPM

[Abbishek94]

Hi,

I am Abbishek and I am a graduate student in the Department of Aerospace Engineering in Auburn University. I am using a stepper motor to rotate a shaft and a rotary encoder to measure the position of the shaft and hence determine the RPM. The encoder I am using is a quadrature encoder (REV-11-1271). Initially, I was using the "Measure Angular Position - modKP.vi" program to get the position of the shaft from the encoder and then determine the RPM of the shaft from that. The DAQ system I am using is the NI-6218. When I run the program and use the X4 decoding, I observed a lot of fluctuations. So, I used an X1 decoding, and the fluctuations reduced a bit. But I observed something peculiar in the RPM measurement. It was seen that the fluctuations about the mean RPM were always about 0.3 RPM, irrespective of the motor rotation rate, the acquisition rate or the microstepping. To check further, I changed the program and used the other VI which has been uploaded here. In that VI, I counted the edges over 1 second to determine the frequency of the pulses and got the RPM from there (our encoder has 2048 pulses per revolution). But, there I observed that the encoder is outputting varying frequencies due to which the RPM is varying as well.

I wanted to know that why am I getting this kind of fluctuations (only 0.3 RPM magnitude). Does it have something to do with the acquisition parameters or how we are acquiring the data? Please help me out with this issue.

Thank you

Regards,

Abbishek

[Kevin_Price]

In prior replies to you about this I focused on just the DAQ-related stuff.  Now that you're still stuck and have such odd observations it's time for a closer look at the rest of it.

Run your latest vi until you've captured some typical-looking data, stop it, go to the Edit menu and select "Make Current Values Default", save it, then post it here.

-Kevin P

[Abbishek94]

Hi Kevin,

Please find the VI attached with the mail. I tried to make the current values default but it would not show the graph. So, I am uploading two images as well here. In one image, the data has been acquired at 0.1 seconds while in the other image, the data has been acquired every 0.5 seconds. It seems like when I acquire at 0.1 seconds, I see distinct peaks, whereas with 0.5 seconds, I do not observe those peaks and just see fluctuations. I was wondering, if this is something to do with the acquisition system or something else is going on here. 

Let me know if any additional details are required.

Thank you

Abbishek

[Kevin_Price]

Mostly I would just repeat what I already posted in a related thread.

This time however the diagnosis is more clear and definite.  You're now doing edge counting with 2048 edges per rev.  At 5 RPM, you have a nominal frequency of 170.7 edges/sec.

When you check your counts every 100 msec, you can expect a nominal count difference of 17.  A combination of actual speed variation and necessary quantization with such a small integer denominator leads to the observed 1 part in 17 quantization effect, which entirely explains the 0.3 out of 5 RPM ratio you're describing.

The code posted in your other threads used a hardware-timed sample clock to capture position data.  It's a much better starting point in terms of DAQ config because you get x4 quadrature resolution *AND* it makes consistent hardware timing available for your RPM calculation.  (Though you have to actually *use* the hardware timing info to your advantage.)   You'll still see real speed variation effects and quantization effects.

Nothing's wrong with your equipment.  You're just seeing real world constraints and imperfections.  Get used to them, there's gonna be a lot more of them in the future!

-Kevin P

[Abbishek94]

Ok. That is why I am observing 0.3RPM variations irrespective of the speed of the motor I setting it to. 

But, if that's the case, in the other program, where we get the encoder position directly, when I do X4 decoding, I see lot more fluctuations whereas with X1 decoding, I see only the 0.3 RPM fluctuations. Why is this happening? I am uploading two images where the RPM is shown for X1 and X4 decoding. 

Also, is the quantization effect the reason, why I am seeing a lot more fluctuations when I count it every 0.5 seconds? Is there a way to reduce these effects?

Regards,

Abbishek

[Kevin_Price]

So, honestly and bluntly, I think we're stuck at the stereotypical divide between academic and industrial (what I call "real world") engineering.

Out here there are no frictionless planes, there are no cannonball trajectories without wind resistance, there are no perfectly smooth motions, there are no perfectly manufactured encoders, there are no analog sensors without noise, there are no data acq systems with infinite resolution.

One of my favorite tech quotes is that the fundamental law of engineering is "the conservation of misery".  Meaning that nothing's ever perfect and there are always limitations, constraints, and trade-offs to be made.

Your data looks eminently reasonable for a real-world system.  Reality is doing its normal thing just fine here, it's probably your expectations that need adjustment.

Maybe I can help give some advice about possible trade-offs you could consider, but I'd need a better idea of the overall big picture.  Where does this motion measurement fit into the overall context of your work?  Why does the small-ish speed variation concern you?  What's the impact?

-Kevin P

[Abbishek94]

Hi Kevin,

I understand what you are suggesting, that there will be some fluctuations irrespective of how perfect the system is. But the question I am having is that with X4 decoding, we see varying fluctuations while for X1 decoding, we see only the 0.3 RPM fluctuations. What is the reason behind this? But to give you more perspective of the experiment and studies we want to conduct, below is the description for that:

Ours is a benchtop setup and the image of the setup is uploaded here as well. The setup consists of a NEMA 34 stepper motor with a DM860T stepper motor driver. The motor shaft is coupled with the rotation shaft with the help of timing pulleys and belt. A REV-11-1271 magnetic rotary encoder (quadrature encoder) is mounted at the center and the rotation shaft goes through it. The DAQ system I am using is a NI USB-6218. In my work, I will be imaging the flow field of a flat plate which is rotating. For the calibration required in our methodology, we need the encoder angles. So, that is why the proper encoder angles are crucial for us. This is a flow field measurement experiment and some changes in the rotation rate may cause changes in the desired flow field over the rotating flat plate. So, this is the reason we are wanting a smoother motion as possible.

Hope this gives you a picture of what the setup is and where the encoder is mounted and why are the angles and RPM crucial for us.

Regards,

Abbishek

[Kevin_Price]

The latest code is doing neither X4 nor X1 decoding, it's merely counting edges of one quadrature channel.  (It's pretty similar to X1 but without the ability to determine direction.)

Otherwise though, I can almost guarantee it's just quantization effects.  Nothing more, nothing less.  They're less visually obvious and noticeable with X4 encoding because they're 1/4 as big as what you get with X1.   Same reasoning for why it's not as noticeable with edge counting when you check at 500 msec intervals instead of 100 msec.   It's all in the ratios.

My "real world" analysis is that you've already conceded the battle for smooth motion by:

- using a stepper motor with its high cogging torque instead of a servo

- operating the stepper at a very low speed

- using a (toothed?) belt drive for no readily apparent reason since it appears to be close to a 1:1 drive ratio

Nevertheless, the motion actually *is* pretty reasonably smooth.  That microstepping drive must be rather good.

The pic helps some, but I have no familiarity with "flow field imaging".  I would say that you've already got pretty smooth motion, all things considered.  So would it be sufficient to measure the position corresponding to a given image?  Or, if you somehow truly need to capture images at equidistant angles, can't you just use one of your encoder channels as a clock for your camera frame grabs?

-Kevin P

[Abbishek94]

Kevin,

I get the point now regarding the different encoding types. 

In the experiment, it would be better, if we get the images at equidistant angles. To get that, we are generating a TTL pulse through labview to synchronize the encoder and the camera acquisition which I have mentioned in the other threads as well. So, if this is the best we can get, then, we will have to work with it.

Regards,

Abbishek

[Kevin_Price]

If motion is unidirectional, you can just use the encoder's own TTL pulses (which are *inherently* equidistant in angle) as the clock for your camera's frame grabs.  You could also use it as a clock for edge counting or position measurement.  Although, in many such cases, there's no great value in measuring encoder edges or position -- the angle is *implicit* in the frame # from the camera.

However, you may need to use the encoder's Z-index as an absolute reference.  If so, I'd still probably recommend going with X1 encoding (which I believe will react to rising edges of A).  The problem with X4 is that one of the 4 state transitions sets up a kind of electrical signal race condition.  The same falling edge is used to capture the instantaneous position *and* to change it.  Which happens first?  I don't know.  I'm not sure if you *can* know for sure.

-Kevin P