TMS320F28069F: Unit delay in rotor position estimation due to bug in Lab 11e during FAST operation

Part Number: TMS320F28069F

Hi all,

I've come across what I think is a bug in Lab 11e. This bug occurs while running above the transition frequency, so should only be running in FAST mode. If we look at the very end of the control loop part of mainISR. My code differs slightly from the lab here because I'm using LEM current sensors instead of shunts, so I don't need to run current reconstruction or compensation.

      // compensate angle for PWM delay
      angle_est_pu = angleDelayComp(speed_est_pu, angle_est_pu);

      // compute the sin/cos phasor
      phasor.value[0] = _IQcosPU(angle_pu);
      phasor.value[1] = _IQsinPU(angle_pu);

      // set the phasor in the inverse Park transform
      IPARK_setPhasor(iparkHandle,&phasor);

      // run the inverse Park module
      IPARK_run(iparkHandle,&gVdq_out_pu,&Vab_pu);

      // run the space Vector Generator (SVGEN) module
      oneOverDcBus = EST_getOneOverDcBus_pu(estHandle);
      Vab_pu.value[0] = _IQmpy(Vab_pu.value[0],oneOverDcBus);
      Vab_pu.value[1] = _IQmpy(Vab_pu.value[1],oneOverDcBus);
      SVGEN_run(svgenHandle,&Vab_pu,&(gPwmData.Tabc));

      // run the PWM compensation and current ignore algorithm
      // ONLY FOR SHUNTS SVGENCURRENT_compPwmData(svgencurrentHandle,&(gPwmData.Tabc),&gPwmData_prev);
      // Run BLDC
      HALLBLDC_Ctrl_Run();
      gTrjCnt++;

Note that the angle out of the estimator angle_est_pu is not used in the inverse Park transform. The value angle_pu,gets set only in HALLBLDC_Ctrl_Run() . This means that the angle_pu going into inverse Park is actually one control loop behind, and my test data shows the measured phased angle matching the change in angle during one control loop based on no-load operation and expected Vd, Vq vs actual Vd Vq.

So, what should be the fix for this? Should the variable going into inverse Park just be angle_est_pu ?

Best,

Will