warning: #47-D: incompatible redefinition of macro "SPD_TIM_M1_IRQHandler"

[llm]

I had a mc sdk problem like as this question: https://community.st.com/s/question/0D53W00000S6AdLSAV/driver-motor-program-error-when-i-use-hall-sensor-and-encoder-at-the-same-time

My platform is: stm32f446re, MotorControl Workbench 5.4.7,mdk-arm v5,STM32 F4 FW V1.26.1.

I used both the Hall sensor and the encoder, the encoder serves as the Main sensor and the Hall sensor as the Auxiliary sensor.

when I build the code, there is a warning: ../mx/Inc1/parameters_conversion.h(283): warning: #47-D: incompatible redefinition of macro "SPD_TIM_M1_IRQHandler" (declared at line 273).

when I run and debug the code, it alway run to the default_handler.

when I disable the irq of the tim2 tim3 tim4 and tim5, this would disappear.

Could you fix this bugs?

[cedric H]

Hello @llm​,

This configuration is not supported by the MCSDK.

In the next version of the MC Workbench we will prevent the user to select a sensor at main sensor and another sensor at auxiliary sensor.

The same question is already answered here :

https://community.st.com/s/question/0D53W00001BRIRoSAP/bug-report-mcsdk-5y3-generated-code-has-macro-redefinition-and-undefined-identifier-errors

Regards

Cedric

[llm]

"In the next version of the MC Workbench we will prevent the user to select a sensor at main sensor and another sensor at auxiliary sensor.", does it mean the mcsdk can not drive the motor that have encoder and hall sensor?

[cedric H]

Hello @llm​ ,

MCSDK is able to drive a motor without any sensor, or with an encoder, or with hall sensors.

Could you describe your application and how do you want to use both sensors from application point of view ?

For your information, the primary target of the MCSDK is to demonstrate our board capacities. Up to know, all our power boards share the same pins for Hall sensors and encoder, this is the reason why we have an exclusive support. This is NOT a stm32 limitation.

Regards

Cedric

[llm]

I have used other boards can drive motor with hall sensors and encoders. My application is hall sensors are used to switch phase, and encoders are used to measure speed and position closed loop control.

I also want to get precise position of the motor from the encoders. Of course the MCSDK can drive motor only use the encoders without the hall sensors. But for a motor with hall sensors and encoders,

is it more easily to drive the motor with the hall sensors and encoders?

So how to config the MotorControl Workbench to use hall sensors and encoders at the same time?

我用过一些其他的电机驱动�?�，普�??都有�?尔传感器和编�?器接�?�。我的应用就是�?尔传感器用�?��?�相，编�?器用�?�测速以�?��?置闭环控制。

我还需�?通过编�?器获�?�电机的精确�?置。MCSDK当然是�?�以�?�用编�?器或者�?尔传感器驱动电机。但是对于�?�时带有编�?器和�?尔传感器的电机，

两者都用�?�驱动电机是�?是更好，算法更简�?�。这样就�?�以�?�挥他们两个的最大作用。

[llm]

I have used other boards can drive motor with hall sensors and encoders. My application is hall sensors are used to switch phase, and encoders are used to measure speed and position closed loop control.

I also want to get precise position of the motor from the encoders. Of course the MCSDK can drive motor only use the encoders without the hall sensors. But for a motor with hall sensors and encoders,

is it more easily to drive the motor with the hall sensors and encoders?

So how to config the MotorControl Workbench to use hall sensors and encoders at the same time?

[THA.1]

I am also interested in this topic as I'm considering the same use case as zwb's, where hall sensor provides absolute phase data, then some benefits could be achieved such that the initial rotor alignment is not required, compared to the encoder-only case. This use case - encoder as main sensor and hall as aux sensor - would be common for motors with both sensors.

I would like to recommend ST provides MCSDK to support this use case, or at least provides a guide so that one could customize the generated source code like as https://community.st.com/s/question/0D53W00000S6AdLSAV/driver-motor-program-error-when-i-use-hall-sensor-and-encoder-at-the-same-time - probably he needed more work to resolve conflicts between both sensor handlers.

I'm afraid if ST prevents even selecting both sensors on Workbench, then more complicate & difficult work will be required to implement this case.

[llm]

I also think there is no need to align the encoder if the encoder just be used to speed closed-loop control.​