Issues with 2 Motor Configuration and Current Sensing in MC Workbench for Customized Controller Boar

[AndyChen]

Hello STM32 Community,

I am currently working on a customized controller board with the same architecture as the EVSPIN32G4-dual, using the STSPIN32G4 and STDrive101, to control two BLDC motors. However, I have encountered a few issues and would appreciate any guidance or confirmation on the following points:

1. 2 Motor Configuration with 6-Step Algorithm: While setting up the MC Workbench, I noticed that I cannot select a 2 motor configuration when I choose the 6-step algorithm. Although I believe this might not be a significant issue, I would like to confirm if it is still possible to configure the PWM peripheral for the second motor manually? Any advice or steps to achieve this would be highly beneficial.

2. Current Sensing with 6-Step Algorithm: Additionally, I found that the current sensing section is disabled in the MC Workbench when using the 6-step algorithm. I am interested in acquiring current readings with a single shunt configuration. Is there any possibility to enable or implement current sensing in this scenario, even though the MC Workbench doesn't provide direct support for it?

Thank you in advance for your assistance!

Best regards,

[Fabrice LOUBEYRE]

Hi AndyChen,

sorry for this inconvenient, but the MCSDK6.3.0 currently does not support 6-step dual motor drive. This feature is one of the change requests we will study for our next version MCSDK6.4.0.  Today it is difficult to provide you with such dual drive support. However, as the MCSDK6.3.0 supports FOC dual motor configuration with the EVSPIN32G4-dual board. So, why not try a FOC solution?

Regarding the boards, the EVSPIN32G4-dual has not been designed to support a sensor less 6-step solution. You will be only able to set up a hall sensor solution with one motor. The current driving mode is also not available with this board.

In addition, the EVSPIN32G4 (one motor control) board is capable to control a 6-step sensor less solution, but also only in voltage driving mode.

So, if you want to study the current driving mode of a MCSDK6.3.0 6-step implementation, i suggest you generate the project given as an example into the MCSDK6.3.0 workbench. You can easily check the schematics of the NUCLEOG431 + X-NUCLEO-IHM07M1 boards accessing the data brief file into the MCSDK6.3.0 workbench. It is also interesting to check IPs configuration thanks to the STM32CubeMx tool by loading the corresponding ioc file.

Best regards.

Fabrice

 

 

 

[AndyChen]

Hi Fabrice LOUBEYRE,

Thank you so much for your reply.

My motor control board is configured with a hall sensor for speed control, so I don't need to implement sensorless control. My board, as well as the EVSPIN32G4, only has 1 shunt resistor for each motor. I wonder how Field-Oriented Control (FOC) can be achieved with only 1 shunt resistor.

The reason I want current reading is for overcurrent protection. Can I use some reference code for overcurrent protection from other example projects?

Also, although the workbench does not support dual motor control with 6-step commutation currently, am I able to configure some pins to generate PWM signals for the second motor? Given my configuration of BLDC, hall sensor, and 1 shunt resistor, would using 6-step commutation be more suitable? 

Thank you for your assistance.

Best regards,

Andy Chen

[Fabrice LOUBEYRE]

Hi Andy Chen,

Yes, the MCSDK6.3.0 can generate FOC projects using a Single Shunt current sensing. And this is the case with EVSPIN32G4 projects.

I agree that 6-step solution is recommended for BLDS motors, but as today we are not able to provide you with efficient and tested solution for dual motor, i suggest you change to FOC algorithm.

You will easily configure with the MCSDK6.3.0 workbench a dual motor FOC project with HALL sensors for speed sensing configured for both motors, based on EVSPIN32G4-dual inverter board. You will have all information required to set up this kind of solution with the generated project.  And you will be able to see two different overcurrent detection configurations:

The first one, called driver protection, uses the nFault signal coming from the three half-bridge gate drivers STDRIVE101 IC that is connected to the timer BKIN input.

The second one, the one you were referencing to, uses the common RSHUN, connected to a comparator that generates a BKIN input to the main timer in case of overcurrent detection.

Best regards.

Fabrice