MCSDK 5.4.3/5.4.4. FOC ,Sometimes after encoder alignment ，motor run reverse。

[CQi.1]

Hi!

I have an I-PMSM motor and interfaces an incremental encoder with A B ,without Z.

Sometimes after doing encoder alignment，the motor runs reverse to the max speed,and it will never recover until i do encoder alignment again。

I set the speed 30RPM,but when start ,the motor goes to -200+RPM.

Most time the motor runs well but sometimes the problem will happen.

（STM32 F303VCT6 ；PWM16000KHZ ；Main Sensor ：Incremental Encoder2048 no Z-index）

I hope someone could help me figure out the problem.

Best wishes.

[intek]

Hello

We increased the motor current and duration during alignment. This seems to help, although we couldn't completly eliminate the problem. But the problem seems to come from a misalignment during start-up.

Best regards

[ypu]

I did below and the issue does not happen till now.

1. change the duration from 700ms to 2000ms as ST recommended

2. change the current from 1.95A to 7.5A (half of rated current) as ST recommended 

3. directly give a 2V on U-V, and record the position

4. adjust alignment electrical angle, make the rotor the same position as 3, the electrical angle is 60 degrees, then I use " alignment electrical angle = 60 degrees"

With only 1 and 2, the occurrence is lower but the issue still happens sometimes, with 3 and 4, the issue does not happen

Our supplier suggest us to use encoder for speed sensing and Hall sense for commutation, to permanently avoid this risk.

which is not supported originally in  MotorControl Workbench, we would like the explore this option but we would like to know if there is any constraint on the STSPIN3201 hardware side?

regarding your reply 2, high frequency interrupt, I guess you mean high frequency injection?

high frequency injection is not supported in SPIN3201 board (or maybe does not supported in  Workbench 5.4.4).

[Bardeen Lai]

OK,

Regarding my suggestion 2, you could modify the mc_tasks.c,

/**
  * @brief It executes the core of FOC drive that is the controllers for Iqd
  *        currents regulation. Reference frame transformations are carried out
  *        accordingly to the active speed sensor. It must be called periodically
  *        when new motor currents have been converted
  * @param this related object of class CFOC.
  * @retval int16_t It returns MC_NO_FAULTS if the FOC has been ended before
  *         next PWM Update event, MC_FOC_DURATION otherwise
  */
inline uint16_t FOC_CurrControllerM1(void)
{
  qd_t Iqd, Vqd;
  ab_t Iab;
  alphabeta_t Ialphabeta, Valphabeta;
 
  int16_t hElAngle;
  uint16_t hCodeError;
  SpeednPosFdbk_Handle_t *speedHandle;
 
  speedHandle = STC_GetSpeedSensor(pSTC[M1]);
  hElAngle = SPD_GetElAngle(speedHandle) + m_eAngleAdjustment;
  PWMC_GetPhaseCurrents(pwmcHandle[M1], &Iab);
.
.
}

Another suggestion to you, try to modify the enc_align_ctrl.c, make the alignment twice. The angle must be 90 degree applied to Iq (ST default setting)

Your case is pretty weird, have you checked very carefully about the 3.3VDC power source to MCU and the 5VDC power supply to the motor encoder?

The SVPWM produces (MOSFET switching on and off) noises causing the encoder output signals badly. Make sure you have band-pass filters (LCR networks) to screen 16KHz ripples when SVPWM is working. Also, check the encoder output signals whether are differential or TTL.

Finally, when kind of current sensing techniques you are using ICS or 3 R-SHUNT or 1-SHUNT, the power source 3.3VDC to the Op-Amp is crucial. The FOC algorithm runs "crazy" because of bad current sensing feedback.

Honestly speaking, the ST FOC, so far is pretty stable but you have to do some customizations in order suite your working conditions.

Cheers

[ypu]

try to modify the enc_align_ctrl.c, make the alignment twice. The angle must be 90 degree applied to Iq (ST default setting)

• do you mean both I set to 90 degree? (if the possibility of fail doing once is 1/100​, then doing twice is 1/10000?)
• is there any reason need to set it to 90 degree? I feel it is "easier" to align it to 60 degree, because that is position when you directly give voltage on U-V

have you checked very carefully about the 3.3VDC power source to MCU and the 5VDC power supply to the motor encoder?

• I use 5V on motor encoder and added resistor to divide the voltage and also capacitor, the encoder signal is very clean.

The FOC algorithm runs "crazy" because of bad current sensing feedback.

• that is true, the DCDC of SPIN3201 has some noise, and my issue also happen on ST's evaluation board, I plan to change the DCDC to LDO in my next version.

could explain a little bit more how your suggestion solve the problem when "some motor manufacturer could not align the motor properly"?

[Bardeen Lai · Accepted solution]

Hi

1. Please try to google "initial rotor position alignment method", you could get much more ideas to do proper alignment for incremental encoder. Once you get some ideas, modify the enc_align_ctrl.c, the default ST MCSDK just does the alignment once. However, you could do the alignment again after 10~100ms delay to wait for rotor stable. If your problem still persists, consider to use BDLC with Hall-Effect Sensor, drive it by using 6-steps together with sinusoidal PWM. It would even be less cost concern compared with incremental encoder. The efficiency is not bad, pretty close to FOC but the torque ripple is not as good as the FOC.
2. Also, you could utilize ST Motor Control Workbench, run the Monitor, try to plot and study some Motor runtime variables, for example, Iq and Id (you should modify the MCI_***)
3. Use oscilloscope to monitor the Ia, Ib (measured by ADCs), dump these values via DAC or PWM (you have to use RC to do conversion), whether these values look like sinusoidal wave forms
4. Make sure your 3.3V or 5V DC, pk-pk < 100mV or even lower when the motor is not running. LDO is a good choose but power dissipation is an issue if VBus voltage is higher than 12VDC. I recommend that use DC-DC step down. ST provides many switching IC for this kind of applications.
5. Again, use RLC filter (band-pass filter) to screen 16KHz ripples from the VBus to your MCU and Encoder

Cheers

[ypu]

we have finally solved this, we summarized two ways:

1. run alignment twice to different angle, and count the encoder number, to make sure the motor is aligned in correct position
2. use encoder for speed measurement and use hall sensor for commutation. (since hall sensor has much less pulse than encoder, so only use hall sensor can not control the motor in low speed)

we finally used 2nd way and it is working fine now.

[B.4]

Hi @ypu​ ,

I want to try second way, please explain configuration and Connection (like main & auxiliary) of the sensors.

[ASaha.3]

I am trying to work around this issue by removing the alignment process ,calculating the initial angle required by FOC from the hall sensors. It is working for few angles only. Has anyone tried this yet? Or succeeded to bypass the alignment error issue??

[Rajeswari]

why 16kHz ripple?

[Zain]

Hey,
I am trying to do this exact thing. Have you found any algorithm/solution to this? I need to avoid startup motor running to find index, instead i want to estimate some initial angle and then correct it while i receive index, that will be in one electrical cycle but i want motor to be ready on startup and foc should be working.