Motion control, S-curves and other stuff >> controlling lift with DC motor - Page 1
Forum section: electronics / projects

author: krisRaba
author_rank: Regular Contributor
timestamp: September 30, 2019, 05:01:42 pm
content: Hi!I hope that we have at least one expert in motion control hereFirst of all - the object (or plant)I have about 6kg lift (so vertical direction of move) driven by geared DC motor and what I need is smooth movement from position A to position B with controlled speed in the same time. At the moment I have available:position feedback - 0.01mm resolution linear magnetic encodercurrent feedback - unipolar ACS723 current sensor in V+ above H-bridge.Current solutionFor velocity feedback I use tracking loop that compares actual position from encoder with estimated position calculated from estimated velocity. It works better than raw calculation based on pulses count per deltaT or moving window average from raw results (lag). But still on very slow speeds it is not so great because of low pulse count per encoder reading period. I am thinking about additional encoder on motor shaft (so before /27 gearing) which will give much higher resolution but maybe it can be improved by better algorithms?I have implemented cascade of regulators:PD position -> [linear speed limiter a.k.a ramping] -> PI speed -> PWMs for DC motorPositioning works but probably could be tuned a little bit better. One thing I don't like is the shape of velocity curve. Velocity change is limited so setpoint best case is a trapezoid which produces nice S-shape on position curve. But if you put position loop above that you get shapes like "bannana up" on acceleration and inversed "bannana down" on decelerationAnd of course there are still 2 sharp edges: at the beginning and when changing from constant speed to deceleration phase.S-curves - how to?I would like to implement S-curve to velocity curve for smooth movement.My first idea was to linearly control current by adding additional current control loop and linear limiter. As far as I know current in DC motor is proportional to torque so also proportional to acceleration. Linear acceleration should give S-curve for velocity. Bad news here is that current measurement in this object/plant is not as I expected. I thought that with unidirectional current sensor in V+ above H-bridge I will be able to measure current regardless of DC motor rotation direction. It is true in steady state. When my cascade of regulators keeps position current increases every time force is applied up or down to keep it in place. But because of BEMF during normal operation and going down current reverses most of the time and tries to flow in unexpected directionRegenerative braking is its name, I thinkSo such current control would work during going up but I think it won't work when going down. But maybe I am wrong?Another way to get S-curve on velocity is to get rid of linear speed limited and calculate velocity setpoints that will form S-curve and track it with speed regulator. But it seems to be complicated especially when position setpoint is changed before previous setpoint is reached, so previous s-curve is not finished. With linear acceleration it would be smooth by definition, without advanced motion recalculation on the fly. But maybe it is done that way in motion controllers?Additional problem is with final position estimation. To know "landing point" whole motion has to be calculated before even starting the move, I think. Because other way it would be hard to know when to start deceleration...Any ideas how it should be done better?

author: IanB
author_rank: Super Contributor
timestamp: September 30, 2019, 05:23:29 pm
content: My first thought is "less is more".You seem to have a fairly complicated cascade of layers in your control scheme. It seems that each time you don't quite get the result you want you are adding more layers? Now it seems you may be contemplating feed-forward elements with predictive control...Maybe it is time to try taking things away instead of adding? Have you tried doing simple PID control on position and tuning the P, I and D terms carefully? Your I term should be able to give you some ramping behavior to reduce jolt, and your D term should be able to give you some feed-forward prediction to slow down when you are approach the target position. Perhaps this is where you started, but it still seems to me to be a rational approach.I haven't implemented control on a system like this, so the above thoughts are just guesses. However, I do think there comes a time when adding more complexity to a system doesn't help.

author: krisRaba
author_rank: Regular Contributor
timestamp: September 30, 2019, 07:33:08 pm
content: Hi!Thank you for your response.I have tried with single PIDAnd this is not proper way to do it, I think.When you separate controllers you have more control over particular elements. First of all you have velocity control itself that isolates any object/plant nonlinearity from higher layers. When you set 10mm/s it keeps it regardless of anything - load change, friction change, supply voltage rail fluctuations etc. It uses all it can use (full range of PWM) to keep your velocity setpoint.When you use single PID like [position input / PWM output] - what is your speed between positions? Hard to tellIf you have PID with limited output you can set limits for max PWM duty and min PWM duty... it doesn't talk in "limited velocity language"It is very important in vertical movement. In horizontal movements it is a little bit easier because it is almost sure that 50% PWM duty LEFT will give the same velocity but opposite sign to 50% PWM duty RIGHT..But in vertical direction result of 50% PWM duty UP is far away from 50% PWM duty DOWN. Gravity is your enemy hereSo you can isolate that nonlinearity by additional layer. You have PI velocity controller that handles all that stuff and higher layers don't have to care about it.Now on top of that you have position controller. It takes position setpoint and outputs... yes! Velocity! So you have a point where you can control speed. You can set your max and min velocity, and you can say: OK, take me from point A to point B but maximum velocity is 200mm/s or 600mm/s. You can't do that with single PID and asymmetric object.So cascade of controllers is not a stupid solution hereI have seen many examples with even longer cascades of controllersBut usually general description and math in these documents looks a little bit overwhelming for meIt is a little bit easier to learn from examples instead of PhD elaborationsAnd in such moments I am not sure if I should add another layer with S-curve somewhere between controllers or replace position PD controller and calculate position changes on the fly with S-curves formulas.And you are right, I was thinking of some kind of feed-forwardJust because I have read somewhere that it limits the role of PID itself, it has to handle only the error instead of full value change. But I haven't investigated that topic yet

author: capt bullshot
author_rank: Super Contributor
timestamp: September 30, 2019, 07:50:15 pm
content: The common way in servo controllers is a cascade of three control loops:Inner loop: motor current (aka motor torque) controls motor voltageMiddle loop: speed controls torque (current)Outer loop: position controls speedAs far as I can see, this looks like your control scheme, so I think you've done that part right. For smooth acceleration / deceleration various schemes exist, depending on the requirements. One of them looks similar to your approach and you've successfully found its limits. I'm not deeply into this stuff, so can't help with details of how to implement, but I vaguely remember there's some kind of math (like spline interpolation or up to fifth order curve fitting) required to generate smooth transitions from stopped system to movement and vice versa - quite demanding e.g. for real elevators.To increase encoder resolution at slow speed with a limited amount of pulses per revolution - do a time measurement from one pulse to the next pulse and calculate raw speed from that in addition to counting pulses per unit of time. Using a tracking loop (observer structure, or some kind of prediction) to get better results is also common technique, but as I said, I'm not deeply enough into that stuff to help with details.Edit: Having a second encoder for speed, directly at the motor output before the gearbox, should help for smoother velocity control.And yes, to "land on the spot" you should be able to predict the deceleration curve or supply the position controller with the S-curve matching you mechanical system (expressed in position). At least some industrial servo controllers work this way - these can be quite complex beasts, not just a simple VFD.

