MotorControl Workbench Issues

[M_Schmidt]

I have multiple issues to report with the MC Workbench (MCWB). I am using Version 6.3.2 and trying to get a dual motor BLDC setup working on custom hardware.
In the .zip-file there is a minimal project required for viewing the issues and additionally what is required to run on the custom hardware.

• It is not possible to restrict current sensing (3-shunt setup) to one ADC, as intended by the MCWB.
  When trying to restrict either Motor1/2 to a single ADC with the end goal of having one ADC used for each motor, i get the following error when trying to generate the project:
  "ERROR [LineInfo_to_exitCode.manage_IocGenerationError] Unable to generate ioc file due to: When calling function "add_extra_regular_cnv_if_needed", required parameter "cnv" (parameter #2) was specified, but had null/missing value...."
  This is a bug in my opinion, because with the pinout, it should be possible to use either ADC1/2/3 for Motor2 and ADC1/2 for Motor1. The amount of conversions should also be smaller than the maximum amount for the ADCs.
  
  There also is no "link" between the ADC Regular/Injected conversion in the .ioc-File and the generated code from the MCWB, therefor changing motorControl stuff in the .ioc-File has no effect. Changing the setup by hand in the generated code from the MCWB is not very usefull i.m.O., as regenerating the code overwrites those.
  
  
• Using Quadrature Encoder as Main Sensor and Hall Sensor as Auxiliary Sensor also is broken, as that leads to following code generation in the file parameters_conversion.h:

/********** HALL TIMER MOTOR 1 *************/
#define M1_HALL_TIM_PERIOD 65535
#define M1_HALL_IC_FILTER_LL LL_TIM_IC_FILTER_FDIV16_N8
#define M1_HALL_IC_FILTER 12
#define SPD_TIM_M1_IRQHandler TIM2_IRQHandler

/********** HALL TIMER MOTOR 2 *************/
#define M2_HALL_TIM_PERIOD 65535
#define M2_HALL_IC_FILTER_LL LL_TIM_IC_FILTER_FDIV16_N8
#define M2_HALL_IC_FILTER 12
#define SPD_TIM_M2_IRQHandler TIM5_IRQHandler

/********** ENCODER TIMER MOTOR 1 *************/
#define M1_PULSE_NBR ((4 * (M1_ENCODER_PPR)) - 1)
#define M1_ENC_IC_FILTER_LL LL_TIM_IC_FILTER_FDIV16_N8
#define M1_ENC_IC_FILTER 12
#define SPD_TIM_M1_IRQHandler TIM3_IRQHandler

/********** ENCODER TIMER MOTOR 2 *************/
#define M2_PULSE_NBR ((4 * (M2_ENCODER_PPR)) - 1)
#define M2_ENC_IC_FILTER_LL LL_TIM_IC_FILTER_FDIV16_N8
#define M2_ENC_IC_FILTER 12
#define SPD_TIM_M2_IRQHandler TIM4_IRQHandler

#define LPF_FILT_CONST ((int16_t)(32767 * 0.5))

The issue is two Macros of each motors SPD_TIM_Mx_IRQ_Handler. The same issue is in the files stm32f4xx_mc_it.c and stm32_mc_common_it.c. Changing those to unique macros by hand after code generation does work though and leads to a working speed measurement.

• Motor Profiler is not supported with dual motor configurations according to the MCWB, the include "mcp_config.h" in the file stm32f4xx_mc_it.c still is generated, but the file does not exist. Deleting the include by hand after code generation does work though. Or does that file not belong to the Motor Profiler and something else is missing?
  
  
• I have not understood the difference between setting the Drive Type to HAL when generating the Project from the MCWB, as when setting the Drive Type to HAL, the generated code uses LL Functions etc.
  Is that intended because of performance or is that not intentional?
  
  
• Not being able to add custom hardware .ioc-File Pinout for the inverter in the STMC Board Designer, as regenerating the MCWB overwrites all changes to the .ioc-File. Therefor being able to set things in the .ioc in the STMC Board Designer would be usefull.
  
  
• The generated FreeRTOS setup uses .5ms as a tick and not 1ms as a standard value. Maybe thats because of weird clock configuration setup by the MCWB?
  
  

