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.