TMS320F280049C: Controller fails to start motor at higher acceleration values

Ok thanks. We already planned to do this if we couldn't fix the problem another way.

spruhj1i - InstaSPIN-FOC and InstaSPIN-MOTION User's Guide (Rev. I) does discuss the situation I'm encountering in Section 14. Also, in section 11, viscous damping is mentioned as something most of the control loop analysis assumes is not present. I would assume the presence of viscous damping in this system is affecting the PI values I'm using. A few more questions.

1. Is there anything else we can adjust that affects how quickly we are able to execute the forced angle function at startup so that we lock in to the angle faster?

2. Do you have any additional resourced about tuning for the of load a pump presents to the motor?

I'm assuming that was a typo. Just to be clear, for the fastest startup, the user guide says to enable forced angle and disable Rs recalibration, not to enable both. Here's what's in the document. 

ver H, p. 527

14.5.1 Fastest Motor Startup with Full Load without Motor Alignment Considerations
The considerations discussed in the previous sections also apply to this mode of operation:
• Load valid offsets and disable offset recalibration; described in Section 14.5.1.1.
• Load valid Rs and disable Rs recalibration; described in Section 14.5.1.2
• Enable forced angle; Section 14.4.1.1.
• Tune speed controller to avoid motor stall; described in Section 14.2.1.4.
• Tune voltage feedback circuit; described in Section 14.2.1.5.

I am doing everything the guide suggests which is why I'm reaching out to you for further support. I'm trying to determine if I'm running into a fundamental limit with how the algorithm is implemented or if it truly is just a gain setting issue. The fact that the system is stable during operation and can accelerate/decelerate with proper dynamic performance, and maintain speed without issue once it starts, makes me think it's not the gains but rather something that's occurs at startup. I suppose it's possible that the initial conditions of the system might require vastly different gains to get moving and then the gains could be changed.

It seems the Rs-recalculation is different than Rs-recalibration. As I found out open loop does not close above 1Hz when Rs-recalculation is enabled, it has to be disable at some speed Hz before and after runSVM(). I'm wondering if ESMO would give better slow speed observation motor under load.

I tried to enable ESMO but ROM symbols are not in SDK4.01 or header include needs to be added to the project. May need to add _ESMO_ symbol in project properties for it to work. Seemingly also have to disable the EST_run (FAST estimator) to use ESMO.

Update: I had also imported ESMO folder into project, set include paths but ESMO_run command did not resolve. Supposedly x49c ROM embedded estimator has ESMO functions, Enhanced Sliding Mode Observer. Monitoring unloaded startup events (small 6 pole SPM) there often several ± hertz cycles prior to Lock Angle flag clearing. Was expecting FAST algorithm was modified and renamed ESMO, the most obvious thing to do. To me redesign would be odd step and not keep consistent name structures already defined SDK4.01(FOC) and earlier x68-x69 MCU SDK migrations. The one advantage of DM-ESMO being CLARKE 3 shunt inputs used ADC PPB, post processing blocks.    

The ESMO code has completely different structure does not keep consistent with Symbols SDK 4.01 and earlier. Using FAST estimator versus easily switching to ESMO in ROM will take few modifications.

Seemingly UVMCSDK modification would require hal.c (x25-MCU) copy/paste GPIO's from SDK4.01 (x49) to test ESMO/FAST observers build level 4. It might even be able to somehow merge (reference build) DM-ESMO project or create userParam symbols for portability backwards and forwards. Perhaps SDK4.01(FOC) could use a tune up, add ESMO mode for motor startup and allow switch to FAST mode > 5-10Hz is reached. Dual modulation methods are encouraged in several SVM articles.  

/* Initialize ESMO slider */
halHandle = ESMO_init(&hal, sizeof(hal));

//
// run the FAST or ESMO estimator, try switching on the fly
//
//EST_run(estHandle, &estInputData, &estOutputData);
ESMO_run(estHandle, &(adcData.dcBus_V), &(pwmData.Vabc_pu), &(Idq_in_A.value));

Yes. Rs-recalculation is done offline without running the motor when it's at standstill. Rs-recalibration is done online during the motor is spinning.

Yanming Luo said:

Rs-recalibration is done online during the motor is spinning.

Trouble being they renamed the calibration estimator function making function seem like recalculation. There is no recalibration call to the FAST estimator that I could ever find. The call name is different from the function name described Instaspin user guide. Hope was ESMO would be more robust and faster for loaded starts. The RS online was hit or miss and required 60-80 seconds to complete at times.

 EST_setFlag_enableRsOnLine(estHandle, motorVars.flagEnableRsOnLine); 

I'm not using the Rs online calculation function. We are also not performing any additional optional functions at startup that would delay the startup process (ie its performing startup as quickly as possible to best of my knowledge). A couple other observations. During previous testing, we used the same controller with a different motor that was connected to a much different load type (low inertia, low to no load at startup). With this motor, we were able to enter very large values for the acceleration parameter without issue. We did this during step change testing to determine response time, to confirm our speed gain calculations/values and to make sure the controller was limiting the peak current to the correct value during rapid acceleration.  The acceleration values we used during this testing were several magnitudes higher than what we need to use in the system that has the startup issue. There were never any issues at startup with the low inertia/load, even with extremely large acceleration values.

The high inertia/load system is behaving as if the trajectory outpaces the startup algorithm and once that occurs, it can never find the rotor position. Because it doesn't happen every time, it may depend on the random starting position of the rotor. The suggestion of slowing the acceleration at startup and then changing to another acceleration seems to support this theory because it gives the controller time to lock into the position and then once known it can accelerate faster without stalling. We have modified the system to allow this to be tested. I won't be able to test it until next week. I plan to leave the tread open until I do. 

I still think that there could be another parameter that could be adjusted to accomplish the same thing as a two step acceleration. Have you ever tried to adjust the Fe_min frequency? A motor with a lower number of pole pairs and high inertia/load at startup may require something other than 1Hz. I will also plan to test this.