author: krisRaba
author_rank: Regular Contributor
timestamp: September 30, 2019, 08:51:09 pm
content: Thanks for your input :-)I have read some documents about speed feedback and both delta position and delta time methods have their drawbacks. Sometimes it is useful to mix them so some of the drawbacks are mitigated but generally tracking loops and observers are recommended.Lack of pulses at low speeds is generally hard to manage. You can measure time between edges and additionally estimate at each sampling period that because there was no pulse and timer is still counting your speed is not higher than X but it works better with ideal encoders with ideal edge positions and spacing.. but AFAIK such encoders doesn't exist ;-)So my tracking loop works well but unfortunately can't overcome physical limits where in sampling period there is no pulse or double pulse is counted because real speed is not synchronized with sampling time. There are some techniques for such synchronization but I don't understand what they were talking about :-DMaybe you are right with position S-curve generating for position controller. It would have to be higher order to produce another S-curve on speed but it may work :-)

author: jbb
author_rank: Super Contributor
timestamp: September 30, 2019, 09:30:06 pm
content: Depending on how you feel about horrible mathematics, you can do as much or as little as you like. Are you looking for good enough or maximum speed or maximum smoothness? Will your payload weight change during operation?To throw my not-very-informed opinion into the ring... I would look at doing the S curve generation purely on the position reference side.Some things I’d be concerned about:- with finite encoder resolution, I suspect you’ll get a little bit of vibration (eg limit cycle oscilllations) when the platform is stationary. If you need something dead steady, I suggest a mechanical brake.- look out for integrator wind-up- in the faster loops (especially current control), Derivative gain can pass high frequency noise through the system, so if you’ve got lots of bitter happening, try setting D gain to 0- when lowering load, you may well be generating electricity. Have you checked for this and designed appropriate countermeasures (an external braking resistor is absolutely classic)- if the DC link voltage changes more than a few %, the PWM reference to equivalent motor voltage rail will change. In general, I suggest including DC link measurement and compensation when generating the PWM duty cycle- different payloads will change the plant gain, so PID settings would need to be a compromise that works OK with varying loads- the current sensor arrangement you describe isn’t ideal. Could you rearrange your system so that you have a bipolar current sensor on the true motor current?- I suggest running current sense ADCs at twice the PWM switching frequency so that the switching frequency is at the top of the Nyquist band and can be filtered out effectively. I have tried sampling at the PWM frequency in the past, and found that small variations in the plant generated some frequencies very close to the switching frequency (thus close to the sampling frequency) which then aliased down to near DC where I could t filter them out. It was disturbing to see my current waveforms ‘gallop’ across the oscilloscope... and moving to double frequency sampling fixed it totally- it’s possible to develop an observer for the total platform mass (difficult maths)- it’s possible to develop an observer for the platform speed and position that will provide smooth, continuous position output even at low speed (difficult maths)

author: krisRaba
author_rank: Regular Contributor
timestamp: September 30, 2019, 10:01:40 pm
content: Quote from: jbb on September 30, 2019, 09:30:06 pmI am not sure how much of horrible math I can handleI have noticed that usually all these horrible descriptions and equations become more eatable when used in discrete form as algorithm examplesGenerally during single move payload is constant but I have to take into account that someone will change it without changing any parameters so system should handle that or adjust/autotune.Quote from: jbb on September 30, 2019, 09:30:06 pmI will try that, I think.Quote from: jbb on September 30, 2019, 09:30:06 pmIt is interesting. I have noticed such behavior. When speed PI setpoint is set to 0 it bounces around pulse from time to time. I thought that position controller does that because 0,01mm is quite high resolution for position keeping.. but it turns out it is a matter of speed PIAnd what is more interesting - I can easily directly set PWM duty at which position is kept and everthing is steady.Maybe with higher resolution (encoder on motor shaft) it will also behave better on PIQuote from: jbb on September 30, 2019, 09:30:06 pmIt is limited in my PID implementation AFAIKQuote from: jbb on September 30, 2019, 09:30:06 pmAt the moment I don't have current loop. I use hardware to limit max current (OCref clear functionality in STM32) and trim PWM duty. My lowest control loop is speed and it is PI type.Quote from: jbb on September 30, 2019, 09:30:06 pmAt the moment I use PSU that can handle that because other cheaper PSUs were not so happy and were shutting down because of OVPIn the future I plan to implement some resistor+NMOS+opamp to protect DC rail and use standard PSU.Quote from: jbb on September 30, 2019, 09:30:06 pmSpeed control loop handles that, I think.Quote from: jbb on September 30, 2019, 09:30:06 pmThat's true. I have noticed that parameters tuned for one setup not always fit another setupQuote from: jbb on September 30, 2019, 09:30:06 pmIt is possible in future PCB release. You mean putting sensor in series with motor, inside H-bridge?Will it bring any improvements to control system?Quote from: jbb on September 30, 2019, 09:30:06 pmThanks for advice. I will keep it in mind. It will be helpfull, I think.Quote from: jbb on September 30, 2019, 09:30:06 pmAny examples of that maths?

author: jbb
author_rank: Super Contributor
timestamp: September 30, 2019, 11:21:30 pm
content: Sorry for messy reply - writing on phone at lunch.Re jumping around at low speed: I think a higher resolution encoder would just make the bitter smaller, rather than getting rid of it. One possibility would be to set a deadband on the position controller that’s a little bigger than the resolution of the encoder. But this could just make things worse... There may be someone on the forum who’s grappled with these issues??Re current sense: yes, I mean put it inside the H Bridge directly in series with the motor. For a brushed DC motor the torque is directly proportional to the current. Controlling current equals controlling torque which is great because it then determines the lifting force (plus gearbox and capstan, of course), which is I prtant for your system dynamics. Also limits motor current to prevent firey death. Have you fitted some ferrite beads and EMI caps to the motor?Re DC rail compensation: if the rail doesn’t move much, you can probably ignore it. But if you’re having trouble with all the system gains moving around, getting 1 unknown term compensated might be helpful.Re observers: I’ve totally forgotten the maths, sorry.

author: Mechatrommer
author_rank: Super Contributor
timestamp: September 30, 2019, 11:39:31 pm
content: you may try implementing Fig 3.22 (cascaded loop) for this kind of multivariable (acceleration/velocity and position) control system inhttps://www.sciencedirect.com/topics/engineering/position-loopthats the mainstream way in control academic, or... you can try preplanned/precalculated S-curve and do single loop PID control based on that calculated values, ymmv.Quote from: krisRaba on September 30, 2019, 10:01:40 pmany control book i know will start with plant modelling, and then to control loop or feedback schematics with gain parm, and then transfer function is derived, and then transformed to Laplace domain to find zeros and poles to determine stability. i never took them seriously esp the Laplace part. you may download some free control book online. and you can see some math example in link i provided above. any control related discussion/text will follow this mode, mind boggling modeyou can go further if you like to "adaptive" or "robust" control for even more mind boggling math, and meet the observer, disturbance and the like in the form of abstract mathematics. ymmv.

