Experiences and issues of X-CUBE-MCSDK motor control, STM boards, FOC vs Sensored and related

[eBirdman]

Posted on May 11, 2018 at 17:54

The STM approach to the motor is well thought through in my opinion. But making it well structured and well organized costs in terms of certain level of complexity. I suspect also that STM has to deal with 'troublemakers' such as myself - I mean those users who need their newest 'bleeding edge' products and then question the apparent mismatch between the levels of development between those... I intent this thread to be a discussion-reports-question-answers for this development path of the motor control: X-CUBE-MCSDK + Nucleo or other MCU control boards + FOC sensorless vs sensored control algorithms and related workflow. All these topics are ultimately related although I am specifically interested in Hall sensored control only. As I understand these tools from STM are rather new and there is mismatch in the levels of their development.

I only started now this workflow: X-CUBE-MCSDK STM SDK Ver. 5.0.3 with it's MC Profiler, Nucleo-F303RE and X-NUCLEO-IHM08M1 expansion board , TrueStudio IDE with it's toolchain and 1KW BLDC Motor with 3 Hall sensors rated for 48V up to 28 amps.  So far I am quite impressed with the results and the quality of the code but the hard questions to the STM team will come too.

1st step : hardware preparations. Nucleo board was the easiest : just make sure the power is received from the expansion board' DC-DC converter instead of USB power. User manual is clear about it.

X-NUCLEO-IHM08M1 expansion board was not that easy: default setup is for 1 shunt and needs careful re-soldering of the high current jumpers to allow 3-shunt current measuring configuration which is required for FOC algorithm.

The confusing part here is confusing information in the user manual about 3 capacitors C3, C5, C7 - it is only clear that for FOC algorithm they should be removed. Whether they should stay or can be removed for 6-step control is not clear. I asked this question on the forum but so far no answer.

2nd step: Motor Profiler run - my motor is 3000RPM, 1KW, 48V , max 28A , 6 poles BLDC with Hall sensors. By lying to the profiler I got max 1300RPM, 10 A, 24V, 3 pole pairs in a profile. (To Abdul:  you can also lie about voltage , amps and RPM but not about the pole pairs - wrong pole pairs should always confuse the software driver). Connection was smooth from the start and profiler did quite intelligent algorithm figuring out all the data about the motor. I'd prefer to know where the Profiler saves the profiled file but no information was found anywhere - luckily MCSDK  Workbench found that file while I never saw it And fun part is: I could run the motor by a profiler without even uploading any code to the MCU !

Note: I ran the Profiler as stand alone (without running MCSDK Workbench). Workbench allows to run the Profiler only when starting a new project. I'd like to see the 'Profiler' starting button always when in a default state of the Workbench and be able to update profile for a given project - right now this is not possible.

3rd step: running MCSDK Workbench - well designed software. Most parameters for all the modules of the system already populated as a result of making the choice of the boards: in my case Nucleo-F303RE and X-NUCLEO-IHM08M1 expansion board . I could verify some of IHM08M1 expansion board specs by comparing them to those provided in the X-NUCLEO-IHM08M1 user manual for the FOC mode (table on page 27) - exact match. Very convenient button allowing to see the functional pin assignment of the MCU for the given motor control system - beautiful (I still remember how much time I spent in the past trying to figure this out with another MCU solution).

At this step assign the Output Folder Options - which is actually choosing the IDE and toolchains environment. I chose TrueStudio and then generated code for it and imported that code into TrueStudio, rebuild and uploaded to the target.

Then ran Workbench again to start 'playing' with Monitor . Started easy and the basic window is nice. Motor ran smooth after first ramping up to higher RPM but then lowering to the defined on the ramp gauge. The ramp gauge is in essence input of the required rotational speed.  It is easy to change specs in the Workbench and try running it here. For ex. I change the PWM frequency and then run it... and listen if I like the 'tune pitch'

Note: about the low speed rotation start. The motor controller can start ramping up at any speed but it does not stay at it if the sped set at below the 500 RPM. I see this as the motor' feature, not the motor controller. My motor is high inertia motor with heavy rotor requiring 48 rated volts and torque (means current) high enough to keep rotation of heavy rotor at the low speed. Given the low voltage I lied to the profiler and low max current I lied too, the controller cannot simply provide needed current (=torque=power) to sustain the needed rotation at lower than 500RPM. This should be expected.

----------------------------------------------

Now questions :

