mcb_eqep_f​oc_example​_with_f280​69M stops the motor abruptly when switching from open Loop to close loop control

Hey guys,

I am just trying to use the example of mcb_eQEP_example with F28069M with a cubemars motor.

It is jus as the title says, the motor spins well when starting, almost an entire rotatio.

But from what i see in the HOST (Simulink printed signal), when the "enablecloseloop" switches to 1, there is an abrupt incresing in the current, which doesn't look like an overcurrent to me, the drv8305 should be able to handle more than that. However the motor stops with big "clack" and the DRV goes to fault.

I have checked and checked my parameters, my encoder signal which to me looks okay and my current signal in simulink plots looks okay too.

Some hints i can check here?

Thank you guys.

[chynna]

I encountered the exact same issue with the F28069M launchpad. The abrupt motor stop when transitioning from open loop to closed loop is a common problem with the MCB implementation. The key is to ensure your encoder alignment is correct and that you're gradually ramping up the Id reference during the transition. I found that adding a soft-start mechanism for the q-axis current reference during the first few seconds after switching modes resolved the stuttering issue. Also double-check that your EQEP configuration is properly set with the correct PPR value. Hope cookie-clicker2

[jeff]

I mean how do you ensure that your rotor alignment is correct? In theory applying a vd != 0 until it is locked is how we do it, but i let the malab "rotor_offset_example" handle it, i just write it down in as a parameter in the MCB algo. I can' thin of anything other than trusting it.

Answer 1

[KrishnaKumar]

Here are a few points you can check -

• Use the open loop example (Example link) to check if motor rotates smoothly before using the present example.
• Was the encoder offset calibration performed for your encoder as described in the example page?
• Recheck your ePWM settings if they were modified, to ensure they do not lead to unintentional switching behavior.
• Do Motor parameters (Rs, Ld, Lq, flux, inertia, and pole-pairs for the Cubemars motor) match the values used in the model?

If any of these steps were skipped or only partially validated, issues can occur when switching to closed loop. In your case, it appears that an over‑current condition may be triggered, causing the DRV to shut down.

[jeff]

Hello Krishna,

open loop seems to work fine, even sensorless is fine. I can set a speed a adapt it and it runs smoothly.

• Offset calibration is performed everytime before i test. Then i note the offset mentionned and start to the eQEP example.
• Since my open loop and sensorless goes I assume the epwm I fine. I even checked the signals comming from the epwm pins on the oscilloscope, and they look like the sinusoid+3rd harmonic you expect, with the right input frequency that i entered (the frequency of my sinusoidal input).
• I entered the parameters that are on cube mars websites: 0.150mOhm, 0.187µH, 14pair poles as well as J=0.0001161kg.m² and Ke=8.28 and Kt=0.094 and I even ran Simu with those, and checked again and again.

I am using magnetic encoder AS5047D-TS.

[Shivaprasad Narayan]

You can further perform following tests to see if the issue is in position calculation or current control.

• Use the position computed by the quadrature decoder but break the current control loop. In order to do this, feed a constant 0 for Vd and 0.15 for Vq to the inverse Park transform block after the current PI controllers. This is expected to spin the motor smoothly if the position is accurate. Higher the Vq more will be the speed of the motor. If this test fails, the position calculation has issues. It could be in the offset compensation or position calculation itself.
• If the above check gives expected output, proceed to validate the current control loop. Undo the changes done in above step. Instead of sending Id, Iq references from speed control loop, send constant 0 Id reference and 0.05 Iq reference. the motor should again spin smoothly and reach the maximum possible speed. Higher the value of Iq reference, the motor accelerates faster. If the motor spin fails in this test, it is due to incorrect current control loop. Since you are using the same kit as the shipping example is intended for, I assume the current measurement is intact. Ensure the right motor parameters such as Rs, Ld and Lq are used, so that the current control is tuned correctly.

Answer 2

[jeff]

Hello guys,

I can confirm the error after reading the SPI. After reading the SPI the error is THE VGS_HA error which is "VGS gate drive fault for high-side MOSFET A".

But is suspect this error only comes after the PID+Driver are trying to solve the following one: The motor just doesn't rotate even when i feed the algorithm a constant Vq and Vd=0. This time it doesn't go to fault, it just doesn't rotate, more like it is servoed in that position (i cannot move it by hand).

Here is what i do basically:

• Run the program for computing the offset (provided by mlab) which is ususally arounf 0.045 P.U.
• Write in the script, pmsm.rotoroffset, then compile it. Now the complete Simulink algorithm can take it into account.
• The I load the program inside the board and run it.

So now i think I can establish that this is an encoder reading issue. However when i rotate the motor in openloop, I can see the signal following the position. So I can say that the position is correctly reported and read.

So in the video, the signal in the oscilloscope is a flag that is set when the algorithm switches to closed loop. Now it is not really a closed loop anymore since i force Vq and Vd, but the angle is still coming from the encoder. The rotation is done in open loop (algorithm generated angle).

Here the way the encoder is set: The "theata_e is fed to the Park after computing the sin/cos

I really don't see the problem.

Thank you all.

Regards,

[jeff]

Ok here is a moire accurate description of the behaviour: Image that the cercle below represent the possible position of the rotor (you can also consider the circumference only):

• When in the Red part, the rotor automatically rotates until it reaches the border of the yellow part, following the direction of the torque mentioned on the figure: The torque is the strongest here. So basically if I put the rotor somewhere in that part it will automatically rotates to find itself on the boudary between the red and yellowpart.
• The blue part has the same behaviour as the red, expect that the torque is lower opposed to T1 and the recall speed is lower. Again pacing the rotor anywhere in the blue part springs him back at the frontiere between blue and yellow.
• The yellow part is a "non torque part". There is no spring effect, no torque to reposition the rotor and the torque is the lowest. If the close loop starts when the rotor is there it will just not move.

I am starting to think that this is a mechanical issue with the motor.