TMS320F280049C: Porting from 28069F to 280049C

1. Even the F28069 has an FPU, so your code can run in floating point mode even there. If you are using IQMath, you can set MATH_TYPE to FLOAT_MATH, and you should be good - both on the F28069 as well as on the F28004x.

The other questions will need to be addressed by someone else.  I have requested support.

Thanks,

Sira

Mojo23 said:

IQmath – I notice all implementation on the 49C is floating point (very good!). Do I have to switch to float or can I stay with IQmath like in the 69? Any recommendations?

You can just use the floating-point as shown in the InstaSPIN example labs in motor control SDK.

Mojo23 said:

What is the fluxHF.lib? Do we need it?

It's only for low inductance motor. You can refer to the InstaSPIN example labs in motor control SDK to use it if needed.

Mojo23 said:

  3. If there’s any porting document between 69 and 49C – that will be great to have.

You may just need to port your own codes to the InstaSPIN-FOC example lab for F280049C, and don't change the codes for motor control with InstaSPIN-FOC.

Thanks Yanming.

can you please also elaborate one the difference between libraries ? Do I need to include any of the new libs that  are used in the 49C, into the original 69 code? Question #2 in my original post.

Thank you!

Ok thanks. That's a big difference..

What do you think of this:

- Remove the 2806xRevB_FastSpinROM library.

- see what gets broken

- fix the calls to FAST libraries with actual values (not PU).

- add F28004x_fast_rom library.

- recomplie.

next step - any suggestion how to verify the changes went ok? maybe inject (create internally in the code) phase voltages and phase currents and see that the angle estimation is ok and speed is ok? any other suggestions?

thanks!

I have sent you a private message. thanks.

Hi Yanming,

I think your suggestion to use one of the 49C labs and port our system code is good.

I'm going to use is13_fwc as starting point.

A few questions please:

1. Is there documentation for the labs like the 69 had?

I could only find "MotorControl SDK" doc, which is VERY short.

2. Is there a version of the projects that has the source code behind some functions, such as:

USER_setParams_priv

Interrupt_initModule

Interrupt_initVectorTable

3. What's the "EST Trajectory" (i.e. EST_enableTraj) ? We didn't have that in the 69.

Especially I'm worried about things that can disable the control, such as EST_isTrajError.

4. For speed and current trajectory, we're using our own implementation (similar to TRAJ_run). Is it still necessary to use the EST trajectory?

such as:

EST_enableTraj

EST_configureTraj

EST_updateTrajState

In the 69 the EST didn't have those trajectories.

5. In the 69 we had a function to check for user errors - USER_checkForErrors

Is it still available on the 49C ?

thanks!

About The USER_setParams_priv - do I need to call it each time I change a param in userParams ? Is there a particular order of calling the functions that use userParams?

About EST_isTrajError - can you please explain under what circumstances this function returns an error?

About trajectory - Is it necessary to run the EST trajectory also when doing RsRecalc ? I assume yes, but want to be sure.

Another thought, if you can please clarify:

- For just running the motor, I should use the ISR and the relevant parts in main from is13.

- For motor ID and Rsrecalc, I should use the ISR and the relevant parts in main from is5.

Is that correct? recommendation?

I only need Motor ID and Rsrecalc besides running the motor.

Thank you Yanming.

About setParam_priv - If I'm setting also the userParams.flag_bypassMotorId do I need to call again the setParam_priv ?

- Is userParams.flag_bypassMotorId the only flag to set to enter MotorID? How does the EST knows to do Motor ID? Is it through EST_setParams(estHandle, &userParams) ?

- to get into Motor ID or Rsrecalc, can I just use the EST_setFlag_motorIdentified and EST_setFlag_enableRsRecalc ?  what's the correct way?

A few more logistic questions:

1. Does the f28004x_fast_rom_symbols_fpu32 replaces rts2800_fpu32 ? Can we use the fast FPU library?