author: Someone
author_rank: Super Contributor
timestamp: September 30, 2019, 11:48:21 pm
content: Quote from: krisRaba on September 30, 2019, 05:01:42 pmThis is the entire problem of smooth motion,predictingthe future position. If you only have a few simple movements possible (not arbitrary positions) just throw a predefined path at it.

author: rstofer
author_rank: Super Contributor
timestamp: October 01, 2019, 02:50:02 am
content: 'grbl' is a motion control system running on an Arduino to drive CNC machines. What is important is that the firmware looks ahead in the G-Code and uses that to control speed and acceleration such that it can cut into a corner without breaking the cutter. I don't know for sure but it seems like this control of overshoot is just what is desired. Controlled acceleration and deceleration.It also has motor current limit which might come in handy.Might be worth a read:https://jtechphotonics.com/Downloads/GRBL_Controller/Instruction_Manual_GRBL_Controller_V1_2.pdf

author: Mechatrommer
author_rank: Super Contributor
timestamp: October 01, 2019, 04:47:37 am
content: Using stepper motor as in gbrl or 3d printer is easy, no need pid control, all you need to do is preplanned/predefined motion. You send stepper pulses, it will go exactly to that position, no undershoot, no overshoot not even ringing (given no slip) thats why most engineers and hobbiests love stepper motor when it comes to position control, not even need close loop feedback. But for bigger lift/torque it will need tons of metal to build the matching stepper motor and hence costs an arm, not to mention rig and cement to support it. thats its drawback, poor torque/weight spec. Ymmv.

author: capt bullshot
author_rank: Super Contributor
timestamp: October 01, 2019, 05:38:46 am
content: Quote from: krisRaba on September 30, 2019, 08:51:09 pmSo two methods to deal with sampling intervals and pulses:- use an encoder with analog (sin/cos) output, that gives you theoretically unlimited resolution by calculating atan2()- use an additional hardware time to yield a high resolution time measurement from one pulse to the next pulse - some uC (maybe Infineon as I vaguely remember) have special internal connections to feed the QEI output to additional timers, not just the up/down counter. You might have to deal with interrupts not synchronized to your sampling / control loop period.Anyway, from my limitied knowledge, having an additional speed encoder, especially when your main encoder is a linear position scale, is rather common.For current sensing, in higher power / voltage servo controllers it's common to place the current sensing into the motor lines (up to three sensors for a 3 phase PMSM), so placing the sensor in the motor output (as you already have an isolated solution) might be the way to go. Regarding lower voltage setups, often shunts placed in the lower legs of the brigde are used, but this is for saving the isolation / differential amplification part, not for better performance.PWM is typically generated using a triangle style modulation (main counter is counting up and down, PWM egdes are placed on up and down ramps and can be updated at top and bottom count, current is sampled at top and bottom of the triagle. Any uC that says "Motor control PWM" in its features should be able to operate at least one timer unit in this mode. With maybe some additional skew adjusted to the inherent propagation delays of the system (H-Bridge and current sensor), this yields the correct average value of the motor current. Harmonics and stuff are filtered by the comb filter nature of this sampling arrangement.

author: filssavi
author_rank: Frequent Contributor
timestamp: October 01, 2019, 05:39:04 am
content: IMHO before embarking in a horrible journey through observers and model predictive controls, you should close the current loop, it is of vital importance for a smooth operation of a machine drive, as it can mask all the motor nonlinearities from the speed controller, that now it has the much easier job of controlling an ideal machine.This is fundamental for a good tunability of the outer loops, of course the bandwidths should be decreasing (usually by an order of magnitude or so) as you go from the inner loops outAlso for good operations on the entire load range of the machine you might want to add some adaptive paid parameter changes (easing the parameters when at full load for example),Hardware wise as job already said that current sensor really needs to be moved to the output, also you need a bipolar sensor as it is not guaranteed that the motor current will always run in the same direction

