Some functions explained

Mojo,

1. TRAJ modules act as an input ramp controller. You will notice that there is a TRAJ handle for _Id, _spd, and _spdMax

Why isn't there one for _Iq?  Because in speed loop mode the output of the PID_spd controller acts as the ramp controller input for Iq.  If you run in Torque mode and are providing an Iq reference this is actually something you may want to add so that you are not inputting step commands to your system.  The Trajectory generation allows you to change how the input is presented to the control module.

For your specific question, during "normal" operation when the Id_Ref is set to "0", this refValue = 0 + 0.

However, there are times when it will not.

1. During Motor ID an Id reference is injected, and we use this to control the rate of change.
2. During field weakening the Id reference will be set to a non-zero
3. For start-up initiall rotor alignment and the RsRecal the Id reference will be set to non-zero
4. For ACI motors the Id is non-zero, so the Idref_pu will be non-zero
5. The ACI PowerWarp (flagEnable_epl) feature uses this to dynamically change the Id reference, so the both the ref and Int of TRAJ will change

2. in ctrl.h see  if(EST_doSpeedCtrl(obj->estHandle)); you'll notice the TRAJ module for _spd is being used here:
_iq refValue = TRAJ_getIntValue(obj->trajHandle_spd);

3. angleDelayComp compensates for the movement of the rotor from the time you sample the signals to the time you update the inverter with a correction voltage. At low speeds the rotor delta will be very, very, very small so it really isn't necessary. At high RPMs the rotor may move significantly before you apply your stator flux, so you could be loosing significant torque as that angle moves away from the ideal 90 degrees.  The sign needs to be accounted for because the Frequency (used to calculate the Delta) can be negative.

4 & 5. Interesting, let me log this for further investigation on our side

Hi Chris,

Thanks for thorough explanation.

About (3) - In order to compensate for the time you are talking about, I think that the software needs to know the execution time of the ISR (well, not all of it, ,but up to the point of updating the PWMs). However, I didn't that you are using such information. Further more, this time interval can vary from different users, dependent on what they run in the ISR. So I think there should be some parameter to specify this time ?

about (4),(5) - indeed interesting. waiting for your reply.

Another interesting issue I encountered, maybe can could explain it, is the following:

First scenario : I'm setting the PWM at 60kHz. ISR is /3 so it executes at 20kHz.

Second scenario: setting PWM at 20kHz, ISR is /1 so it runs again at 20kHz.

The behavior of the motor is much different in high speed. In the first scenario the motor starts making strange noises at about 400Hz electrical, in the second scenario the motor starts making strange noises at about 600Hz electrical.

I thought maybe the deadband effects the behavior. In the MCU there's actually no DB configured (1 sysclk..). Then I went to the HW schematics, and saw that the resistor that sets the DB in DRV8301 is 1ohm, which translates to 50ns. This is very very low DB, and should not effect the PWM frequency I use (20,60 kHz).

Can you think of a reason for different behavior, even though the control runs at the same frequency ?

Mojo,

About (3) - that timing is taken into account. Did you look at ctrl.h function

inline _iq CTRL_angleDelayComp(CTRL_Handle handle, const _iq angle_pu)

The TICK rates are used

  _iq angleDelta_pu = _IQmpy(EST_getFm_pu(obj->estHandle),_IQ(USER_IQ_FULL_SCALE_FREQ_Hz/(USER_PWM_FREQ_kHz*1000.0)));

  _iq angleUncomp_pu = angle_pu;
  _iq angleCompFactor = _IQ(1.0 + (float_t)USER_NUM_PWM_TICKS_PER_ISR_TICK * (float_t)USER_NUM_ISR_TICKS_PER_CTRL_TICK * ((float_t)USER_NUM_CTRL_TICKS_PER_EST_TICK - 0.5));

Your other topic:

I have a few thoughts. First I'd like to ask what sort of controller tuning have you done?  Have you tuned the speed controller for both scenarios?  At lease a manual tuning by commanding zero speed and finding a good stiffness and return?

I would suggest first to run proj_lab5a which is torque control only (no speed controller in the system).  Take the default Kp value of IdIq, multiply by 4, and set this back to the control system.  The x4 is the calculated bandwidth of the system and is needed for highest dynamics and typically highest speeds (though 400-600 Hz is not "high").

