Problems with STM32 PMSM FOC SDK

[tatus1969]

you can check the phase current, ia ib, if they are constantly rising in that situarion, it would be another hint of a count mismatch.

[Dave_PT]

there is only one reason for this that i can think of: the encoder does not do 500 counts per mech rev. even 501 or 499 would lead to exactly this result.

I will program a MCU to communicate with the encoder.
So I can analyze what the registers have.

[tatus1969]

another remaing thing from a previous post that came into my mind again: did you check that the shaft becomes stiff during (slow 5 seconds) encoder alignmen?t it should not be possible to easily turn it by hand after current has ramped up. i would check that without gearbox.

[Dave_PT]

another remaing thing from a previous post that came into my mind again: did you check that the shaft becomes stiff during (slow 5 seconds) encoder alignmen?t it should not be possible to easily turn it by hand after current has ramped up. i would check that without gearbox.

I already tested it and I can not turn the shaft by hand.

So far, the encoder registers are fine to work ...

I do not know what I can do...

[Dave_PT]

The problem is somehow related with PI gains ...

I made some adjustments here and the motor can keep up the speed ... but after a few minutes it starts to oscillate brutally ...

Could it be related to the encoder?

The motor was running smoothly for about 95 seconds and then began to oscillate ...

[tatus1969]

The problem is somehow related with PI gains ...

I made some adjustments here and the motor can keep up the speed ... but after a few minutes it starts to oscillate brutally ...

Could it be related to the encoder?

The motor was running smoothly for about 95 seconds and then began to oscillate ...

What happens when you run it sensorless? Does it run stable over time, does it produce torque over time? If all is yes, then I am sure that it must be related to the encoder feedback.

Is it possible that you have an EMC problem on the encoder signals, that is causing the microcontroller to count incorrectly? You can check this by adding small capacitors to the encoder signals (maybe 100pF to 1nF) and see if the behavior improves.

Generally, when I set up the controller gains for FOC, then I do it like this:
- operate in torque mode, and program a rectanguar torque(current) command, maybe 10 to 50Hz in frequency. Adjust system input voltage to max rated.
- configure virtual rotor position feedback to make sure the motor cannot spin.
- measure current of phase U, preferably with current clamp and oscilloscope.
- set integral term to 0, raise proportional term in steps, until the scope starts showing overshoot of the current signal.
- step back a bit with proportional term (I prefer using 50% of final value)
- start raising integral term, until it starts overshooting again
- step back a bit with integral term (again 50% of final value)

Now you can be sure that the current control loop is stable.

Then, the same for velocity control loop:
- use your real rotor phase feedback now
- add all inertia to the rotor shaft that will be present in the system later on
- make sure that regerative operation does not cause overvoltage, as the following test will do that
- program a rectangular velocity command profile, maybe 0.2 Hz, having the velocity switch between two different values. They can be close to each other, maybe 1000 rpm and 1500 rpm.
- monitor velocity value via STM32 DAC feature
- now tune proportional and integral terms of velocity controller the same way as explained above.

This should result in a rock stable system with highest possible dynamic response.

[Dave_PT]

Is it possible that you have an EMC problem on the encoder signals, that is causing the microcontroller to count incorrectly? You can check this by adding small capacitors to the encoder signals (maybe 100pF to 1nF) and see if the behavior improves.

It is a random situation.
For example, the motor was running for more than 15min without any problem ...

I will add the capacitors in the feedback traces 

Next I'll start doing the process that you recommend.

Thank you.

[tatus1969]

Is it possible that you have an EMC problem on the encoder signals, that is causing the microcontroller to count incorrectly? You can check this by adding small capacitors to the encoder signals (maybe 100pF to 1nF) and see if the behavior improves.

It is a random situation.
For example, the motor was running for more than 15min without any problem ...

I will add the capacitors in the feedback traces 

Next I'll start doing the process that you recommend.

Thank you.

does this happen with sensorless feedback?

[Dave_PT]

Nope.

This erratic behavior only happens with the magnetic encoder.

In sensorless had no problem.

I've already put the capacitors and I'll let the motor run until I'm gone, to see if there's any problem.

[tatus1969]

Nope.

This erratic behavior only happens with the magnetic encoder.

In sensorless had no problem.

I've already put the capacitors and I'll let the motor run until I'm gone, to see if there's any problem.

if the problem remains, it would be interesting to see "Ia" via DAC, that should be a stable sine and only increase with load. if it ramps up even at idle it would be a strong hint to encoder problems.

[Dave_PT]

Everything is already tuned and I am already meeting the minimum operating conditions.

However at low RPM I get some instability (<400RPM) ...
Is it because the motor has only 2 pairs of poles?
If the motor had more pairs of poles, would I be able to control better at low speeds?

[tatus1969]

Everything is already tuned and I am already meeting the minimum operating conditions.