Please correct me on any of these points, if I am mistaken/if it is working as intended and I`m just using it wrong.
The issues lead to:
Being able to drive each single motor with Position/Speed Control without any issues.
Trying to get the motors to work at the same time (just calling MC_StartMotor2() after MC_StartMotor1()) leads to a broken FOC-control/noise/Software undervoltage errors. To see the behaviour in main.c uncomment line 87:

void PfuschTask(const void* param)

{

 (void)param;

 osDelay(8000);

 assert(MC_StartMotor1());

 osDelay(8000);

//MC_StopMotor1();//if not called -> Error/broken control (this is line 87 in main.c)



 osDelay(8000);

 MC_StartMotor2();

 osDelay(osWaitForever);

}

The custom hardware could in theory be reproduced by a stm32f407, and two IHM08 as it is based on those, Im assuming that is too much effort though.

Please give me input, on how to proceed, if the bugs will be looked at/improved/or if I have to look for another solution like using Matlab/TI Hard-/Software.
In my opinion it is not worth using the MCSDK for this application, if the structure of the generated code and the workflow is not fixed or at least improved heavily.

[Gael A · Accepted solution]

Hello M_Schmidt,

Thank you for your post, I will try to answer as many topics as possible.

- Your first issue is a limitation of the MCSDK concerning the stm32F4 MCU in Dual Drive operation. We are working on it and will try to fix it as soon as possible.

- Though the WB overwrites any ioc modification when regenerating, you can still modify your ioc file, and then regenerate using CubeMx. That way, your custom modifications will be taken into account, while still keeping your MCSDK configuration. However, take note that if you want to change your MCSDK project, you will have to do the CubeMx modifications once more.

- The generation of two handlers named the same is indeed a generation error. Thank you for your report, we will fix this issue.

- mcp_config.h relates to the Motor Control Protocol, which allows communication with the MotorPilot tool. The include in stm32f4xx_mc_it.c is an artifact though, and should be removed. Thank you again for your report.

- HAL functions are mostly used in main.c during initialisation. However, a lot of LL functions are still used when selecting HAL Drive Type as it would otherwise impact performance too much.

- It is advised to use a different time base than that of the MCU for the FreeRTOS, this is intended behaviour.

- Concerning control issues during the use of both motor at the same time. I will need to spend more time on the subject. Have you taken a look at the estimated current ? Are both HighFrequencyTasks happening correctly ?

[M_Schmidt]

Hi Gaël A,
thank you for your reply!
I will create another post on Monday/Tuesday, where I will go more into detail concerning the specific issues I am having with my dual motor project. This way we can separate the bug report and the specific problems of my project.
I hope you also think that is sensible, I will mark your previous reply as "Accept as Solution", as you have answered the question wether those were bugs/intentional.

About the following:
"Your first issue is a limitation of the MCSDK concerning the stm32F4 MCU in Dual Drive operation. We are working on it and will try to fix it as soon as possible."
Can you give any input if that will be in the next version of the MCSDK/when that will come out?

Many thanks for your quick reply,
Markus Schmidt

[M_Schmidt]

Hello Gaël A,

The problem was an eFuse, that shut off the supply to the second motor, as I havent implemented the handling of the eFuse yet. (And turned back on -> back off -> ... -> ..., therefor the oscillations).
After regenerating the software with fitting current limit for the custom hardware, the generated software with the few mentioned fixes works as expected.

Separating the ADCs for the measurements to each motors is a requirement in my opinion, I am looking forward to the fix.
Nevertheless thank you very much for your feedback on the bugs/intended features. I hope I was able to contribute to the improvement of the MCWB, as I am a huge fan of generated code for standard applications.


Thank you ST and Gaël A!

[Gael A]

Hello M_Schmidt,

I am happy to learn that you found a solution to your problem. I would also like to thank you for your well written posts and your understanding of the forum. We are working on the issues you mentioned, and will get back to you once they are integrated. Unfortunately, I cannot say anything about our next release date, and if it will feature all the changes you mentioned.