Speed Feedback fault in Motor Control Workbench Monitor.

[Gussius]

I have made a SM-PMSM project for a hub motor (10 pole pairs). I can compile the generated code in STM32CubeIDE (HAL) but when I run it I always get the fault "Speed feedback" in Motor Control Workbench Monitor.

There is 20ms of activity, where there is 3ms of 13kHz PWM wave from about zero to nominal voltage (p-p) at 50% duty, then "Speed feedback" fault occurs. The waveforms are identical on all phases. The motor does not move, therefore no encoder pulses.

It is strange that the pulse are the same on all three phase outputs, basically stalling the motor.

What is going on here?

UPDATE:

• Hall sensors are conected to the board header, has been probed in place and correct 0-VDD square wave is output.
• Motor coils probed and b-emf waveform checks out ok.

• Placement electrical angle was measured from Hall H1 rising edge to the peak of the first Phase waveform.
• It seems like none of these measurements have made any difference at all.

Is there a way to test the STEVAL-SPIN3201 board?

UPDATE 2:

• I have managed to get the motor to run in sensorless mode, but I really need Hall sensors to achieve a more robust low speed running.
• I changed a few settings.. like increasing the "max measurement errors number before fault". This at least kicks the motor around which produces some Hall signals. But still faults with "Speed feedback".

The motor control SDK user manual (UM2392) mentions this fault "The speed feedback is not reliable any more (usually happens when the rotor speed goes too low)"

But at this stage I am not even trying to have a low speed.

Hmmm!?! Anyone got any ideas?

[cedric H]

Hello,

Few things are required in order to be able to use Hall sensors.

• be sure that the angle of your hall sensors matches your configuration (120 or 60 deg)
• You should know the "Placement electrical angle" value (difference between the electrical angle and the Hall sensor angle)
• In Hall sensor mode, the order of the phases does matter, you can NOT switch U,V, W
• Be sure that you did not swap the hall sensor connector.

Regards

Cedric

[Gussius]

Hi Cedric,

Thanks for your reply.

• I have opened up the motor and measured the physical angle of the hall sensors, and they are 60 degrees appart from each other.
• I have probed U and V with CH1 and CH2 and hall sensors digital signals (see image)... The setup is, all motor wires connected to the hardware and power on (idle).

The screenshot shows the correct U-V-W forward sequence and a hall sequence for a 120 degree arrangement (??) according to UM1052 fig 85 (see image). Why is it not 60 degrees like I physically measured?

• Now for the "placement electrical angle", when zoomed in on the capture, it shows the delay from hall_1 rising edge to the peak of phase-U as 2.61ms. The motor phase has a period of 21.40ms. How do I get the "placement electrical angle" from this? Is it simply 360/period*delay=43.9 deg? Does having 10 pole pairs effect the answer?

If I use 120deg, 43.9deg with the current setup, then I still get the following response before the fault "speed feedback" (see image)...

Thanks

Angus

[Gussius]

I have still had no luck with trying to get this motor going with STEVAL-SPIN3201 and Motor Control Workbench.

Here is an image of the motor internals...

Any help would still be appreciated.

Thanks,

Angus.

[jouko.perkkio]

I am facing the exact same problem. I have a 3kW 23-pole hub motor which I am able to spin in sensorless FOC mode. The rev-up needed by the sensorless algorithm is not feasible to use with my E-bike project. Therefore the HALL sensors would be very important to get working.

My motor shows similar waveforms when trying to start; all phases output similar signals, therefore not making the motor spin in order to let the HALL sensors to output speed/position information.

When I struggled with sensorless mode, I got similar waveform from all U, V and W phases. But after increasing the ramp-up current, the waveform got correct and motor started to spin.

The MC workbench does not create any rev-up code when primary sensors are configured to HALL. This makes me wonder, is there some kind of "lack of drive current" setup when trying to start up the motor? At least it looks that all example motors are very small and probably spin and start with quite a small current...? Could there be some kind of configuration issue/problem/bug with the MC Workbench when trying to configure it to this kind of larger motors? Meaning low inductance (LS ~ 0.050 uH, RS < 0.1 Ohm) and with fairly large inertia compared to small motors?

I'm kind of out of ideas. Probably next I'l try to setup the 6-step algorithm if that would work.. If you Angus get any progress with this, ideas are more than welcome.

-Jouko

[Mateus P. Lourenco]

How exactly were you able to get it run in Sensorless? You mentioned you increassed the current on the start-up, but how much, in terms of motor spec current, did you increassed? Can you share the configurations made at your side?

I'm trying hard to make it run on a 17" SM-PMSM on a custom driver board. On startup, the motor tryies to spin but it shorts and the MCU reset. On that point the MCU reset and reads no signal from the hall sensors, so it stops and flags "Speed feedback" fault.

 

Already calculated the electrical angle for the 120° hall sensors mounted on the motor.

[jouko.perkkio]

@Gussius​, @cedric H​ 

I solved my problem. Most likely here is solution for you too Gussius.

First of all, the phases and hall channels need to be correct. My motor has YELLOW-GREEN-BLUE phase wiring which corresponds my motor control U, V and W phases. The motor gives out HALL sensor wires also in same color coding; YELLOW-GREEN-BLUE and they match H1, H2 and H3.

But the actual problem is noise. BLDC phase control results in very large noise transients due to the pulsed control by nature. Now when the HALL sensors are inside the motor (and wires go along the phase cables), they pick up the control noise. I debugged this with low-latency printouts at HALL timer interrupt which captures the HALL pulses and determines speed and direction. When I spinned the wheel, the printout shows perfectly corrent rotational speeds. But immediately when I clicked "Start motor", the interrupt logger goes crazy, displaying non-possible hall sensor states. I could track this down with oscilloscope and the HALL sensor information is just terrible!

Now when you look at the HALL sensor input (for example your STEVAL-SPIN3201) schematic, there's 1k + 10pF as input filter. This filters nothing. And the pull-up resistor is on the "wrong side" of the resistor in the RC circuit; increasing the R creates a voltage divider and eventually HALL sensor activation will not be detected by MCU logic state.

I modified my HALL input as in attached picture. It is taken from STEVAL-SPIN3201 schematic, but the interface is more or less the same in all ST motor control boards (mine is from X-NUCLEO-IHM08M1). The filter is 10k + 1n, resulting in 15kHz cutoff frequency. Rise time is around 10us, which is quite fast enough for this kind of big motor. My motor could have theoretical maximum speed of 1000 RPM, which would result in getting HALL pulses at a rate of 1ms. So no problem in time delay due to increased filtering.

And what is best, now my motor starts and stops when I want =)

EDIT: BTW @Gussius​ , you electrical angle is 316 degree according to my understanding. The rising edge of H1 is 2.6ms before the U peak value. From that point, the angle is calculated as 360 - 360*2.6/21.4 = 316 degree

[Mohamed eleuche]

you are my hero. I was stuck trying to make my motor run for days and your post helped.

thank you

[jouko.perkkio]

You're welcome. I struggled with this quite a long time too. I wanted to share my findings as I think this is important if one wants to use hall sensors.

[Gussius]

Thanks a lot for your solution on this @jouko.perkkio​ .

[Laurent Ca...]

The question has been set only to the "STM32 Motor Control" topic (the question is only about the STM32 MC SDK). 

Best regards