Jumpy speed reporting on MDC2230

6 years 2 months ago #29529441 by Griffin Baker
Replied by Griffin Baker on topic Jumpy speed reporting on MDC2230
It is related to the number of encoder counts. Speed is measured by counting the number of encoder counter every 10ms. That is a very short time and so if the encoder has a low PPR, one extra count within that 10ms can mean several RPM.

The speed speed must be measure fast in order to allow closed loop operation. So the only way to get a better speed capture resolution is to use a higher count encoder.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529445 by jgannon
As I mentioned, my encoders are 1024 CPR, and my motor is spinning ~35 RPM. That works out to almost exactly six pulses per sample. Seems like I should be seeing a 35 show up in there occasionally, right? It's not even close.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529447 by Griffin Baker
Replied by Griffin Baker on topic Jumpy speed reporting on MDC2230
1 pulse = 4 counts.

Try changing the resolution and see what the differences are in the values read. If lower the resolution, the smaller the sample data taken and reported back. The higher the resolution, the more the sampling rate.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529453 by jgannon
The nomenclature is a little confusing here, so let me be clear. When I hand turn the encoder through one full revolution, the counter on the controller increases by 4096.

How do I change the sampling rate? I don't understand what you're suggesting.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529456 by Griffin Baker
Replied by Griffin Baker on topic Jumpy speed reporting on MDC2230
The PPR (pulses per revolution).

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529460 by jgannon
As best I can tell, that just changes the scaling factor. I changed the PPR from 1024 to 102, and now instead of bouncing between 29 and 43, it bounces between 294 and 441. What else do I need to do?

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529461 by Griffin Baker
Replied by Griffin Baker on topic Jumpy speed reporting on MDC2230
Hook up the motor to the motor output of the controller instead of using the power supply. Use the sliders in the run tab to give the motor command. If the max motor speed is 3000 RPMs, then at the full motor command output when pwm = 100% (Slider command is +1000) then it should read 3000 rpms. Any command less than that, the speed will change accordingly.

If your PPR is off, then the readings will be wrong.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529462 by jgannon
I'm now running the motor in open-loop with the controller. Here's another video to more clearly demonstrate the problem: www.youtube.com/watch?v=y10-A_ubeXo (quality is a little sketchy, sorry)

Watch the speed as I ramp up the command. It tracks really nicely through lower speeds, but once I get up to the max of ~35RPM, it starts with the bouncing between 29 and 43 instead of anything close to the true speed.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529463 by Griffin Baker
Replied by Griffin Baker on topic Jumpy speed reporting on MDC2230
As far as it goes, it looks like our controller is reading the encoder, but as to why it is jumpy is unknown. You might want to contact the manufacturer of your encoder to see if there is anything else they can do to resolve this issue.

If you have another encoder, you can try and see if the result is the same.

Please Log in or Create an account to join the conversation.

6 years 2 months ago #29529464 by jgannon
As I've mentioned, I have hooked the encoder up to a scope, and the signal is very smooth and consistent. I'm confident in asserting that there is nothing wrong with the encoder.

Is there any chance you could bring another engineer into this discussion? This problem definitely seems like one that could benefit from a fresh set of eyes.

Please Log in or Create an account to join the conversation.

Moderators: tonysantoni
Time to create page: 0.161 seconds