author: krisRaba
author_rank: Regular Contributor
timestamp: October 01, 2019, 09:05:20 am
content: Quote from: jbb on September 30, 2019, 11:21:30 pmYeah, higher resolution should reduce the problem because change in position will be noticed earlier and less correction action will be needed. But on the other hand higher resolution means being more sensitive to vibrations etc. I have noticed that with linear position encoder when changed 0,1mm to 0,01mm version. I have implemented plotting routine that outputs something if positions changes. After increasing resolution it was plotting almost all the time as it is hard to keep so precise position steady. Even stepping on other end of the room causes vibrations that change the position slightlyQuote from: jbb on September 30, 2019, 11:21:30 pmI will try to implement current sensing directly on motor. But I am still not sure if current control loop will work properly in vertical as UP and DOWN currents looks way different. But maybe it will handle that just like speed controller handles it without a problem.Quote from: jbb on September 30, 2019, 11:21:30 pmAt the moment I use top quality PSU which provides bang-on DC rail and even handles overvoltage caused by motor in regenerative breaking. I will consider it later because at cutting cost phase I will try to replace that expensive PSU to something little bit cheaper.Quote from: Mechatrommer on September 30, 2019, 11:39:31 pmThis is almost exaclty what I have. One missing component is the current control loop because I only use hardware comparators to limit current. I have to change current sensing circuit to make it bidirectional etc. as mentioned earlier.I have also found excellent example for S-curve calculation and it can be used for position point-by-point feeding. It determines initial and final position and additionally total time of movement. In spreadsheet it works very well.https://robotics.stackexchange.com/a/7503Quote from: Mechatrommer on September 30, 2019, 11:39:31 pmUhm, no thanksI would probably need another guy that loves that part who would model, simulate and prepare algorithms etc. I think it's important part when you want to do it REALLY right because with all that maths you can see traps that can occur in very specific situations. Unfortunately my mind is not so flexible after all these years. I could dive into that but it would take some time and give no pleasure, I thinkSo maybe I will stick to solutions for engineers, not for academic gurusQuote from: Someone on September 30, 2019, 11:48:21 pmSolution already found!Link to the formula added above.Quote from: rstofer on October 01, 2019, 02:50:02 amQuote from: Mechatrommer on October 01, 2019, 04:47:37 amI have already tested big stepper motor in that project and it is too slow. Stepper doesn't like high speeds because torque decreases very fast and when you try to go too fast with hugely decreased torque you can loose steps, produce a lot of noise etcMentioned controller uses dedicated drivers so it is a little bit easier because you provide command or DIR/STEP and you don't care, driver should follow and keep position. I try to control everything directly from MCU so my code should care about everythingBut maybe (if I understand it correctly that GRBL is an Arduino + shield with drivers) there is some open source code that can be used as a reference for movement planning... I assume there is no feedback and it works open-loop by forcing positions on drivers but there could be something interesting anyway.Quote from: capt bullshot on October 01, 2019, 05:38:46 amIt's "resolver", I think. AFAIK it is used in very precise drives. If my additional encoder on motor shaft will not do the job I will investigate that solution. Thanks for a hint!Quote from: capt bullshot on October 01, 2019, 05:38:46 amThis is also interesting. At the moment I use another timer as a time-base and it triggers input capture on QEI so I am independent from ISR execution delays in deltaT measurements.I will have to check if STM32 has some logic to forward edges to other timers. But IIRC it doesn't have anything like that and signals would have to be wired externally to work with two timers. In older MCUs it was a little bit better because you could route your input to more than one peripheral. Nowadays you can select only one Alternative Function and all you can do is to use internal inter-peripheral connections. It is less flexibleQuote from: capt bullshot on October 01, 2019, 05:38:46 amI have also seen that in many out-of-the-box controllers. It means it is not so stupid, maybe?Quote from: capt bullshot on October 01, 2019, 05:38:46 amI can put this current sensor anywhere which is a big advantage. The problem is with its output data acquisition. My MCU is 3.3V and sensor is 5V. Version for unipolar current is easy to adapt because you have small bias voltage, like 0.5V and it increases with current increase (with defined sensitivity) so when you use sensor with higher current range you can measure it directly and only limit the maximum voltage. With bipolar sensor it will be a little bit more complicated because Vbias=Vcc/2 so you have to scale bias and full range... but I will handle it somehow, I thinkQuote from: capt bullshot on October 01, 2019, 05:38:46 amI have noticed that many exaples use that kind of "phase-correct PWM" and didn't know why. Your explanation about current measurement points put some light and understanding and it corresponds to earlier suggestion that current should be measured twice per PWM period.But one error that pops up in my head is the current limiting by OCref CLEAR. For Brushed DC it's not so big problem that you will cut the cycle if current exceeds provided limit (comparator with blanking period) but in 3-phase BLDC and sinusoidal driving... but OK, it's not that case nowMaybe for BLDC I should use other methods of current control.So you mean that I should sample current on TOP and BOTTOM, and make an average Ia=(It+Ib)/2?Quote from: filssavi on October 01, 2019, 05:39:04 amI willQuote from: filssavi on October 01, 2019, 05:39:04 amYeah, I heard that. From my gathered information outer loop should be at least 2-5 times slower to avoid racing conditions etc. Should it be achieved by parameters tuning / decreasing gains or by varying sampling periods?Quote from: filssavi on October 01, 2019, 05:39:04 amI hope that some isolation between layers will able to handle that but we will see...Quote from: filssavi on October 01, 2019, 05:39:04 amYeah, I have already noticed that it wont. For steady state my current sensing works OK (so one direction, from V+ to the motor) but for high speed DOWN movement miracles happen and my current reading tries to go far below Vbias (<0.5V). I think that my unipolar sensor is bipolar in fact but has different bias circuitry that brings Vbias low so only unipolar currents can be seen on output.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 01, 2019, 10:45:17 am
content: Quote from: krisRaba on October 01, 2019, 09:05:20 amOk, it is not true anymore. I have found new serie of these sensors that is 3.3V compatible

author: IconicPCB
author_rank: Super Contributor
timestamp: October 01, 2019, 11:19:08 am
content: Trajectory planner is the name of the game.In absence implement a PID controller with Feed forward path.Divide the path You wish to traverse into a series od shorter segments.Treat the overall path as sum of small steps along the path.This way You can control the profile of the movement by implementing incremental changes in ( PID and Feedforward) positional SET POINT.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 01, 2019, 01:12:39 pm
content: 1) Add proper bipolar current sensing. Regenerative braking is still torque ~ current! No need to handle it differently.2) Sync current sensing to the PWM so you get right average (over the PWM cycle) current reading3) Tight and fast control loop for current. Typically a PI loop works. Measure the current with scope verifying your loop is stable.Only after this, start adding on the top.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 01, 2019, 01:36:38 pm
content: Ok, I have ordered bipolar ACS that outputs 3.3V range signalso I will be able to use it directly.My thoughts about current were taken from current configuration which works a little bit weird because there is no headroom in the Vbias to handle reverse currents. Maybe with proper sensor placement it will be obvious ;-)

author: capt bullshot
author_rank: Super Contributor
timestamp: October 01, 2019, 02:29:53 pm
content: QuoteFor 3-phase servos HW overcurrent detection is used for real overload and short circuit detection. Usually such kind of event shuts down the power stage, and some kind of manual restart is required. The current loop keeps the motor current within the operation range normally, there's no cycle-by-cycle current limiting as seen in current mode switchers. I'd expect an DC motor driven by an H-Bridge to operate in a similar way.Sampling at TOP and BOTTOM provides the average current for each (if done correctly), no need to average them. Usually it's used to virtually double the carrier frequency, since the control loop is executed once at TOP and once at BOTTOM and updates the PWM each time. This is useful for higher voltage / power application where you typically use switching (PWM) frequencies from 2kHz to 16kHz. If your PWM frequency is higher, you should be fine with one update per complete period or less.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.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 01, 2019, 03:40:54 pm
content: 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 theactualshort circuit, because the inductance is now bypassed and the protection should bereallyfast (microsecond range). For cost-cutting, it may make sense to decide not to support safe shorting of the output.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 01, 2019, 04:03:35 pm
content: Quote from: capt bullshot on October 01, 2019, 02:29:53 pmToday 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 pmI 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 solutionBut 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

author: jbb
author_rank: Super Contributor
timestamp: October 02, 2019, 07:31:36 am
content: 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 :-)

author: krisRaba
author_rank: Regular Contributor
timestamp: October 02, 2019, 03:08:11 pm
content: Quote from: jbb on October 02, 2019, 07:31:36 amThanks 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 amI use that method tooQuote from: jbb on October 02, 2019, 07:31:36 amIn 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

author: krisRaba
author_rank: Regular Contributor
timestamp: October 09, 2019, 07:56:08 pm
content: 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 valueAnd 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 variableAt the moment it works like a switching point but maybe I should use some kind of proportional change in wider range? I don't knowI 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!" occursAnd 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...

