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

[Electric Forest]

Posted on May 14, 2018 at 21:25

Hi Vlad,

Interesting project you have. And very similar to mine.

> 

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.

I'm not sure I understand, why can't it be FOC any more? Because you can't use a Hall sensor and still use 3 shunts? (Because of pin issues on the IHM08M1?)

I'm just about to try to use a hall sensor and FOC with the board, but not as far down the line as you yet.

[eBirdman]

Posted on May 16, 2018 at 18:23

Hello,

why can't it be FOC any more? Because you can't use a Hall sensor and still use 3 shunts? (Because of pin issues on the IHM08M1?)

Because the FOC algorithm is driven by the events generated by the current reading from 3 shunts. Hall sensor has no place in running  FOC algorithm.  Also you cannot replace current readings from 3-shunt with reading Hall events in FOC algorithm - impossible because of the nature of FOC (I recommend to read about Field Oriented Control from TI papers to understand what it is about).

On another hand 6-step algorithm can be driven by either one : current reading from a single shunt (identifying 'zero crossing') or , instead, by a Hall sensor. And more or less the same algorithm can be slightly modified to use either one sensor or another.

That's why STM's statement in their papers that their FOC Workbench allows both sensorless and sensor motor control - does not make sense to me. Even more confusing is that their 6-step motor control library is ONLY sensorless (while it actually should be both - that's the beauty of this method)!

Hope this helps.

[eBirdman]

Posted on May 16, 2018 at 18:41

I didn't analyze STM code in X-CUBE-MCSDK yet, but if all that library is based on FOC only, I'll have to drop it because my own application requires only Hall driven new designed algorithm.

[eBirdman]

Posted on May 17, 2018 at 18:38

I hope that this my post will help those X-CUBE-MCSDK users who need a well developed framework for the Field Oriented Control of the sensorless motor control. As for my application - I am abandoning this approach along with using X-NUCLEO-IHM08M1 expansion board. I think STM team never ran this board with Hall sensors... here is why I think so:

The user manual for the board does not clearly specify how to configure that board for the Hall sensored mode and hence to be able to use X-CUBE-MCSDK with Hall sensors. So I requested a clarification from STM tech support (hoping they will fix the User Manual to include the obviously missing information), instead I got an unexpected reply ....

Here is my request:

Missing configuration information for the X-NUCLEO-IHM08M1 motor control board . User Manual UM1996 says ' For FOC control Remove capacitors C3, C5 and C7' and then 'For 6-step control keep capacitor C5 mounted' . Manual says nothing about capacitors C3 and C7 for 6-step control - should they be removed or should they be kept along with C5 ? Or either way is OK?

After 10 days I finally got a response from STM with a 'Solution proposed' . Here it is :

We would suggest you to visit our community page where you can collaborate with other engineers to work on issues. Please see the link below for related information.

https://community.st.com/thread/49857-experiences-and-issues-of-x-cube-mcsdk-motor-control-stm-boards-foc-vs-sensored-and-related

That link provided points to this post where I am sharing my experience running the above board in FOC mode

while waiting the tech support solution to the missing information: how to configure the board for Hall sensored mode...

If STM developers don't know how to configure the board for the Hall Sensored mode instead redirecting me to my own post here, that could only mean they did not test this board in Hall sensored mode themselves. They only ran all these tools in FOC mode which is not Hall sensored algorithm.

[Electric Forest]

Posted on May 19, 2018 at 18:50

Hi Vlad,

For 6-step you can keep all those caps mounted, but only C5 is required. Also note that you must change some of the jumpers. As you say, the documentation is really bad.

I'm running the IHM08M1 board now with a hall sensor (using one with a quadrature encoder output atm). Using the Bullrunning motor and I have botched the motor together with a magnet and mounted a hall sensor board above.

The benefit you get is that the FOC algorithm can run the motor all the way down to zero speed. And you don't need any special start procedure. I do not think you are correct that FOC can't use sensors in addition to the current sensing.

BTW, I'm using the FOC SDK 4.3.

The X-CUBE-MCSDK is very different, and the software architecture is much much better. I couldn't make it spin the motor though. Again, no documentation.

Let us know what you end up choosing! Also have a look at VESC.

[eBirdman]

Posted on May 20, 2018 at 05:53

Thank you for sharing. Please specify are you using FOC SDK 4.3 to run your motor? If you are using FOC, you are not using your Hall sensors even if they are connected to the board. The FOC algorithm is based on math model of the phasors diagram to predict the distribution of the magnetic field using BEMF current reading from 3 shunts.

FOC algorithm does not involve reading any positioning sensors: Hall or encoder. Neither you can replace driving the state/event machine with positioning sensors -this is not how FOC works. Try this: just pull out Hall sensor connectors and continue running...

If you use Hall sensors, then I think you are running 6-step algorithm and this is good news for me   If STM developers indeed ran their MCSDK with Hall sensors, that means MCSDK reconfigures code to use 6-step algorithm whenever user enters relevant input: Hall sensor and 1 shunt (such user choices cannot be used for FOC algorithm).

I suggest you read app pages about FOC motor control algorithm either from TI or from Microchip or watch their videos on youtube...

[Electric Forest]

Posted on May 20, 2018 at 11:56

Yes, using FOC SDK 4.3.

Pulling out the hall sensors stops the motor.

You are not correct that FOC can't use sensors.

[eBirdman]

Posted on May 20, 2018 at 17:07

That means you are running Hall-based algorithm. Could you please provide details of your configuration? The main parameters of interest: How many shunts did you enter?

Did you try one shunt configuration with Hall sensor included?

[Electric Forest]

Posted on May 20, 2018 at 18:21

Oh yes, definitely running in sensored mode. Note that my hall sensor has a quadrature encoder output. So quadrature encoder is what I need to tick in the tool - not hall sensor. If you tick for hall sensor I think it expects UVW commutation signals.

No, I didn't try one-shunt. Why do you want that?

To create the systemdriveparams I did the following in ST Motor Control Workbench:

1. New project

2. Choose my Nucleo (302R8)

3. Choose my power board (IHM08M1)

4. Choose my motor (Bullrunning)

5. Tick quadrature encoder in Motor->Sensors and set the number of pulses

6. Select quadrature encoder in Drive Management->Speed/Position Feedback Management

7. Set the correct IO pins used for the quadrature encoder in Control Stage->Digital IO. For my board it is A15 and B3.

After this, compile and load.

Which compiler are you using?