# Brushless DC motor problems at high velocities

For a project we use a brushless DC (BLDC) motor. Everything works fine until we tried to reach high velocities. I will first explain my setup, and than explain our problems using some graphs.

# 1.0 Setup

The following hardware is used in the setup:

• BLDC motor: Tiger motor U8 (135kV)
• Motion controller: SOMANET DC 1K
• Encoder: RM08 12 bit absolute encoder

An overview of the setup is shown below:

## 1.1 Requirements and Parameters

We need about 4800 [RPM] from the motor. The Tiger motor has a kv value of 135 [RPM/V], connecting it to a 48 [V] supply means it theoretically should be able to go up to 6500 [RPM]. The specsheat includes a scenario where it reaches 5000 [RPM] while a propeller is connected to it, so 4800 [RPM] with no load should not be a problem.

# 2.0 Problem

We are not even getting close to the 4800RPM, a plot of the motor velocity vs phase current is shown below. We can identify 2 problems from this plot.

## 2.1 Inefficient commutation

The first thing which was remarkable from the test is that about 10 [A] was already required to turn at 3200 [RPM] without any load connected. This seems to be caused by inefficient commutation, we figured there are two main possible causes for this.

### 2.1.1 Phase offset error

Their might be an error in the phase offset used, this will cause an linear increase in required current with velocity. This can be best solved by finetuning the offset at a high velocity. However our curve does not seem linear, thus this does not seem to be the case.

### 2.1.2 Delay error

There is a certain amount of delay in between requesting the position from the RM08 and applying the new voltage. This delay can cause the current to exponential increase with motor velocity, which is true in our case.

By adding up al delays we found a total delay of ~0.1 ms in the system (see above). Spinning at 3000RPM = 50Hz and using 21 pole pairs means that the electrical turning frequency is 1050Hz, than a delay of 0.1 ms would cause a 37.8 electrical degree error, This likely causes the inefficiency!

## 2.2 Control going crazy

if we try to go above ~3200 RPM, the motor starts pulling a lot of current and makes a lot of noise. This means the motor is not operational above 3000RPM, this seems to be the most urgent problem at the moment.

### Voltage dependency

Normally the motor velocity is limited by back-EMF, if the back EMF would be causing this issue the problem would be voltage dependent. Therefore some measurements where done at different voltage levels, see the two images below:

The moment where the motor stops following the velocity sweep seems to increase linearly with voltage. Another interesting outcome is that at 30V the motor just stops following the velocity sweep, while at the higher voltages (40V and 43V) the motor suddenly dropped to a lower velocity. Note that the 46V test stopped before this moment because to high current peaks were flowing trough the SOMANET (35A). However it seems unlikely the back-EMF is the problem since Tiger has been able to reach 5000RPM themselves.

# Solutions

For the first problem we thought we could use something like:

Pcorr = Penc + t_delay * Vel.

With:

• Vel: angular velocity
• t_delay: the delay compensation gain
• Penc: the encoder position for the rotor
• Pcor: the delay compensated position

However this didn't save the problem at all. Do you have any other suggestions?

For the second problem we can't think of any cause, can you think of any?

• What control loops are in place? May 29 '17 at 12:06

The somanet site makes a big deal about their firmware being open source, so you should be able to check the timing in the code (or otherwise get the help of the somanet engineers).

A 15kHz PWM is the slowest I've seen in a long time and could indicate that that they had trouble fitting the commutation algorithm to their architecture. Or maybe they are optimizing switching losses which is all good.

Either way the PWM frequency is not part of the commutation calculation or estimated latency.

The commutation should use velocity and encoder latency in it's calculation. If not, and the math indicates it can't keep up, use a separate lower res encoder for commutation.

Verify that the noise on the motor bus is not affecting the encoder signal.

• Thanks a lot for your answer. I figured that good detail would be important for finding the problem. May 29 '17 at 18:48
• I will have a look if we can increase the PWM frequency, and see if that could make things better. I will also contact Synapticon to check if they use any latency in their calculations. We actually already use a separate encoder for commutation. The encoder which will be use to find the joint output will be placed after a transmission and will be about 16bits. May 29 '17 at 18:56
• We made some progress today. The reason for the high peaks when the motor cant keep up with the setpoint is due to an I factor in the PID. if we use feed forward control the high current peaks disappear, however the motor is still limited at 3200RPM unfortunately. May 29 '17 at 18:57
• We also did some measurements on the PWM signal, it seems like it never gets wider than 60% - 70% so this explains why the motor reaches lower setpoints than expected. Why the SOMANET wont output a duty cycle higher than 60%-70% is still unclear tough, we should contact Synapticon for that. May 29 '17 at 19:01
• I would not expect changing PWM freq to change anything. It's only a clue that somnet firmware may have been written in a non standard way. Whether that is nonstandard-good or nonstandard-bad is unknown. May 29 '17 at 20:26