author: jbb
author_rank: Super Contributor
timestamp: October 10, 2019, 12:42:34 am
content: Quote from: krisRaba on October 09, 2019, 07:56:08 pmSwitching between sense modes does seeming something that makes a ‘bump.’ Maybe you can experiment? A ‘mixed’ region might be an option to improve matters if necessary. IE you could smoothly transition from delta pos mode to a mix of delta pod and delta time to full delta time.A current / torque control loop would indeed keep the same current setting between updates of the speed controller. (Look up Zero Order Hold if you’re interested.) Any changes in the plant mechanics (eg friction or changing load) will cause a change in speed that the speed control loop needs to deal with.

author: Kasper
author_rank: Frequent Contributor
timestamp: October 10, 2019, 03:39:36 am
content: Looks like you are well beyond my understanding of this subject but I'll share something simple that worked for me.I had to make a test set move air like human lungs. Was given a couple 2L syringes and a linear actuator with controller with speed input and position outputI used speed = sine(position) and added extra variables for tuning.That worked well enough but when I later saw a professional version I was jealous of its simplicity.It used disc and rod (like a train). They just needed steady motor speed and the disc smoothly changed the speed and direction of the rod. It also had easy and accurate way to set travel distance: connect the rod to holes at different radius on the disc.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 10, 2019, 04:59:18 am
content: Quote from: jbb on October 10, 2019, 12:42:34 amIf I recall correctly it was way below that crossover speed but thank you for your suggestion, I will check that twice to be sure. I think it is caused by non-constant update rate in delta pos method and for very low speeds update period is probably longer than control loop period so it becomes a little bit nervous that no reaction can be observed for previous demand ;-) I will try to check it somehow.And thanks for one more keyword. I will check what it stands for ;-)

author: krisRaba
author_rank: Regular Contributor
timestamp: October 10, 2019, 05:01:17 am
content: Quote from: Kasper on October 10, 2019, 03:39:36 amThanks for example. I also prefer situations where physics does the hard job, not calculations ;-)

author: IconicPCB
author_rank: Super Contributor
timestamp: October 10, 2019, 10:16:53 am
content: For the adventurous spirits forget PID nonsense... go straight to take back a half algorithm for those dificult to control processes.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 10, 2019, 10:52:11 am
content: Quote from: IconicPCB on October 10, 2019, 10:16:53 amWhat do you mean exactly? Any suggestions?

author: IconicPCB
author_rank: Super Contributor
timestamp: October 10, 2019, 11:23:31 am
content: Enjoy

author: krisRaba
author_rank: Regular Contributor
timestamp: October 10, 2019, 03:52:04 pm
content: Are you one of the authors?

author: IconicPCB
author_rank: Super Contributor
timestamp: October 10, 2019, 07:14:34 pm
content: No.I have however been interested in applying this algorithm for a while.So far I have had good success with PID with Feed forward in conjunction with incremental set point in a situation where conventional PID did not perform terribly well.The point to recognise is the micro provides a lot of flexibility so that the control strategy is no longer limited to prior art.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 11, 2019, 11:19:08 am
content: How exacly is feed-forward implemented in such situations? Is it some kind of OUTPUT = FF_VAL_CALCULATED_FROM_WHATEVER + PID_OUTPUT? And PID checks SP versus PV with such side-channel under hood, so PID only reduces error in FF_VAL_CALCULATED_FROM_WHATEVER estimation of output, and not full range of OUTPUT?

author: IconicPCB
author_rank: Super Contributor
timestamp: October 11, 2019, 06:58:05 pm
content: With PID a control loop is implemented such that an error value is processed by the PID algorithm and the output of the algorithm then controls the process.Feed forward is a very simple scaling of set point not error value followed by summation with PID algorithm output.The scaling is selected by observation of process response with PID set to minimum value.Set feed forward level to achieve best possible open loop performance and then close the loop via PID.Adjust FF then P, D and then I, if needed, in that order.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 14, 2019, 07:10:37 pm
content: Ok, thank you very much. I was close in my presumptions, I think, but you have made that even clearer :-)

author: krisRaba
author_rank: Regular Contributor
timestamp: October 16, 2019, 05:34:56 pm
content: Ok, when I started thinking about implementation of S-curves linked earlier I have calculated shape of velocity and acceleration and... yeah, right.. it will be nice and smooth move from point A to point B but there is no constant velocity region which is most important for meSo I need different equation for calculating that. I am not good in profiles generation and I am not sure how to do it exactly. The best solution would be the 7-region approach with linear ramps on acceleration. There are also cubic ramps but it will be too complicated, I think.It would be nice to specify max acceleration, max speed, start and landing points, total time of transition and maybe read/calculate from which time point velocity is linear and when it is not linear again at braking...I have found this articlehttps://www.researchgate.net/publication/278969938_A_complete_S-shape_feed_rate_scheduling_approach_for_NURBS_interpolatorand there is a section about S-shape profile generation. There are even equations for each region so it could be quite easily adapted, I think, but I will have to think how it should be implemented, for example by providing desired speed in constant region or total time? There should also be some verification point to decide if desired profile can be achieved on physical object etc.Any ideas?

author: krisRaba
author_rank: Regular Contributor
timestamp: October 23, 2019, 07:29:17 am
content: I have made a "proof of concept" with linear ramps on current changes and it shows that physics worksWith linear current (= acceleration) there are S-shapes visible on velocity plots.But I have some problems with current sensing, I think, or maybe it always is like that and only my lack of experience screams that current plot should be "cleaner". At the moment there is a lot of noise but it can be caused by long (but twisted) wires between ACS current sensor and MCU. Maybe it catches everything from air like antennaMaybe someone can confirm my setup:1. bipolar ACS current sensor is in serie with motor windings2. it has selectable bandwidth - 20kHz or 80kHz - I use 20kHz3. long twisted wires from ACS to MCU - to be fixed in next PCB release4. optional RC filter near MCU - currently bypassed because it introduces additional delay in feedback loop but maybe just ADC trigger should be delayed accordingly - simple 100R/100nF increases feedback delay from 2.4us to 8us, just to operate on real numbers5. ADC is triggered synchronously with generated PWM - in the middle of "ON" state delayed by 2.4us to compensate propagation delay on feedback signal (mainly caused by ACS) - sampling rate is thus 21kHz so I should increase it above 40kHz (Nyquist) for example by adding sampling also in the middle of "OFF" state or limit the bandwidth below 10.5kHz... What would be best here?On the DSO I can see the output from ACS and it is a rounded and skewed triangle plot. On my ADC readings it of course looks different because I try to sample once per period and I treat that measured value as an average. But real current fluctuates a little bit up and down between cycles so it is a thick line on DSO screen and of course my sampled "average" also changes between cycles so it is a "noisy" signal on data plot.From that point there is a small step to problems in current control loop. If I set parameters of current PI regulator to react slowly it rejects that noise but general response is veeery slow. If I set it to be more "nervous" and instantly follow PV changes motor starts to be audible and feedback noise excitates everything...What steps should I make to improve that closed current control loop?