2. The f28004x_fast_rom_symbols_fpu32 has 3 versions - one with coff, one with eabi, and one without. I'm using the coff variant for the labs (is13 and 05). Do I need to use the f28004x_fast_rom_symbols_fpu32_coff ? at the moment in is13 the f28004x_fast_rom_symbols_fpu32 is linked.

3. same question as (2) but for fluxHF.

Thanks!

Hi Yanming,

Unfortunately, I won't be able to integrate the Motor ID functionality due to some time constraints.

We will try to run without.

The motor we're driving is delta-connected PM.

I have from the manufacturer:

Ld = Lq - Line-to-line value. (it's a surface mount PM, so I guess this is some average value).

Rs - Line-to-line

BEMF constant in V*s/rad.

Should I do some transformation to be able to use these values in the user.h file?

If so, can you please provide the required transformation?

Thanks!

It's better to run the parameters identification lab (is05) to identify the motor parameters, and then use the identified motor parameters.

It's not possible at this point.

Can you please provide the info I requested?

Thanks

Thank you.

Another question that came up - In lab is05, we find these lines:

why are we setting the Id ref BACK to the estimator, while we got it FROM the estimator 2 lines prior?

Thanks!

ok thanks.

So if I'm not using Rs-online I can delete this line:

 EST_updateId_ref_A(estHandle,
                               (float32_t *)&(Idq_ref_A.value[0]));

?

In the chapter it says:

Once I convert from Rs(delta) to Rs(Y) - by dividing by 3 - do I still need to divide that again by 2, per eq.17 ?

Or asking differently - once I convert from delta to Y, do I get the equivalent L-L  or L-N resistance ?

thanks!

Thanks Yanming.

I'm experiencing a strange behavior and would like to confirm with you.

I'm running lab is05.

During Motor ID, when the EST gets to Ramp-Up stage, it seems that it's changing to speed control.

however, the outMax,min of the speed controller is zero (during R over L and Rs it's not zero).

I can see the speed ref getting updated, but the reference to Iq controller is zero, because of the above.

Only when we get to RATED_FLUX state the speed controller Max/Min updates.

Any idea?

Ok thanks.

So how the motor is supposed to spin? I see the ref to the Id controller to be 40A (that's our Rs calc current), but reference to the Iq controller is zero.

There's something else that is happening - As soon as we get to Ramp-Up stage, we get an overcurrent protection.

We set all max currents in the userparam to be around 20-40A, current limit is at 80A.

So I guess there's a big jump in the output voltage between RS and RAMP-UP

But this is strange because Id_ref is the same is in RS-state, and Iq ref is zero...

Any idea what can cause this?

Can you please share what parameters are involved to calculate the Kp, Ki gains of the Id,Iq controlllers?

My thought is that the gain is too high.

Or a reset of one of the Ui when moving between RS and Ramp-up ?? that would cause some instability for sure.

Any thoughts on which variable to look at / what to debug - will be great!

Thanks!

Mojo23 said:

So how the motor is supposed to spin? I see the ref to the Id controller to be 40A (that's our Rs calc current), but reference to the Iq controller is zero.

Did you use lab02 and lab03 to verify the current and voltage sensing on your own hardware board first? The sensing signals are very critical for the motor ID.

Mojo23 said:

There's something else that is happening - As soon as we get to Ramp-Up stage, we get an overcurrent protection.

Is the motor identification working without load?

You may try to tune the identification variables in the file of the user header file according to the motor.  And don't add any load on the motor when run this lab for motor parameters identification.

#define USER_MOTOR_RES_EST_CURRENT      (1.0)                               // A -  10-30% of rated current of the motor

#define USER_MOTOR_IND_EST_CURRENT      (-1.0)                             // A -  10-30% of rated current of the motor,  just enough to enable rotation

#define USER_MOTOR_MAX_CURRENT            (5.0)                               // A -  30~150%  of rated current of the motor

#define USER_MOTOR_FLUX_EST_FREQ_Hz     (40.0)                            // Hz - 10~30% rated frequency of the motor

Mojo23 said:

Can you please share what parameters are involved to calculate the Kp, Ki gains of the Id,Iq controlllers?

As mentioned above. The Kp and Ki will be set automatically according to the identification coarse R and L in EST_STATE_ROVERL state.

Mojo23 said:

Or a reset of one of the Ui when moving between RS and Ramp-up ?? that would cause some instability for sure.

Tuning the variables as mentioned above, and make sure that the current and voltage sensing signals are good enough for motor control.

Thanks Yanming.

We are currently commissioning all the analog signals and makiing sure everything is correct.

In the meantime I have a slightly different question:

The motor we're running is delta-connected.

I know and read lots of threads on the fact that FAST doesn't care about the connection type etc.

I wonder though about the estimated angle - If the angle is estimated for a wye-connected equivalent structure, should that be converted to delta angle ?

for example - We know that zero angle is not the same for wye and delta, and there's 30 deg between them.

How is that being handled?

Thank you Yanming.

My question was about the angle, not motor params.

can you please share any thoughts about that?

Hello Yanming,

Our motor is spinning and the angle estimation looks smooth.

However, we got some strange phenomena:

1. The electrical speed estimation is way off (seems like x5-6, changing as speed changes. We took into account that it's in rad/sec, but still off). When looking at the angle (using CCS graph), the period of the saw tooth is correct, compared to phase current period on a scope.

2. We get very high reactive power.

3. Vd is positive (we're doing Id=0 control, Iq ref is positive). Positive Vd doesn't make sense.

To us, it seems there's a 90 deg shift somewhere.

Is it possible to see a space vector diagram of the d-q frame and the where the angle is in the FAST system?

We get to this conclusion by looking at this picture (from "InstaSPIN Projects and Labs User’s Guide", lab is03):

You can see that at zero angle (yellow at zero), the SVM for phase A is at zero. Usually at zero angle the SVM for phase A should be at maximum (since the BEMF is at max).

This leads us to a conclusion that something is off by 90 deg - our thought is that you're using a d-q reference frame where q is pointing downwards?

However, the next picture is more confusing, since the peak of the Phase A current is aligned correctly with the SVM:

some more details - we're using the struct estOutputData to get the angle and the electrical speed (angle_rad and fe_rps, respectivly). It's interesting though that while the system is running, the timeStamp is continuously zero.

is that normal? maybe we should use the est_Get functions for the angle and speed?

Thanks for any insights!!

Mojo23 said:

1. The electrical speed estimation is way off (seems like x5-6, changing as speed changes. We took into account that it's in rad/sec, but still off). When looking at the angle (using CCS graph), the period of the saw tooth is correct, compared to phase current period on a scope.

Can you check if the pole pairs of the motor, control ISR period are set correctly?

Mojo23 said:

Is it possible to see a space vector diagram of the d-q frame and the where the angle is in the FAST system?

The angle is the rotor angle that is not related to the frame.

Mojo23 said:

is that normal? maybe we should use the est_Get functions for the angle and speed?

Please refer to the example lab to get the angle and speed that could be the same values as in estOutputData.

Can you check if the pole pairs of the motor, control ISR period are set correctly? Yes they are correct.

what else can cause this?

The angle is the rotor angle that is not related to the frame. - I strongly disagree. There are multiple ways of defining the ref frame and that will determine the angle.

Do you use ref frame where d axis is pointing right, and q-axis is pointing upward or downward?

Why do we get positive Vd?

why the timeStamp is continuously zero ?

Mojo23 said:

what else can cause this?

Did you check if the frequency (Hz) of the angle and current is close to the target speed frequency (Hz) you set? Which example lab are you using? Did you set the right motor parameters?

Mojo23 said:

Why do we get positive Vd?

Ideally, the Vd should be close to zero, but the Vd could be a positive or negative value due to the errors of the current sensing or the estimated angle.