High current when motor isn't spinning

1

I observed relative high current and therefore relative high temperature on my driver board when the motor was not spinning (Target : 0.00). The reason for that was - so far i investigated - that there was still some pwm signal on the driver. I fixed that temporarily by adding following code to the setPhaseVoltage method:

Capture1
Capture1923×889 39.7 KB

After that the signal in idle state disappeared and current/heat went down. This is for sure not the solution but maybe a starting point for further investigations. @Antun_Skuric maybe you can have a look at it?

2

Are you in openloop mode? High current is totally normal and expected in openloop. The current is holding the rotor in place.

If you want zero current at zero velocity, I’d suggest changing motor.voltage_limit inside loop(). You can read motor.shaft_velocity and programmatically decide how much voltage_limit (and this current) to use.

In closed loop I’m drawing 40mAh when target velocity is zero. If you are getting higher current in closed loop mode then that is a worry.

3

Yeh, this is not a solution but it is a good starting point.

Basically at this point we are centering our output voltage around half of the power supply (duty cycle 0.5) And that is why you see some pwm even when the voltage_q is in 0.

In theory duty cycle 0.5 on all three phases will result in pwm like this one:
Untitled Diagram (75)

Where all three phases are in the same time on and in the same time off. Which means that the line voltage of the motor will always be 0 in between Ua-Ub, Ub-Uc and Ua-Uc.

But as you said, it is possible that due to the misalignment of the phases or some other issue that I am not familiar with there are some voltages across the phases that induce certain currents. We will try to look into this soon.

4

Thanks for the fast and detailed response!

I use 6pwm in closed loop with voltage control mode (G431-ESC with hall sensors). In rare cases t’s between 30-40mA. In most cases it’s 60-80mA. I also have observed up to 150mA in few cases.

So far i havn’t found out what is the reason for this big range of ‘stand-by’ current. After further observations i’m even not sure if my first assumption with the source code changes are correct. I have to investigate it further.

@Antun_Skuric, thanks for the detailed explanation. In my naive thinking i didn’t expect such a behavior, when the setpoint is zero (voltage_q = 0) in voltage-control mode. Anyhow, it is a nice feature, like a motor break.

The question now is, how can i ‘disable’ the driver/motor, so that it will not consume energy? I tried already to use the method disable() without success (G431_ESC board doesn’t have a enable pin for the mosfet driver). I further tried to pause the HardwareTimer, but this created even more troubles (undefined state of output state of U V W pins). Any suggestions for me?
@Owen_Williams unfortunately I couldn’t follow your suggestion with motor.voltage_limit and motor.shaft_velocity. Is there an example i can look into?

5

Hey @erwin74,

We do not support this feature at the moment. But this is something that is important to implement and we should definitely include it in next release.
I mean to be able to switch the phases off completely.

Could you please (if you have time) create a github issue so that we do not forget and it will make us resolve it quicker. :smiley:

Which stm chip are you using and which pins are you using?
Is it just one timer or you are running low-high pairs on different timers.

1 Like
6

github issue added.

I use the stm32G431CB processor with following pins:
#define PHASE_UH PA8
#define PHASE_VH PA9
#define PHASE_WH PA10
#define PHASE_VL PA12
#define PHASE_UL PC13
#define PHASE_WL PB15
{PA_8, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_TIM1, 1, 0)}, // TIM1_CH1
{PA_9, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_TIM1, 2, 0)}, // TIM1_CH2
{PA_10, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_TIM1, 3, 0)}, // TIM1_CH3
{PA_12, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_TIM1, 2, 1)}, // TIM1_CH2N
{PB_15, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_TIM1, 3, 1)}, // TIM1_CH3N
{PC_13, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_TIM1, 1, 1)}, // TIM1_CH1N

→ just one timer, which should be perfectly synchronized?!

7

Thanks.

Yes, I would say they are synchronized as well. We will have to look into this more carefully.
Maybe @Owen_Williams could look into it with a scope?
I will check for nucleo and bluepill.

If you wish to do a quickfix to disable the phases you can look into the funciton LL_TIM_CC_DisableChannel and LL_TIM_CC_EnableChannel. We call the LL_TIM_CC_EnableChannel in driver init:

LL_TIM_CC_EnableChannel(HT->getHandle()->Instance, LL_TIM_CHANNEL_CH1 | LL_TIM_CHANNEL_CH1N | LL_TIM_CHANNEL_CH2 | LL_TIM_CHANNEL_CH2N | LL_TIM_CHANNEL_CH3 | LL_TIM_CHANNEL_CH3N);

This function starts the 6PWM mode.

8

I am also wondering if this problem as something to do with the question @Juxo has asked few days ago.
https://community.simplefoc.com/t/ringing-at-gpio-and-mosfet/384

9

I don’t know if it has anything to do with it either. But my DRV8302 board was destroyed with only 2A current consumption. One of the shunt resistors went up in smoke.
I’m currently testing my motor with an Infineon development board. There is also a small oscillation of the output voltage here, but that is in the range of + - 1V maximum. And is therefore not critical.

10

3 posts were split to a new topic: Infineon bldc shields impression

11

@erwin74
Extremely hacky and untested. I don’t think it is any better than your approach apart from not changing library code.

 void loop() {

    static float last_voltage_limit = 0;
    if (abs (motor.shaft_velocity_sp) < 0.01) {
        last_voltage_limit = motor.voltage_limit;
        motor.voltage_limit = 0;
    } else if (last_voltage_limit > 0) {
        motor.voltage_limit = last_voltage_limit;
        last_voltage_limit = 0;
    }
}

I’ve not noticed variations in current except when I plug/unplug USB whilst also powering board from bench power supply. I should probably stop doing that :wink: !

Do you have any load on your motor? I’d expect variations in current if your motor is opposing a gravity load at zero velocity.

1 Like
12

Last days couldn’t find time for it. Today i implemented your (Antun) approach, and i works as expected - thanks!

I also looked into the signal with scope:
all signals are fine,

  • no ringing observed (just little engaging, but this is normal) like Juxo did on his configuration
  • all 3 phases are perfectly synchronized
  • dead time is fine 400 ns (fpwm = 25kHz; dead time = 2%)
    Still have 60 mA when supply voltage is around 14 V, even when no load (no motor) is connected. I have no explanation for it. The high side mosfet drivers should only need few mA (25 kHz, Mosfet Ciss = 4,8nF). Anyhow, now i can turn of the driver and that’s just fine for me.
13

@Owen_Williams
I have also found out from where this big variations on input current comes from :thinking:

It’s too bad to tell, but also interesting in some way: My driver board is connected to an usb-hub (for programming and debugging) with a separate power supply. On that hub, some more development boards are connected to. The assumption was that all this devices are supplied by the usb-hub. But this isn’t the case :laughing:. When i turn on the power supply for the ESC board (14V), then this ESC board snaps the power supply for all boards on the usb-hub. Probably because the 5V regulator on the ESC boards has a slightly higher output voltage, than the 5V regulator from the USB hub… and the winner takes it all.

→ Lesson learned: You should know your participants well.

1 Like