STC_CalcTorqueReference function

[SRedd.5]

In the __weak int16_t STC_CalcTorqueReference(SpeednTorqCtrl_Handle_t *pHandle) function 

The original ST code contains the below line code.

hMeasuredSpeed = SPD_GetAvrgMecSpeedUnit(pHandle->SPD);
hError = hTargetSpeed - hMeasuredSpeed;
hTorqueReference = PI_Controller(pHandle->PISpeed, (int32_t)hError);

I modified the first line of code to

hMeasuredSpeed = -SPD_GetAvrgMecSpeedUnit(pHandle->SPD); i put a negative sign before the function.

This i have done since the error was never going to 0. Is it correct or i need to remove the negative sign? I have start up issues is it because of this?

[FouadB]

Hello,

The speed parameter returned by the SPD_GetAvrgMecSpeedUnit function contains the direction of rotation. Reversing the sign of the estimated speed value, as you have done, will reverse the speed at the input of the speed regulator. This explains the startup issue reported, as your control will never converge during the startup phase.

Best regards

[SRedd.5]

Thank you for the reply, i will remove the negative sign and verify if the startup issue is resolved and update.

[SRedd.5 · Accepted solution]

I changed the sign and tested the issue remained same, the issue resolved by changing the HALL_PHASE_SHIFT

to different angle. I have a real challenging understanding this. The way i have found this issue is with HALL_PHASE_SHIFT set with original value, it was jerking in the forward direction and not jerking in the reverse direction and i changed the sign of the HALL_PHASE_SHIFT and it is not jerking in either forward or reverse direction, slight jerk is still there some times i need to resolve that as well. Do i have a mechanism from which i can confirm if my Hall_phase_shift is correct. By reading one of the posts in these forums i understood that the raising edge of Hall1 signal shall match with zero point of U phase current. Is it correct?  

[cedric H]

Hello @SRedd.5 ,

Thanks for your post and sharing your findings with us.

Few comments on my side. When I read back your initial post, I notice that you did not mention that you are using Hall sensors, so do not hesitate to describe your configuration accurately. In your post, you ask us if your start up issue is coming from a modification of the source code that you did. Please be aware that modifying the source code of the motor control librairie could be dangerous as it potentially drives high current and/or high voltage, so I really advise you to modify the sources very carefully with a deep understanding of the consequences of your modifications. 

Finally, to answer your question about Hall sensors, you have to understand that motor control algorithm relies on the electrical angle. The Hall sensors will provide you an angle information relative to the physical placement of the sensors, but not aligned with the electrical angle. The electrical angle is computed by the software thanks to the HALL_PHASE_SHIFT.

As the Hall sensors could be tricky to tune, we developed a specific part in the profiler tool that computes for you the HALL_PHASE_SHIFT. We have a limitation with the release 6.2.0 that unfortunately makes this feature functional only for STM32G4 ( a fix for STM32F3 is available in this post ).

Let us know what your configuration is, we will see how to help you further.

Regards

Cedric 

[SRedd.5]

Thank you very much for the reply, sorry that i have not included the details of my configuration, i will start doing from now, this post i have created to solve the issue raised by me 

https://community.st.com/t5/stm32-mcus-motor-control/hall-speed-back-fault-error/m-p/595467#M8244 

I will start using the Motor Pilot more frequently now, as i can see benefits understanding the motor parameters and other features. I will update once i am successful connecting the motor pilot with my custom board and see if i can measure Hall_phase_shift, i am using the STM32G4 series.