author: capt bullshot
author_rank: Super Contributor
timestamp: October 23, 2019, 08:04:13 am
content: Quote from: krisRaba on October 23, 2019, 07:29:17 amInterestingly, this is a common issue with motor phase current measurement in 3ph Servos too. More interstingly, the large servos can cope quite well with this noise and still act dynamically, I believe it's also a matter of physics because large motors have large inertia. It's all a matter of physics and control loop parameters. Typically, any servo drive must optimize it's parameters to the system.Anyway, from a HW point of view:- look for common mode noise coupled from the high du/dt motor voltage into the small signal current measurement. Twisted pair is a good approach in the first place. Sometimes you get noise injected into the sensors output within the sensor itself, you cannot do too much about it but taking care of a good (solid / massive) grounding the sensor to a quiet low impedance ground or choose a better CMRR sensor.- look for non-current sensor related issues in the signal path - often one can see badly designed ADC input circuitry and decoupling with MCU integrated ADCs - good layout and clean supplies, proper low impedance decoupling GND plane etc. are as important for a clean signal as the design of the sensor itself.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 23, 2019, 08:51:02 am
content: Thanks for these suggestions. I have already extended my TODO list to improve ACS power supply filtering as well because AFAIK it produces ratiometric output so any noise on its VCC will be reflected in output signal, I think. "CMRR" doesn't exist in ACS722 datasheet so I am probably right about its rule of operation. At the moment there is some foil cap in THT for VCC decoupling because it was easier to install so in final design I will replace it with low ESR mlcc 100n+1u and maybe ferrite bead.AVCC which is also AREF in this MCU is already quite well filtered, I think.My particular DC motor has rather low rotor inertia itself - 72.8gcm2 - and what is also important (I suppose) it has quite low windings inductance - 0.103 mH - so current will be less filtered than in high inertia, high inductance models and motor will react faster to any changes on input.What it interesting, original motor controller that can be purchased with that motor uses 50kHz PWM, 25kHz current PI loop, 2.5kHz speed PI loop and 2.5kHz position PID loop. In some NXP article I have found a note:Quoteand my DSO shows rounded and skewed triangle on ACS output, as mentioned earlier... Maybe they have increased PWM frequency to get more linear current transitions? I don't know. Or maybe it is only a matter of limited bandwidth?

author: jbb
author_rank: Super Contributor
timestamp: October 23, 2019, 09:36:18 am
content: Glad to hear it more or less works. It’d be nice to see some photos of the setup if you’d be so kind.I suggest you try sampling the ADC at twice the sampling frequency. Then you can quite simply average the two samples and feed that into your current controller, which hen runs at 1x PWM frequency.If you then want to try more, you could try a modified PI controller. Keep the integrator part as normal, and add a low pass filter to the proportional part to knock down the high frequency gain a little. (Rationale: the integrator has a 90 degree phase lag. If you simply low pass filter the current the you add filter phase lag to the integrator phase lag and could have trouble.)

author: IconicPCB
author_rank: Super Contributor
timestamp: October 23, 2019, 10:33:32 am
content: Place an inductor in series with the motor to achieve required electrical time constantwith motor

author: Siwastaja
author_rank: Super Contributor
timestamp: October 23, 2019, 11:50:19 am
content: If getting the correct & accurate average current is an issue due to large current ripple, or running in DCM (at low currents, in "diode emulation mode"), use an MCU with high enough sample rate ADC, and sample several times during the PWM cycle. For example, I have done 2 x 8 samples/cycle in a 140kHz dual converter no problem using STM32F334, averaging in software. With motor control frequencies (say < 50 kHz) and only one channel required, it should be trivial to go for, say, 32 samples/cycle. Some ADC peripherals offer oversampling in the peripheral itself (accumulating in the data register). This will reject switching noise as well, unless the spikes are truly massive.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 23, 2019, 02:57:43 pm
content: Quote from: jbb on October 23, 2019, 09:36:18 amMaybe with next release. Now it looks horribleQuote from: jbb on October 23, 2019, 09:36:18 amThat is a good idea and easy to implement. I will try that.Quote from: jbb on October 23, 2019, 09:36:18 amYeah, some time ago I have noticed that too much lag causes strange bahavior which is quite obvious because reaction is made against something that is not true anymore in realityQuote from: IconicPCB on October 23, 2019, 10:33:32 amYou are right, I have noticed today that original controller has specified built-in motor choke of about 9uH and I have found FAQ document with some formulas to check if additional external inductor is needed. And what even more interesting, they claim that for calculations only 30% of inductance from datasheet should be used because it is measured with 1kHz sine and effective inductance for higher freq square is 30-80% of thatSo I plan to add 4,7uH to each H-bridge output. I was looking for some info about type, whether it should be CM choke or DM (not coupled inductors) and I am still not sureBy intuition DM... But I have also found some standard solutions with 220uH CM and 82uH+RC to groundThe best way to check would be to play around and swap some components, maybe there will be some spare time to do thatQuote from: Siwastaja on October 23, 2019, 11:50:19 amYes, I think that my F303 could also handle that. I will check the results with simplier solutions and if it fails I will try more sophisticated ones..In the meantime I have switched to 50kHz PWMIt works (without current control loop at the moment) but I have to check some bad things on output signals. From very quick investigation I think that ringing on MOSFET gates causes cross-conduction for short moments so motor works but H-bridge becomes hot...

author: capt bullshot
author_rank: Super Contributor
timestamp: October 23, 2019, 04:05:42 pm
content: CM inductor is useful for EMI mitigating purposes, but it's magnetizing inductance isn't added to the motor inductance since the motor current cancels out. Only the stray inductance will add to the motor inductance.I've seen designs adding a small value inductor (e.g. 4.7uH) to each H-Bridge output - it's purpose is to limit dI/dt to some value the short circuit protection can handle. Depends on the ruggedness of the MOSFETs and the speed of the short circuit protection (if applicable). Also helps with capacitive charging currents of longer motor cable runs.If you want to use higher switching frequencies to lower the ripple, your current control loop still can run on a lower frequency (if computing power is the limit) - a faster loop would still run with the same bandwith required by the system, doing more computation than necessary. Oversampling and averaging or downsampling (filtering) is a good measure to reduce noise and increase resolution, as long as you can meet your bandwith requirements.Driving a MOSFET H-Brigde requires tuning and low impedance layout for best performanceCross-conduction is rather easy, just increase the dead band. Diode recovery and ringing can be way more nasty, try slowing down the switching by increasing the turn-on gate resistors, keep turn-off fast - or try to find a very narrow dead band configuration that avoids MOSFET body diode conductance and switches fast. The latter one is difficult to maintain over a wider range of DC-Link voltages and loads characteristics.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 23, 2019, 06:39:56 pm
content: First thing I have to check is raw MCU output. I was a little bit surprised about its shape. Maybe it was some kind of ringing but looked like short turn off during ON state :-| On 21kHz everything looked perfect, I think, so it is strange that it behaves so different.. but I have to double check as it was just quick test before turning everything off ;-)