However at low RPM I get some instability (<400RPM) ...
Is it because the motor has only 2 pairs of poles?
If the motor had more pairs of poles, would I be able to control better at low speeds?

How does the instability show? Can you measure rpm fluctuations? Or is it just audible? How does the motor react to instantaneous velocity setpoint changes, is it free from overshoot?

Generally it depends on how you run the motor:
- sensorless: there is a certain minimum speed for the rotor angle estimator to run properly.
- sensored: no theoretical minimum speed. But in reality it depends on the sensor's angular resolution. Yours @400/rev should be fine even at very low rpm.

In either case, the way in which the FOC library represents mechanical velocity has some limitations. As you know, they implemented everything with fixpoint integers. For these values, they did not choose the format very wisely, the numerical representation is in 1/10th of Hertz, or 1/10th of mechanical revs per second. For extreme low speed situations, this can lead to noticeable quantization errors, which is maybe what you notice.

I think that there is a way to work around this (have not tried yet though). As this is mechanical revs, you can "push" the resolution by telling the library that you have a motor with 20 pole pairs instead of 2, and also tell it that the encoder has 4000 steps per rev, instead of 400.

[tatus1969]

I think that there is a way to work around this (have not tried yet though). As this is mechanical revs, you can "push" the resolution by telling the library that you have a motor with 20 pole pairs instead of 2, and also tell it that the encoder has 4000 steps per rev, instead of 400.

this is stupid, because it decreases the calculated mechanical velocity, instead of increasing it. Forget about that idea....

[Dave_PT]

How does the instability show? Can you measure rpm fluctuations? Or is it just audible? How does the motor react to instantaneous velocity setpoint changes, is it free from overshoot?

I have fluctuations in RPM...
But if I tune PI gains for minimum possible instability at low rotations, it becomes very unstable at high revs (high revs>400).

This is the speed chart at 200RPM.


Here you can see a video of the behavior of the motor. Initially the motor is running at 1000RPM and then ramps in 10s to 100RPM.
Can it be the backlash that contributes to this?
Does it happen because there is no load on the motor shaft?

https://meocloud.pt/link/07993c73-7c99-4012-bb97-8ee4c9c1b897/VID_20170301_093623.3gp/

[tatus1969]

is it running sensorless or with incremental encoder? That would be very important to know now. For sensorless operation, that would not be surprising. IF you are running with incremental encoder, I would suspect that this is pure velocity control loop instability.

You say that there is no load at the motor. Actually, this is not pointing in the right direction when we are talking about control loop stability. It is not the load that affects stability. That only shifts the setpoints to different values, but it does not change the dynamic behavior. It is the inertial momentum that you need to look at. And you added a lot of that with that large and heavy wheel. My question is: did you do the velocity control loop tuning with that wheel? you definitely need to.

Backlash... your setup looks like it is using a precision planetary gear, is that right? If so, I would expect that the backlash introduced by the reduction gear should be negligible. And, if the velocity control loop is stable with maximum inertial momentum at the shaft, then it cannot become unstable again by adding backlash (unless you would measure velocity after the gear, which you don't). You can consider backlash as a disturber, leading to reduced precision, like a hysteresis.

But if I tune PI gains for minimum possible instability at low rotations, it becomes very unstable at high revs (high revs>400).

This sounds like that you have a certain range of PI gains that are stable. You should only observe instability when gains are too high, it should not be possible to cause instability when gains are too low.

[Dave_PT]

is it running sensorless or with incremental encoder? That would be very important to know now. For sensorless operation, that would not be surprising. IF you are running with incremental encoder, I would suspect that this is pure velocity control loop instability.

I'm always using the incremental encoder.
I hope this magnetic encoder is not disturbing ...

You say that there is no load at the motor. Actually, this is not pointing in the right direction when we are talking about control loop stability. It is not the load that affects stability. That only shifts the setpoints to different values, but it does not change the dynamic behavior. It is the inertial momentum that you need to look at. And you added a lot of that with that large and heavy wheel. My question is: did you do the velocity control loop tuning with that wheel? you definitely need to.

Yes.
All calibrations were made with the wheel.
The wheel is very light, all made of plastic and rubber, and has a diameter of 20cm.
The motor has 110W ... a wheel of this size and weight should not be a problem.

Backlash... your setup looks like it is using a precision planetary gear, is that right? If so, I would expect that the backlash introduced by the reduction gear should be negligible. And, if the velocity control loop is stable with maximum inertial momentum at the shaft, then it cannot become unstable again by adding backlash (unless you would measure velocity after the gear, which you don't). You can consider backlash as a disturber, leading to reduced precision, like a hysteresis.

The gear box is planetary, but the connection of the wheel to the shaft has a small gap. However I will solve this to be able to test better.

But if I tune PI gains for minimum possible instability at low rotations, it becomes very unstable at high revs (high revs>400).

This sounds like that you have a certain range of PI gains that are stable. You should only observe instability when gains are too high, it should not be possible to cause instability when gains are too low.

You are right.
But at low rotations I need to increase the gains so that the rotation is more stable. Approximately I have to triple the PI gains to have stability below 400 / 300RPM.

Can current PI gains have any influence?

[tatus1969]

I'm always using the incremental encoder.

happy to hear that, the last that I noticed was that you were having trouble with it

I hope this magnetic encoder is not disturbing ...

I doubt that, but you could check it by operating the motor in "stepper motor" style, and watch the output from the encoder via DAC. To test that, this is the hack I normally do:

file MCTasks.c

Code: [Select]

uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));
  static int16_t k=0; k+=10; hElAngledpp=k; // <<<<<<<<<<<<<<<<<

 ...
} 

Then, start the motor in torque control mode, and apply some current (the more the better, as you want to check for EMI probems ). The motor should turn slowly and smooth. The DAC should show a clear sawtooth.

All calibrations were made with the wheel.
The wheel is very light, all made of plastic and rubber, and has a diameter of 20cm.
The motor has 110W ... a wheel of this size and weight should not be a problem.

It's not a matter of power, control loop stability depends on the characteristics of the controlled system. There you look for gains and time constants. The gains are bus voltage and motor ESR (torque system), and motor kV (velocity system). The time constants are motor inductance (torque system), and rotating mass inertia (velocity system). I hope I haven't forgot anything... As this is a cascade of two control loops, the inner one will also cause additional delays, but normally the current control loop is at least one order of magnitude faster than the velocity control loop, so I try to treat them as independent to keep things simple.

But as you said you have tuned the loops with the wheel. Do you have oscilloscope diagrams of the step response of both loops? Maybe that could give me a clue of what's happening.

at low rotations I need to increase the gains so that the rotation is more stable. Approximately I have to triple the PI gains to have stability below 400 / 300RPM.

That is really strange. Can you once try a controller without integral term? Does the instability disappear? How far can you increase the proportional term until you start noticing instability? My suspicion here is that the I term is too high to be able to handle the wheel's inertia. Another thing worthwile trying: remove the wheel and check if that leads to better stability.

Can current PI gains have any influence?

As mentioned above, theoretically yes but I would expect the current control loop to be much faster than the velocity control loop. That could be easily checked if you could post some pictures from current and velocity step responses from your calibration.

[Dave_PT]

But as you said you have tuned the loops with the wheel. Do you have oscilloscope diagrams of the step response of both loops? Maybe that could give me a clue of what's happening.

The current step response graph is more complicated to obtain.
Here is the speed response step response graph (for 1500RPM).
Y - rotor speed


Here is the current response step response graph, Iq (for 3Amps). NOTE: I have some oscillation in current control...
Y - Iq current

Can you once try a controller without integral term? Does the instability disappear? How far can you increase the proportional term until you start noticing instability? My suspicion here is that the I term is too high to be able to handle the wheel's inertia. Another thing worthwile trying: remove the wheel and check if that leads to better stability.

Rotation setpoint = 100RPM
Without integral control (Ki = 0) the motor only starts to run with Kp equal to 25000/128. But when the motor starts to run, it is unstable.
I used a Kp = 12000/128 and started to increase Ki to get the error overridden.
With Ki = 10/4096 the motor does not run, but with Ki = 100/4096 the motor starts to rotate but in an unstable way ...

However, more and more I am sure that the "shakes" in the rotation are caused mechanically.

I'm going to run some more tests to try better understand what's going on ...

[tatus1969]

Here is the speed response step response graph (for 1500RPM).
Y - rotor speed

That looks very reasonable, the time constant is roughly 30ms. Which is quite fast considering that large wheel. But this also makes me think that it is unlikely that your low-rpm oscillations would be caused by instability of the velocity controller. That oscillations were way slower. Which brings me back to the start --> 

Y - Iq current

The step response shows very large overshoot here (50 % or so?), I suggest to reduce gains until you are completely free from that. It is not possible to judge the time constant from that picture, maybe 2 ~ 5ms. I would say that is fast enough to assume that there will be no interaction with the velocity controller.

But what really concerns me is the very slow decay at 60ms. What command has been given there? Did you just set the current setpoint to zero? If that is the case (I assume for now), I would have expected a step response that is as fast as the one before (@20ms). Something is wrong there. The oscillation also should not be there. It looks as if the power stage is not controlled correctly. Are the low-side transistors working as expected? When the power stage is on, each leg must always be active, so either H or L side transistor conducting. You should never see both transistors of any leg in OFF stage (except of course deadtime during switching).

[Dave_PT]

I'll take a look at everything again and do what you recommend.

It seems to me that the problem is the motor and gearbox.

Watch this video. Reduction of 2000RPM (motor)/~ 69RPM (after gear box - wheel) to 100RPM (motor)/3.45RPM (after gear box - wheel) in 25sec.

It appears that the control powers the motor to overcome the inertia of a pole and when it rotates. The next magnet attracts and the control has to reduce power quickly ... and so on.
I think it's something related to this ...

Now my speed control loop is 3mS and the current control is 4 times the pwm period.

VIDEO: https://meocloud.pt/link/89ac0711-c8c1-4a29-956a-016925fd7074/VID_20170302_122155.3gp/

[tatus1969]

Rotation setpoint = 100RPM
Without integral control (Ki = 0) the motor only starts to run with Kp equal to 25000/128. But when the motor starts to run, it is unstable.
I used a Kp = 12000/128 and started to increase Ki to get the error overridden.

If the motor does not start with only proportional term, then give it a higher speed setpoint, e.g. 1000 or 2000 rpm. Then the motor should start and you can find the correct Kp value. Only then start increasing Ki.

With Ki = 10/4096 the motor does not run

This should never be possible. The integral term of the controller will always deliver maximum torque after some time (it takes longer, the smaller Ki is). You must always be able to start the motor with Ki > 0, even when Kp=0. (It will not be stable though). Again, also here I suggest using a larger speed setpoint.

[tatus1969]

It appears that the control powers the motor to overcome the inertia of a pole and when it rotates. The next magnet attracts and the control has to reduce power quickly ... and so on.
I think it's something related to this ...

it seems that the "oscillation" correlates with the electrical rotor angle. But I think that the root cause must be somewhere else. Maybe the magnetic encoder. Did you check that all three driver legs are working properly? Are all current sensors giving correct readings?

Basically, the FOC library produces a clean and perfect sinusodial rotating field. If the motor is constructed as a PMSM, then you'll have virtually no torque ripple. The other possibility is that you have a BLDC type motor. These are optimized for six-step "block" commutation and do not produce sinusodial current / back emf waveforms. You'll have some torque ripple when using them together with FOC. As the motor has only 2 pole pairs, this might be contributing to the "oscillation", but the level is surprising to me, and the velocity controller should be able to compensate this to a certain degree.

If the datasheet does not tell, you can check if you have a BLDC or PMSM by running the motor under load, and watching the motor current waveform (Iq, via DAC). If the waveform is sinusodial, then it is a PMSM.

As you are developing a servo application requiring ripple-free torque, a PMSM would be more suitable.

[Dave_PT]

Rotation setpoint = 100RPM
Without integral control (Ki = 0) the motor only starts to run with Kp equal to 25000/128. But when the motor starts to run, it is unstable.
I used a Kp = 12000/128 and started to increase Ki to get the error overridden.

I was trying to observe the behavior at lower rotations.
At higher revs, I can do a correct tunning and the behavior is expected in all situations.

With Ki = 10/4096 the motor does not run

This should never be possible. The integral term of the controller will always deliver maximum torque after some time (it takes longer, the smaller Ki is). You must always be able to start the motor with Ki > 0, even when Kp=0. (It will not be stable though). Again, also here I suggest using a larger speed setpoint.

Exactly.
I did not wait long enough...

[Dave_PT]

When the power stage is on, each leg must always be active, so either H or L side transistor conducting. You should never see both transistors of any leg in OFF stage (except of course deadtime during switching).

it seems that the "oscillation" correlates with the electrical rotor angle. But I think that the root cause must be somewhere else. Maybe the magnetic encoder. Did you check that all three driver legs are working properly? Are all current sensors giving correct readings?

Yes, I have confirmed and all PWM outputs are correct.
Always in high state, except during the dead time on switching.

[Dave_PT]

Basically, the FOC library produces a clean and perfect sinusodial rotating field. If the motor is constructed as a PMSM, then you'll have virtually no torque ripple. The other possibility is that you have a BLDC type motor. These are optimized for six-step "block" commutation and do not produce sinusodial current / back emf waveforms. You'll have some torque ripple when using them together with FOC. As the motor has only 2 pole pairs, this might be contributing to the "oscillation", but the level is surprising to me, and the velocity controller should be able to compensate this to a certain degree.

If the datasheet does not tell, you can check if you have a BLDC or PMSM by running the motor under load, and watching the motor current waveform (Iq, via DAC). If the waveform is sinusodial, then it is a PMSM.

As you are developing a servo application requiring ripple-free torque, a PMSM would be more suitable.

Here is a lot of information.
In the supplier page, everything indicates that it is a BLDC motor.
Under load, the current Iq is just line ... does not form any sine wave ...
Another interesting thing is when I see the Measured Electric Angle on the oscilloscope, I see strange waveforms. I stop observing a triangle waveform.