Electronics > Projects, Designs, and Technical Stuff
Motion control, S-curves and other stuff >> controlling lift with DC motor
<< < (5/14) > >>
Siwastaja:
Motors typically have such high inductance compared to the high switching frequency and high current measurement bandwidth, that current ripple is very small, and it's trivial to tune the current PI loop to react fast and not overshoot. If done like that, "pulse by pulse" limiting is only a safeguard measure against problems during initial PI controller tuning at early stage of development; and a safeguard against some strange edge cases that still slips through the PI loop control; or a short circuit.

Though, even the "pulse by pulse" limit may be too slow to react to the actual short circuit, because the inductance is now bypassed and the protection should be really fast (microsecond range). For cost-cutting, it may make sense to decide not to support safe shorting of the output.
krisRaba:

--- Quote from: capt bullshot on October 01, 2019, 02:29:53 pm ---STM32 doesn't have internal routing from the QEI decoder to other timers afair, I'd propose to route the encoder signals to additional timer inputs running in edge capture mode.

--- End quote ---
Today I have found that in F3 serie it is possible in SYSCFG to select ENCODER_MODE bits which will connect TIM15_CH1 and TIM15_CH2 to inputs on TIM2, TIM3 or TIM4. Maybe they are connected in parallel thenand both timers can use them? It would be great. But it has to be tested because I haven't found any information about that option and it is very poorly described in datasheet.
I can't see any related signal input on TIM2/3/4 diagrams so it will be something outside these blocks, I think.


--- Quote from: Siwastaja on October 01, 2019, 03:40:54 pm ---Motors typically have such high inductance compared to the high switching frequency and high current measurement bandwidth, that current ripple is very small, and it's trivial to tune the current PI loop to react fast and not overshoot. If done like that, "pulse by pulse" limiting is only a safeguard measure against problems during initial PI controller tuning at early stage of development; and a safeguard against some strange edge cases that still slips through the PI loop control; or a short circuit.

Though, even the "pulse by pulse" limit may be too slow to react to the actual short circuit, because the inductance is now bypassed and the protection should be really fast (microsecond range). For cost-cutting, it may make sense to decide not to support safe shorting of the output.

--- End quote ---
I usually use it like that - to limit current when something goes really wrong. But I was also thinking of some kind of hardware regulation where you can write 0xFFFF to OCRx and it will be trimmed by OCrefCLEAR when current reaches setpoint and comparator changes its state. Maybe it is not the best solution ;) But if I recall properly it was used in some document about BLDC 6-step control to limit phase current to desired level. It used external circuitry to filter out noise and after comparator was routed to TIMx_ETR pin. Then ETR was selected as OCrefCLEAR source...
But actually almost everything you need for that is inside the MCU ;)
jbb:
From past experience with PV inverters, an ‘oh crap’ hardware overcurrent trip is good.

In terms of control rate, it’s easiest from a SW perspective to run everything at the same sample rate. However, you might run out of execution time. So maybe group things together: run the current ADC at twice the PWM frequency, the current (aka torque) and speed loops at the PWM frequency, and the position loop at a lower frequency (maybe 10x lower?).

In the interests of not going crazy, I’d suggest aiming for current bandwidth = PWM frequency / 10, and speed bandwidth = PWM frequency / 100 and position bandwidth <= PWM frequency / 1000.

I’ve found it very handy in the past to set and clear some GPIO pins as the processor makes its way though the code. You can then directly measure execution times with a scope.

Regarding gravity: obviously it’s an issue. You need torque to compensate for gravity, and it will vary with the mechanical load. The Integral part of the speed controller will soak this up. You may find it beneficial to have different +ve and -ve limits. So you don’t accelerate the stage into the floor :-)
krisRaba:

--- Quote from: jbb on October 02, 2019, 07:31:36 am ---From past experience with PV inverters, an ‘oh crap’ hardware overcurrent trip is good.

In terms of control rate, it’s easiest from a SW perspective to run everything at the same sample rate. However, you might run out of execution time. So maybe group things together: run the current ADC at twice the PWM frequency, the current (aka torque) and speed loops at the PWM frequency, and the position loop at a lower frequency (maybe 10x lower?).

In the interests of not going crazy, I’d suggest aiming for current bandwidth = PWM frequency / 10, and speed bandwidth = PWM frequency / 100 and position bandwidth <= PWM frequency / 1000.

--- End quote ---
Thanks for these tips. I will close my current loop soon and then I will try to tweak everything above...


--- Quote from: jbb on October 02, 2019, 07:31:36 am ---I’ve found it very handy in the past to set and clear some GPIO pins as the processor makes its way though the code. You can then directly measure execution times with a scope.

--- End quote ---
I use that method too ;)


--- Quote from: jbb on October 02, 2019, 07:31:36 am ---Regarding gravity: obviously it’s an issue. You need torque to compensate for gravity, and it will vary with the mechanical load. The Integral part of the speed controller will soak this up. You may find it beneficial to have different +ve and -ve limits. So you don’t accelerate the stage into the floor :-)

--- End quote ---
In new cascade with current loop I hope that it will handle that. My currently used speed loop works ok with symmetric output for PWM. It probably doesn't use full range for DOWN direction but who cares if it knows what to do. But maybe you mean tuning phase... yeah.. everything can happen then ;)
krisRaba:
So far I have added AUX encoder on motor shaft and results are quite promising. It performes better than on linear encoder only, I think, especially at lower speeds where linear encoder's resolution was too small so only few pulses were counted per sampling period + quantization error caused by sampling period not synchronized to speed and incoming pulses.
But I have also noticed that my speed tracking loop based on linear encoder works surprisingly well and it offers similar speed error amplitude from sample to sample to my new measurement based on AUX encoder in more steady regions. Of course error slightly increases at rapid changes before the loop finds out that something is wrong with estimated value ;) And it lags a little bit... but still is better than raw delta time measurement from linear encoder.

With new measurements I have used just discovered functionality, that I can forward signals from timer in QEI mode (delta time method) to other timer that can count time between edges (delta pos method) :] Delta pos method is better for low speeds, delta time for high speeds so basing on setpoint I use "crossover" speed to decide which measurement should be forwarded to speed variable ;) At the moment it works like a switching point but maybe I should use some kind of proportional change in wider range? I don't know ;)

I have also added bipolar current sensor in series with motor windings but so far I haven't enough time to write code that handles it. I hope to do it soon.

One annoying thing that I noticed is that there is some "fighting" at the end of the move when speed is fading out. It reaches very low speeds, probably hard to measure precisely, so measurement reaches near zero but setpoint is a little bit higher so there is a bump on PWM output to increase speed to setpoint level. Nothing noticeable happens on measurement (time between encoder pulses) so it winds up and bang, new pulse arrives - setpoint exceeded so "stop your horses!" occurs ;) And because of that braking is not perfectly smooth at the end.
I wonder if that planned current loop will help with such things. Current loop will be fast, much faster than speed loop, and current measurements are available each cycle so no need to wait for speed pulse to react. As fas as I understand that, between speed loops there will be a constant current setpoint and current loop will try to handle it. Constant current means constant torque... How it will react to changing friction or other disturbance? With constant torque additional friction will probably slow down the lift and it will have to wait for speed loop that will ask for more current/torque to keep speed setpoint...
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod