• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 83 subscribers
  • Views 845 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28069M: EST_getOneOverDcBus_pu() 'trapped' at result _IQ(100.0)

Martin Bayer
Prodigy 140 points

Part Number: TMS320F28069M
Other Parts Discussed in Thread: LAUNCHXL-F28069M, MOTORWARE

Situation : Using LAUNCHXL-F28069M with InstaSpin motorware 17 'proj_lab11a' in a high voltage BLDC prototype sample

Hi,

I am faced with with following Problem:

For our target application, we create a high voltage electronic hardware with dual supply : 

- 12V supply for the control system, i.e. launchpad F26069M , gatedriver and current amplifier

- 400V supply for powerstage

The 400V supply is allowed to be switched on/off during a regular operation session, while the 12V supply is continously powered.

The issue is, that after switching the 400V supply off and on again (i.e. the 400V voltage has been dropped to '0V'), a motor start attempt failed (directly high motor phase currents, not sinus shaped as intended).

I found out, that I can avoid the effect, by limiting the 400V voltage signal (gAdcData.dcBus) to a min-value of about 20V, i.e. in case of switching off the 400V supply, the internal signal  (gAdcData.dcBus) drops not to '0' but to a value of about _IQ(0.04).

Further Investigation Shows, that the effect is associated with the result of function call  'EST_getOneOverDcBus_pu()'.

Usually the result is plausible and changes according the gAdcData.dcBus -signal, which is feeded to the estimator :

// run the estimator

EST_run(estHandle, &Iab_pu, &Vab_pu, gAdcData.dcBus,TRAJ_getIntValue(trajHandle_spd));

 

In case of the gAdcData.dcBus -signal falls below a certain value, which results in an 'EST_getOneOverDcBus_pu()' output of _IQ(100.0), this output-value is frozen.

It is not possible to release this 'trapped' situation , even if the gAdcData.dcBus -Signal is lifted back to higher (regular) values.  

 

For the moment I can work with my 'high voltage low limit patch'.

However I am  interested in understanding the issue, i.e.

-  is the obeyed behaviour as intended

- should I use a diagnostic feature of  InstaSpin software to detect such a situation 

- is the malfunctioning situation induced by violation of  any  boundaries

 

Regards

Martin

 


  • 0
    Intellectual 655 points

    Hello Martin,

    The way you are treating the EST while switching off the bus voltage is uncommon, and the system does not handle this as expected. The OneOverDcBus follows the inverse of the bus voltage, and is limited to 100, so any value below 1/100th of the full scale voltage causes the OneOverDcBus to be limited to 100. Usually the MCU is powered from the dc bus, and the MCU would lose power before this issue would occur.

    I am assuming you understand the bus voltage compensation and PID controllers, If not, please read up on those subjects.

    The OneOverDcBus is used for bus voltage compensation of the D and Q current PID controllers, and should give a (slightly) higher duty cycle when the bus voltage is (slightly) lower. You can see this in CTRL_runOnLine_User() and CTRL_runOnLine(). The PID controller Kp values are adjusted by multiplying them with the OneOverDcBus.

    If OneOverDcBus is _IQ(100.0), there is a risk of the adjusted Kp going above _IQ(127.99), causing an overflow problem. To prevent this potential overflow problem, I used the following change:

    // compute the Kp gain
// Scale Kp instead of output to prevent saturation issues
if(CTRL_getFlag_enableDcBusComp(handle))
{
    Kp_Id = _IQrsmpy(Kp_Id,EST_getOneOverDcBus_pu(obj->estHandle));
               // IQrsmpy instead of IQmpy
}

    Do this for the Id and Iq current controllers, in CTRL_runOnLine and CTRL_runOnLine_User.

    The OneOverDcBus is updated when EST_run is called. The DC bus filter pole USER_DCBUS_POLE_rps is related. Depending on full scale voltage values and things like the EST_FREQ_Hz it seems possible that the filter is trying to adjust the OneOverDcBus with such a small value that it is lost in rounding. This could cause the OneOverDcBus to get stuck. I have not tried this, it is something I would need to run some tests on.

    A workaround would be to keep the value you report to EST_run within a usable range. This is usually automatically the case when powering the MCU from the same bus, so most people will not have this problem.

    When actually running the current controllers with dc bus compensation active the correct bus voltage should be reported to EST_run, but there is no danger in reporting a minimum of say 100 volt while the current controllers are not active. Reporting 100V keeps your OneOverDcBus at around _IQ(5.0) instead of clipping at _IQ(100.0).

    While testing, a check to make sure the OneOverDcBus is within a usable range before turning on the PWM seems sensible.

    Best regards,

    Rob.