MSDK 5.y.4. Incorrect operation of the encoder alignment function.

[MK.1]

Hello,

When working with an incremental encoder, after performing the encoder alignment procedure, it is imperative to perform the function

 MC_StopMotor1();

Otherwise, the current (Id ref) is incorrectly set, which can lead to overheating of the motor.

This problem is especially relevant in the position control mode, since in this mode the motor stop function is not used. 

Best regards.

[DBE · Accepted solution]

Hello MK.1

The MC_StopMotor1() is implicit in a sense that at the end of the alignment state the PWM are switched off and restarted when we go to run state. The issue here, in a position control project, is that the call the FOC_Clear(M1) routine (which clears the current references among other things) is missing at the end of the alignment. If you add this call before exiting the alignment state, it should solve your issue.

Best regards

[MK.1]

Thanks for the reply and advice. I will try to use this. But, on the other hand, I will answer the following:

-the problem is present in all modes, including speed and torque mode

-during the encoder alignment process, the current value (Id ref) should take the value 0, which does not happen. I hope you take this into account in future updates.

Best regards.

ps sorry, I'm using a translator

[SCrum.1]

Hi, I was just going to post on this and noticed you had beaten me to it. Glad to confirm this is a bug and not something wrong with my setup. I think this is not new to the latest release either, and yes it affects torque, speed and position control configurations, although you notice it more with position control because the motor is generally not doing anything immediately after the alignment in position control mode.

[MK.1]

That helped. Thanks!

[MK.1]

 Hi,

add the following line to the mc.task.c file

      /* USER CODE BEGIN MediumFrequencyTask M1 EndOfEncAlignment */

       FOC_Clear(M1);

       /* USER CODE END MediumFrequencyTask M1 EndOfEncAlignment */

this will solve the problem

[THA.1]

Hi, I wonder if it is the same issue for SDK 5.y.3 which I'm using for my project.

In SDK 5.y.3, FOC_Clear(M1) is executed at ANY_STOP state after alignment - is it different in SDK 5,y.4?

=========================================================

case ALIGNMENT:

...

/* USER CODE BEGIN MediumFrequencyTask M1 EndOfEncAlignment */

    /* USER CODE END MediumFrequencyTask M1 EndOfEncAlignment */

   STM_NextState( &STM[M1], ANY_STOP );

...

 case ANY_STOP:

   R3_2_SwitchOffPWM( pwmcHandle[M1] );

   FOC_Clear( M1 );

================================================================

[MK.1]

Hi, in version MSDK 5.y.4 the state machine has been changed (simplified). New state machine...

 the ANY STOP state machine no longer exists

typedef enum

{

 ICLWAIT = 12,     /*!< Persistent state, the system is waiting for ICL

              deactivation. Is not possible to run the motor if

              ICL is active. Until the ICL is active the state is

              forced to ICLWAIT, when ICL become inactive the state

              is moved to IDLE */

 IDLE = 0,       /*!< Persistent state, following state can be IDLE_START

              if a start motor command has been given or

              IDLE_ALIGNMENT if a start alignment command has been

              given */

 ALIGNMENT = 2,    /*!< Persistent state in which the encoder are properly

              aligned to set mechanical angle, following state can

              only be ANY_STOP */

 CHARGE_BOOT_CAP = 16, /*!< Persistent state where the gate driver boot

              capacitors will be charged. Next states will be

              OFFSET_CALIB. It can also be ANY_STOP if a stop motor

              command has been given. */

 OFFSET_CALIB = 17,  /*!< Persistent state where the offset of motor currents

              measurements will be calibrated. Next state will be

              CLEAR. It can also be ANY_STOP if a stop motor

              command has been given. */

 START = 4,      /*!< Persistent state where the motor start-up is intended

              to be executed. The following state is normally

              SWITCH_OVER or RUN as soon as first validated speed is

              detected. Another possible following state is

              ANY_STOP if a stop motor command has been executed */

 SWITCH_OVER = 19,   /**< TBD */

 RUN = 6,       /*!< Persistent state with running motor. The following

              state is normally ANY_STOP when a stop motor command

              has been executed */

 STOP = 8,       /*!< Persistent state. Following state is normally

              STOP_IDLE as soon as conditions for moving state

              machine are detected */

 FAULT_NOW = 10,    /*!< Persistent state, the state machine can be moved from

              any condition directly to this state by

              STM_FaultProcessing method. This method also manage

              the passage to the only allowed following state that

              is FAULT_OVER */

 FAULT_OVER = 11,    /*!< Persistent state where the application is intended to

             stay when the fault conditions disappeared. Following

             state is normally STOP_IDLE, state machine is moved as

             soon as the user has acknowledged the fault condition.

           */

 WAIT_STOP_MOTOR = 20

} MCI_State_t;

[THA.1]

Thank you ! It looks like SDK 5.y.4 has more major changes compared to the small version up.

Regards,

THA.1