Electronics > Projects, Designs, and Technical Stuff

DC motor controller

<< < (4/5) > >>

Siwastaja:
The elephant question in the room is, why in the world would you want to use a 4096-step encoder on a DC motor axis? The control of the motor will never be even in the same ballpark of accuracy. The brushes energizing windings causes torque ripple, inductance of the windings limit the rate of change when you want to feedback current, and inertia prevents sudden changes in speed - all in all, if you want the motor to run at an exact speed, or feedback it to track a certain position, you are at least two orders of magnitude away from that 4096 steps per revolution.

I'd understand if that 4096 step encoder would be on the output shaft of a 1:256 reduction gear; or if you used, say, a 16-step encoder on the motor shaft (equivalent thing).

Everybody is ignoring the 500kHz pulse rate because it sounds so strange. What are you going to do with a pulse every 2 microseconds when just changing the motor current by any meaningful amount takes some 100 microseconds? I mean, this is like measuring a kettle temperature every 1ms to adjust a heating element when it takes a minute for the water to heat up by any significant amount.

Usually, the feedback loops run at something like 10% to 50% of the PWM frequency, and the PWM frequency is somewhere around 10-20kHz.

Try to run the feedbacks at 1kHz first and only if you can show a responsitivity problem, go for maybe 2kHz, still just fine on an 8-bitter; not 500kHz.

What comes to the encoder itself, hardware timers/counters are used for this. The AVR should have 16-bit counters available, but even if you must use a 8-bit counter, this already divides your 500kHz rate to around 2kHz; this would be the overflow interrupt in which you increment or decrement a software counter. At 2kHz, you can easily handle a 64-bit counter, for a total of 72 bits.

langwadt:

--- Quote from: Siwastaja on July 28, 2020, 10:20:11 am ---The elephant question in the room is, why in the world would you want to use a 4096-step encoder on a DC motor axis? The control of the motor will never be even in the same ballpark of accuracy. The brushes energizing windings causes torque ripple, inductance of the windings limit the rate of change when you want to feedback current, and inertia prevents sudden changes in speed - all in all, if you want the motor to run at an exact speed, or feedback it to track a certain position, you are at least two orders of magnitude away from that 4096 steps per revolution.

I'd understand if that 4096 step encoder would be on the output shaft of a 1:256 reduction gear; or if you used, say, a 16-step encoder on the motor shaft (equivalent thing).

Everybody is ignoring the 500kHz pulse rate because it sounds so strange. What are you going to do with a pulse every 2 microseconds when just changing the motor current by any meaningful amount takes some 100 microseconds? I mean, this is like measuring a kettle temperature every 1ms to adjust a heating element when it takes a minute for the water to heat up by any significant amount.

Usually, the feedback loops run at something like 10% to 50% of the PWM frequency, and the PWM frequency is somewhere around 10-20kHz.

Try to run the feedbacks at 1kHz first and only if you can show a responsitivity problem, go for maybe 2kHz, still just fine on an 8-bitter; not 500kHz.

What comes to the encoder itself, hardware timers/counters are used for this. The AVR should have 16-bit counters available, but even if you must use a 8-bit counter, this already divides your 500kHz rate to around 2kHz; this would be the overflow interrupt in which you increment or decrement a software counter. At 2kHz, you can easily handle a 64-bit counter, for a total of 72 bits.

--- End quote ---

overflow interrupt quickly gets messy to do safely, use a timer interrupt that you are sure is faster than the counter can wrap

four quad decoders, two on 32bit timers and two on 16bit timers extended to 32bit, https://github.com/langwadt/nucleo_quad4




OM222O:
I already answered your "elephant in the room" as that encoder was the only one available to me, other than the mechanical "knobs" that come with 13PPR. I can't wait 2 months for stuff to ship from china since this project needs to be ready by october (first post). I also mentioned that I would probably go with some sort of frequency divider.

All in all, it still doesn't answer either of the questions I asked about dedicated encoder ICs / teensy's built in decoders without any detail in the datasheet. Please let me know what chips I should be searching for this application, I will try reducing the pulses to reasonable levels.

H.O:
If you're controlling position using the quadrature encoder signals as feedback then forget about using a simple frequency divider(s) to divide down the high frequency quadrature signal from the encoder - it's not as simple as just slapping a divide-by-n on each of the two signals.

Like I said earlier, the LS7166 is a "classic" quadrature counter IC but I don't know how easy it is purchase now. Another one that pops up when searching is the iCHaus ic-MD but I don't know how easy it is to actually purchase. I believe most people that know that what they're doing either roll there own counter in a CPLD or FPGA or use a a uC with the required peripheral.

I'm surpised you weren't able to find an encoder with a resolution other than 4096PPR. The CUI Inc encoder with programmable resoultion mentioned earlier are availble from Digikey and you have manufacturers like US Digital, Avago, Scancon, Hengstler, Heidenhein, Omron etc etc offering all sorts of enocders.

Finally, if you can live with 1/4th the resoulution of the encoder you should be able to quite easily convert what you have into into two discrete up/down pulses using some basic 74 series logic ICs. Then feed those signals into two separate timer/counter inputs on the uC and differentiate them each loop to get the relative distance moved since last time.

If you can't wait two months for "stuff" to arrive I stronlgy you suggest you shop around for something that does what you need. You'll spend a lot of time rolling your own solution which - again - is not wrong but in this case it feels like the actual motor control part is just a small piece of a bigger picture.

Siwastaja:
IMHO, 500kHz encoder signal shouldn't be a problem for the 16MHz AVR hardware timer/counter module, that's the point. Have you tried it? Are you having a problem, and if yes, what kind?

So you don't need to process every pulse in software.

The counters count the pulses for you; you only add extra bits in overflow interrupts (500kHz/256 is manageable interrupt rate because the ISR is very short). Then you can do actual calculations at 1kHz, for example, looking at the counter values.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod