SVPWM signal seems wrong for some Sectors on MCWSDK 5.4.8

[Mateus P. Lourenco]

Hi guys, I'm new on this forum

I'm using the MCWSDK v5.4.8 to drive a custom control and power board on a big Hub motor (17" from YM) using hall sensors.
The simptom I'm facing is that every time I try to start the motor with a command as MC_ProgramTorqueRampMotor1 or MC_ProgramSpeedRampMotor1 the motor tries to start. It starts, turn for close to 1° and then abruptly stop right after.

I get a MC_SPEED_FDBK right after, because this event pulls lots of current from the power source. The power source protects it by cutting of the supply thus powering off the hall sensors.

While investigating the problem, we disconnected the phases wires and just connected the Hall connections to check the SVPWM signals for each sectors, by turning the motor by hand. We noticed that in some of the sectors, there is only one phase with a PWM signal while the other ones are either fully open (0% duty cycle) or fully closed (100% duty cycle) in a fashion that while one phase is open, the other is closed. I don't know if this behaviour is expected but I imagine that this is the cause to the overcurrent events.

The following contents are measures between phase output conection and GND
These consecutive sectors seems fine

But these following consecutive states, doesn't

The results is the following. Note that on these photos, the motor phase connections where connecte to the board and each phase was evaluated.

These are the SVPWMs beeing generated while the power sourcer is shutting down due the overcurrent. Thats why it has this downward shape.

We know that on the OFFSET_CALIB state, all three phases are on 50% duty for calibration. But as soon as they get different values from each other, the power supply stops powering the circuit thus lowering the SVPWM signal voltage (as shown on the last image).

We already checked the deadtimes for shorts, and the 500ns value we setted up is ok.

My question are:

Why are these 3 sectors signals looks like this? Is this normal?
Is there a API  handdler to control the BUS current? We have ICS on phases A and B.

[RhSilicon]

Wouldn't it be possible to use a smaller Hub motor for tests, and after being able to understand how it works, start working with the bigger Hub motor?

[Mateus P. Lourenco]

We're acctually going after a smaller one as well. But since the final application will be on the bigger one, We're trying to figure out these described behaviour and if there some kind of limitation on the MCSDK side for these motors.

[RhSilicon]

What is the motivation for choosing SDK 5? The ST YouTube channel has several videos about Motor, and I found the SDK 5 initial presentation video from 5 years ago, but it already has the SDK 6 video from a year ago.

Getting started with STM32 Motor control SDK5.0

Getting started with STM32 Motor control SDK6.0

I found this too, I believe it might be interesting to research the subject further:

Long story short, the SVPWM technique isn’t a precise method of control for BLDC motors, but it does reasonably well as can be seen in the video.

https://jkboyce.github.io/electronics/2020/04/13/SVPWM-motor_control.html

[Mateus P. Lourenco]

The last time we checked the v6, it does not featured Isolated current sensor topology neither custom PCBs. That's why we using the v5.

We appreciate the Link for the GitHub project. We'll check it

[Mateus P. Lourenco]

@Gael A Can you help me on this?
I men, are these 3 sectors right?
I also like to mention that on code auto generation, this low level function is auto generated using TIMx instead of TIM1. I mannualy correct this so it can complie, but Idk if this is right

on the ics_lm1_pwm_curr_fdbk.c file

LL_TIM_CC_EnableChannel( TIMx, TIMxCCER_MASK_CH123 );

 

[SRedd.5]

I also like to mention that on code auto generation, this low level function is auto generated using TIMx instead of TIM1. I mannualy correct this so it can complie, but Idk if this is right

No keep as TIMx dont change to TIM1.

[Gael A]

Hello Mateus P Lorenco,

From the look of it, maybe there is an issue with your Hall Sensor setup. Have you correctly configured your "Sensors displacement" and "Placement electrical angle" ? You can change them by clicking on the motor in your WorkBench project, then on "Sensors" tab.
The determination of both values is well explained in MCSDK 6.1.2 documentation. You can access it by executing WB 6.1.2, clicking "About", then "Documentations". The information you are looking for is at the end of the "Hall sensor feedback processing" section in the User Manual.

Hope this will help,
Gaël A.

[Mateus P. Lourenco]

Hi @Gael A thanks for the sugestion.

From the following images I calculated 259° (-101°).

But even changing that, the motor response on turn on was the same

Phase A (Yellow)
Phase B (Light blue)
Phase C (Purple)
Current sensor (dark blue)

Note that the current sensor points 1.9V (450A -> 5V; 0A -> 2.5V; -450A -> 0V). This indicates -108A out of a 5Amax power supply. This event triggers the power supply protection, then reducing the Voltage output, as shown on the phase voltages.

What else could be doing it?