See if there is a difference in behavior between the 60 kHz and 20 kHz PWM now.

Hi Chris,

I ran lab 5a and 5b and calibrated the controllers.

They now act the same in my "high speed" range.

However, I have an interesting phenomena - When I use PWM=60k, between 7000-9000 RPM (mechanical) I get oscillations, which disappear after 9000. When using PWM=20k this does not happen.

I use the same values for kp,ki for current and speed controllers in both cases. I tought that since I don't change the ISR frequency (when PWM=60 I use a /3 division, while in PWM=20k I use /1 division) the values should remain the same.

The values I use are:

Kp_Idq = 1.2,Ki_Idq=0.03

Kp_spd = 25 , Ki_spd=0.15

I still have strange noises around 700Hz...

The oscillation effect is NOT present in lab 5a, in both cases. When I reach the problematic RPM, around 8000, I reduce Iq_ref so the motor will stay at that frequency. No oscillations.

How do you suggest of looking at a step reference (we had a thread about debugging control loops...) ? Actually today I'm trying to capture data with the graphing tool of the CCS (dual graphs), using a vector of 100. I have 2 vectors for Id,Iq and 2 vectors for Vd,Vq. So I get some readings. I see that in the d-axis I get spikes when the noise is present, but not sure if the graphing tool is reliable...

By the way, do you know how can I change the allowable sampling rate of the graphing in CCS ? I remember there was some configuration to that..

About the noises, this is quite strange because I can reach much higher frequency, even tough the noise is present. As the speed gets higher, the noise does not become stronger, but rather stays the same. I was able to reach 1kHz electrical and I think I have more room until reaching modulation index of 1.333.

The noises are present also in lab 5a, but maybe at higher frequency than in 5b. A problem is that I don't have a current probe... I tried connecting my voltage probe to TP25 and TP17 but did not see anything (I think the current is very low since the motor is in no-load).

Another issue to think about - Even though I use a surface mount PM, I looked at the rotor and I saw that the PMs are a little bit buried. This I think causes a Lq>Ld case. Maybe this has an effect - causing a reluctance torque if Id is not completely zero ?

Hi Chris,

Please see attached the print-screen. It shows a ramp from 10kRPM to 20kRPM. see what happens to the currents and voltage at 20k.

Mojo,

Would you like to test an alpha release of a lab that shows you how to use graphing inside CCS to tune the current and speed controllers?  Right now it's only been tested on the DRV8312 kit, but I would think it should prot over to DRV8301 just by updating the paths in the project file. (we work off of 1 board until it's closed and then we do the port to others).

Message me your email address and I'll get it to you...it's a <1MB zip that installs over MotorWare _11.

"Another issue to think about - Even though I use a surface mount PM, I looked at the rotor and I saw that the PMs are a little bit buried. This I think causes a Lq>Ld case. Maybe this has an effect - causing a reluctance torque if Id is not completely zero ?"

This could be the case though I'd be a bit surprised if you were seeing this effect unloaded.  Cross coupling the current controllers has been very effectivein these cases.  We have simulated and implemented this (first for salient motors but we also see benefit for none) with success. We will add it to MotorWare eventually. It isn't so hard to do yourself if you are capable...someone on these forums has. Let me see if I can find that post.

Another thing, my first instinct on your issue is noise in your current samples at higher duty cycles.  We have seen this quite often with the DRV8301 layout.  We should have placed the amplifiers closer to the ADC inputs instead of closer to the inverter.

here is a post from Dave Wilson about what we are looking at for decoupling:

http://e2e.ti.com/support/microcontrollers/c2000/f/902/p/311698/1091155.aspx#1091155

this is also where I believe  Eli_jia  stated he has implemented.

Hi Chris,

I was also thinking about sampling issues - noise, but also offset...I was thinking maybe to run the ISR at the PWM rate, and do averaging on the samples. then run the control and est every xx cycles... I'll see if that helps.

Mojo,

Coming back to this

"4. I tried running the control with floating point enabled. I started form lab 2d, and actually observed different behavior than in lab 2c. In the transition between rated-flux state and Ls, there were some speed oscillations, which did not exist in lab 2c..."

our response is:

Lab 2d does not work with low inductance motors. Only 2c does which doesn't have fpu32 enabled

Lab 2c will give different results than 2a/b/d