author: jbb
author_rank: Super Contributor
timestamp: October 23, 2019, 07:30:37 pm
content: Quote from: krisRaba on October 23, 2019, 02:57:43 pmI gotta say, cross-conduction (aka shoot-through) is bad at any switching frequency. You should check for that; it might be fixable by adjusting the gate driver circuits.Also, do you really need 50kHz PWM? Assuming the same H Bridge, higher switching frequency will always lead to higher switching losses. Also, laminate iron rotors will tend to show lower effective inductance (and higher iron losses) at higher switching frequencies.

author: capt bullshot
author_rank: Super Contributor
timestamp: October 23, 2019, 07:36:22 pm
content: Interesting - some kind of timer misbehaviour? Do you use the capture/compare shadow / buffer registers (don't remember real name in the datasheet and ATM I'm too lazy to look that up) so the PWM values get updated at the correct sampling point?I've experienced some weird effects with STM timers, usually I could resolve them by checking and fixing my codeFrom my experience, it's highly recommended to handle the bare metal timer, not to use ST HAL code. It's way more efficient and you've got to debug your own code only. Since I'm lazy, usually still leave the basic initialization to Cube/HAL, but no more HAL once it's up and running, especially within timing critical interrupts.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 23, 2019, 08:19:57 pm
content: Quote from: jbb on October 23, 2019, 07:30:37 pmI have to investigate what is the real source of that problem. Power section is quite nice layed-out, I think. It is not my design but I would give a thumb up for that part of PCB to my colleagueAnd the problem was also observed on MCU side, before isolated gate drivers, so I presume it just follows junky drive signals. These lines are quite long and one of them is rewired near gate driver because I had to do some pin re-arrangements to free additional hardware connections. But it worked perfectly with 21kHz and 50kHz doesn't sound like astronomic changeQuote from: jbb on October 23, 2019, 07:30:37 pmI don't know, just to be honestCompany that designed these motors and controllers doesn't hire idiots.. I hopeIt's rather top brand. These motors and controlers are designed to work together and their controllers use 50kHz and other parameters that I have already mentioned. So I think there is important reason for that.I have already mentioned effective inductance and it looks like they know about that problemAnd this is why they suggest to use 30-80% of its value in calculations...Generally I have to check if there is any significant improvement in current ripple. I couldn't hear any difference in motor sound when working at 21kHz and 50kHz, no resonances, buzzing etc. in both situationsI usually use 21kHz just to go above audible range but their 50kHz tortures my brainQuote from: capt bullshot on October 23, 2019, 07:36:22 pmI use HAL only for GPIOs init because in CM4 it is designed so strange that it would be hard to write simple macro to set that and this is done only once at startup. Other things usually controlled in "bare metal" on registers. I use "preload" on all CCR registers so it's not that. And nothing was changed here between 21kHz and 50kHz.Of course before blaming MCU vendor I always study datasheet, my code, datasheet, and so on..But to still have good resolution after increasing output frequency I have switched clock source from PCLK2 to 2xPLLSo now this timer runs at 144MHzBut datasheet claims it can handle thatTBD in reality

author: capt bullshot
author_rank: Super Contributor
timestamp: October 23, 2019, 09:14:26 pm
content: QuoteGood luck, I'm quite confident you're able to find the root cause.Need 50kHz or not: No idea, except higher switching frequency allows for lower inductance. That particular motor indeed is pretty low inductance, so 20kHz to 100kHz looks appropriate for a rated 100uH / real 30uH. Not a big deal for modern MOSFETs.Running the timer @ 144MHz: should work if the datasheet says so

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 08:35:21 am
content: Ok, problem solved and actually it was something stupid ;-) I forgot that value written to BDTR (DTG) register to set deadtime is related to timer clockso after increasing clock frequency effective deadtime was decreased proportionally ;-) After increasing it as well power stage is cool as usuallyAnd signals from MCU looks ugly now.. but only with ground lead ;-) With spring ground connection on probe it is OK.But I will think about decreasing gate resistors a little bit. Now 10R is used so small bannana shape is visible on gate charging and discharging. Or maybe I will add diode+resistor in parallel just to turn it off faster and keep slower turn on time because of EMI...And what is most important current ripple significantly decreased with 50kHz PWM ;-) I wonder what will be the effect of additional chokes in serie, it should be even better ;-)

author: capt bullshot
author_rank: Super Contributor
timestamp: October 24, 2019, 09:20:47 am
content: Quote from: krisRaba on October 24, 2019, 08:35:21 amBusiness as usualQuoteBusiness as usualQuoteI've seen higher gate resistances working just fine - depends on the MOSFETs and it's just the usual power dissipation vs. EMI tradeoff gameQuoteBusiness as usual

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 10:00:24 am
content: Quote from: capt bullshot on October 24, 2019, 09:20:47 amYes, I know. I have seen even 100R in ST BLDC controllerWorked well with 6-step but it was a tragedy when I was trying to implement sinusoidal driving and had to be reducedSo it also depends on control scheme and your needs. But I am also aware that high rise times look good on DSO but are your enemy in EMIBut on other hand additional inductance should add some slopeI have just checked that driver already has 5R of internal resistance for LOW TO HIGH transition and 0.55R for HIGH TO LOW transition so it is already asymmetric. I will leave that for further testing in the futureQuote from: capt bullshot on October 24, 2019, 09:20:47 amI have added 2x 4,7uH in series with motor windings and just as expected, current ripple has been decreased. It is not enormous change, something about 25%, but always something is better than nothingDoes it mean that effective inductance of motor is about 37,6uH? I think so and it sounds quite realistic. It would be 36,5% of 103uH presented in datasheet and they were talking about 30-80% for calculations..

author: capt bullshot
author_rank: Super Contributor
timestamp: October 24, 2019, 10:11:44 am
content: Quote from: krisRaba on October 24, 2019, 10:00:24 amYes, I'd agree using the same rough (and probably incorrect) calculation pointing to the ballpark range. Good enough for a plausible estimate.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 11:03:00 am
content: Quote from: capt bullshot on October 24, 2019, 10:11:44 amThe formula from mentioned earlier FAQ is ΔIppmax=Vcc/(2*Ltot*freq), where Ltot=Lint+0.3..0.8*Lmot+Lext, freq in , so it can be correctly estimated that way, I think. Given change in ΔIppmaxis caused by given change in Ltot, the rest is kept unchanged.