Why does STM present X-CUBE-MCSDK as 'FOC motor control' ? There is FOC control mode in there for sure but it is only when 3-shunt chosen and backEMF used for FOC algorithm calculations. When Hall sensor is chosen in the setup and only 1 shunt instead of 3 it cannot be FOC any more but rather 6-step control. In other words I see it as a library and a complete workflow for ALL types of motor control: FOC or Sensor based 1-shunt 6-step control.

Am I missing something?

I hope somebody from STM team will read this to answer...

#mc-workbench #motor-control-library #x-cube-mcsdk #motor-control #foc

[eBirdman]

Posted on May 20, 2018 at 22:25

If STM would release any time soon next version of X-CUBE-SPN8 with Hall sensored example - this would be my main source for further development... I would post here all the details of my experience to help others....

I guess nobody knows when it might be released...

[eBirdman]

Posted on May 20, 2018 at 21:55

Thanks for the info. It compelled me to check out STM user manual FOC SDK 4.3  FOC algorithm . On page 25 I found interesting detail about their algorithm which implied that I was wrong - STM indeed uses position sensors in their FOC algorithm in a 'sensored' version of FOC.  Manual explicitly says that in absence of the position sensors they can run in sensorless mode  which is what all the other motor control vendors do ( I researched 2 other vendors before - FOC was always used in sensorless mode only...)

You are using quadrature encoder - this is not Hall sensor, those are two different kind of sensors with the same goal - to provide a rotor position for speed calc.

I am interested only in 1-shunt mode in sensored configuration because this mode is close to my design. My controller which I am developing cannot use FOC - it uses 1 Hall sensor and 1 BEMF and 1 current sensor. Since SDK Workbench allows this mode (at least theoretically, 1-shunt and a position sensor), Workbench should generate non-FOC code which I could use for my customization. If Workbench cannot produce code for that mode (so far failed ), I will do my own from scratch.

Can you get yours running after configuring for 1-shunt and a position sensor ? Not sure if keeping 3 shunts on IHM08 board is OK or not - user manual is ambiguous in this.

I am using two different compilers : Visual Studio with VisualGDB plugin (my main) and TrueStudio (as a backup in case when VGDB fails to import STM code)

[cedric h1]

Posted on June 07, 2018 at 22:42

Dear Vlad,

Sorry to reply only now, we were very busy with the output of the 5.1 release. It is available now on ST.com .

Regarding your questions.

Yes it is possible to do FOC with 1 Shunt or with 3 shunts and even with ICS (Insulated current sensing). 3 shunts topology is more accurate than one shunt, if you can do both, prefer 3 shunts solution. In 3 shunts topology, we sample 2 phases among the 3 ( sum of the 3 is null, so 2 are enough) in the same time (best option is with 2 different ADCs like STM32F303, it is also doable with 1 ADC STM32F302R8). In 1 shunt topology, we sample the current twice per period . As the sampling instants are spread over the PWM period, the result is less accurate.

Now regarding sensors.

We support 2 kinds of sensors. quadrature encoder and HALL sensors. As you mentioned in this thread, it is two different hardware, and configuration must be aligned with your hardware.

If no sensors are available, we do have a sensor less algorithm that uses a mathematical model of the motor (luenberger observer).

Sensors or Luenberger observer provide motor angle and instantaneous speed, required by the FOC algorithm along with phases current. As you see sensors do not prevent you to do FOC, It is even required if you target to spin your motor at very low speed.

One note regarding TrueStudio, it is fully tested with the latest 5.1 release, and it requires the 1.9.1 patch of the F3 HAL driver (available here :

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-mcu-packages/patch-cubefw-f3.html

)

F0, F1, F4 are not yet supported by truestudio because of HAL drivers.

Hope it helps.

Let us know if you are able to spin your motor with X-MCSDK ( which is support only FOC), and HALL sensors.

Regards

Cedric

[eBirdman]

Posted on June 14, 2018 at 05:12

Thank you Cedric for info. Hopefully this will be useful for others (those who use FOC). For me only FOC without Hall worked - any attempts to run with Hall sensor failed. As for my project, the FOC code is not useful, I need only Hall sensored motor control (not FOC) 6-step approach, but since X-CUBE-SPN8 does not implement Hall sensored approach we could not wait for Hall sensored X-CUBE-SPN8 update. We switched to a completely different solution.

[Diandi Zhu]

Posted on July 11, 2018 at 18:55

Hi cedric,

So in the process of code generation, if I choose LL driver will it work in trueStudio?

[Laurent Ca...]

The question has been moved from the "Motor Control Hardware" section to the "STM32 Motor Control" section (the question is about the STM32 MC SDK). 

Best regards