author: capt bullshot
author_rank: Super Contributor
timestamp: October 24, 2019, 11:50:17 am
content: Quote from: krisRaba on October 24, 2019, 11:03:00 amOkay, I did a very simple linear calculation without even looking at that formula you mentioned (4.7uH * 2 * (1/0.25)) ( = 37.6 uH). So I can't be horribly wrong

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 12:39:32 pm
content: Quote from: capt bullshot on October 24, 2019, 11:50:17 amYeah, this is how I did it at the first time as well - value estimated just from proportionsThen I only posted my response to your "(and probably incorrect)" senstence to show it doesn't have to be wrong because in mentioned formula relation is also linear (so no sqrt or ^2 etc)

author: capt bullshot
author_rank: Super Contributor
timestamp: October 24, 2019, 12:54:56 pm
content: Quote from: krisRaba on October 24, 2019, 12:39:32 pmYes, linear the relation is, no doubt, so linear estimation is correct. I'm still wondering if the ratio applied (1/ 0.25) is correct for this kind of relative change, or if I have to apply something like 1/x or (1 - x) on the 25% change, but meh, it's just an estimate, and I'm not in the mood to think about basic math

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 01:30:33 pm
content: Quote from: krisRaba on October 24, 2019, 11:03:00 amYou have two situations:ΔIppmax=Vcc/(2*Ltot1*freq) -> without additional inductance, Ltot1= Lmot_eff, where Lmot_eff= (0.3..0.8*Lmot)and0,75*ΔIppmax=Vcc/(2*Ltot2*freq) -> with additional inductance (Lint=2x4,7uH), Ltot2=Lint+Lmot_eff, where Lmot_eff= (0.3..0.8*Lmot)then you can replace ΔIppmaxin second one with the first one, so you get0,75*(Vcc/(2*Ltot1*freq)) = Vcc/(2*Ltot2*freq)and then you can remove things that are on both sides by multiplying both sides of the equation with (2*freq/Vcc) so this is what remains0,75/(Ltot1) = 1/(Ltot2)so finallyLtot1= 0,75*Ltot2so(Lmot_eff) = 0,75 * (Lint+Lmot_eff)(1-0,75)*(Lmot_eff) = 0,75 * Lintuhm.. s#!t..(Lmot_eff) = 0,75 * Lint/ 0,25 = 0,75 * 9,4uH / 0,25 = 28,2uH... ekhm... something is wrong hereEh, whatever

author: capt bullshot
author_rank: Super Contributor
timestamp: October 24, 2019, 01:37:18 pm
content: At least, 28.2 is a 25% error from 37.6 - perfectly matches the 25% lesser ripple. ROFLMAO and as I said - can't be horribly wrong and doesn't really matter for an expected 0.3 to 0.8 range of 100uH. Math is an asshole

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 01:50:08 pm
content: Oh, interesting.. there was an error in previous estimation, I think, because when you compare results for calculations of ΔIppmaxwith Ltot1=Lmot_eff=28,2uH and with Ltot2=9,4+Lmot_eff=9,4+28,2=37,6uH ratio is 75% as it should.When you take Ltot1=Lmot_eff=37,6uH and Ltot2=9,4+Lmot_eff=9,4+37,6=47uH ratio is 80%

author: capt bullshot
author_rank: Super Contributor
timestamp: October 24, 2019, 02:03:46 pm
content: I never stated whether 37.6uH is the total or motor only inductanceIn fact, I believe I thought of it as the total inductance.If you have a decent current probe in your lab, you can verify the theory by a practical measurement (calculate inductance from applied voltage step and current ramp over time). Kind of real time math, I like it that way, let the physics do all the hard calculation work in real time, and observe the results by accelerated electrons based (or a modern solid state variant) visualisation.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 24, 2019, 07:49:17 pm
content: I have to limit things that are not usefull in problems solving. Estimated value sounds realistic, current ripple decreased and along with 50kHz PWM looks much better on DSO nowSometimes it is good to know some details, sometimes I am just curious and I dig a little bit deeper than needed but generally I have to move forwardI think that it will be good to oversample and average current for smoother readings so I will try to sample in the middle of ON and OFF states (=100kSPS) and skip every second cycle in calculations (=25kHz), as in original controller, so I will have 4 samples to average before each current control loop call

author: krisRaba
author_rank: Regular Contributor
timestamp: October 25, 2019, 04:52:41 pm
content: Quote from: krisRaba on October 24, 2019, 07:49:17 pmDone!Maybe except "control loop call"But I have finally changed edge-aligned PWM to center-aligned mode, configured additional channel in asymmetric mode to generate TRGO2 with controlled delay that compensates feedback loop lag, and some additional "magic" on ADC to get 4 samples before interrupt that will execute current control loopA lot of tests performed to check all that synchro on DSOand it perfectly hits defined momentsGosh, I love flexibility of these MCUs

author: capt bullshot
author_rank: Super Contributor
timestamp: October 25, 2019, 06:26:01 pm
content: Great!I like to follow your progress, and I acknowledge you focusing on the main progress. Often interesting details can distract from the actual work to do, I know this quite well.

author: krisRaba
author_rank: Regular Contributor
timestamp: October 25, 2019, 07:53:12 pm
content: Nice to hear that ;-) I can still see a lot of views but visitors muted their keyboards ;-) So I was wondering if they are already boredor it's an effect of overwhelming calculations expanding to full screenI have to admit that many times when I open some document and see all these formulas I get a headache ;-) and feel high pressure to click But this forum is great anyway because on some other I usually talk to myself, no response at all ;-) It also helps sometimes because I have to explain something and some ideas sprinkles when I have to organize information but it is always more interesting with any interaction ;-)

author: capt bullshot
author_rank: Super Contributor
timestamp: October 25, 2019, 08:03:36 pm
content: Quote from: krisRaba on October 25, 2019, 07:53:12 pmYes, I know. I've opened a small number of threads regarding my private projects (rather presenting some results and linking to my homepage than asking for a particular help, but interested in comments), get visitors and a few comments, but forgotten after a few days.Your project and thread is quite interesting, making a motor controller from scratch and you're not a pointless beginner asking very basic questions showing no knowledge at all. More like a dialogue with an fellow engineer. Such a dialogue is a source of inspiration and whatever ...

author: krisRaba
author_rank: Regular Contributor
timestamp: October 25, 2019, 08:42:58 pm
content: So thumbs up for all "fellow engineers" that pushed this issue forwardEven if responses count fades out quite a lot of usefull hints have been posted so farAnd of course it's not over yet