instaSPIN FOC delay

Hi Sebastien,

I am moving your post to the InstaSPIN forum, where they will be able to answer your question.

I see a lot of strange things in this user.h

First can I ask that you have checked your compiler so that you are using effective version 6.2.3+?

Which version of MotorWare are you using?

Which project are you basing your code on?

Have you triple checked your hardware, especially current and voltage scaling as well as voltage filter pole?

Hi Chris,

TI compiler version : V6.2.6

Motorware version : 01_01_00_13

The project is based on the Lab_7 of Motorware 01_01_00_13.

I think the hardware is correct :

I used 1% resistors.

PVDD = 24V

The phase voltage feedback is designed to have 3.3V on the ADC when the phase voltage is equal to 31.2V (24V + headroom of 30%). The filter pole value is 379.62Hz. The motor frequency is (3000*10)/120 = 250Hz.

The current feedback is designed with hall effect linear current sensor. One hall effect sensor for each motor phase (I could use 2 sensors instead of three, and I'll probably do it later). The hall effect sensor I'm using has a range of -25A to +25A.

There was a mistake about the delay I gave you, it was 124ms instead of 560ms.

Please find below a graph, giving the time to reach 100rpm from 0rpm for 30 spinning command.

Best Regards,

I'm traveling so can't be as thorough as I like. 

In your user.h, your filters pike is different than what you state in this post. Also noted that you set the cpu frequency to 80 MHZ instead of 90. 

For the active motor your ID'd Rs / Ls is quite small. I think your Ls is misidentified. 

Your IQ_FREQ is pretty low, and it is lower than the ROVERL Frequency (change this from 300 to 100) hence the user error that is being displayed on the image you posted. 

Filter poles value is correct now.

I did a new motor ID and Ls is correct now.

ROVERL Frequency aqual to 100 instead of 300.

But unfortunately, the delay still appears.

Please upload your user.h again

0211.user.h

Please find the user.h attached.

In my project, the 2 BLDC motors are independant and have to move as synchroniously as possible.

I didn't notice this delay in the past. To focus on this delay, now, I'm measuring the time to reach the speed of 100 rpm from 0 rpm. Below, you will find a graph with the log of 30 spinning command and it seems that Motorware 01_01_00_09 is faster and may be more stable than Motorware 01_01_00_13.

Hello,

Do you have any feedbeck or test I could do ?

Best Regards,

Just for information,

I have just finished to do the same test but in torque mode (without the speed controller from TI).

The result is the same, I still notice times to times a delay before the motor spins.

Regards,

I've been traveling and my laptop died, sorry for delay. 

Are you loading your offsets from user.h the first time?

In your test are you just toggling the RunIdentify flag between tests with a large IqRef already set?

Your results are not consistent with what we've seen at all.

The first time, I followed the Lab 3a to read the offsets of my board and then put the values in user.h.

Now, when SysEnable and RunIdentify are true, the offsets values are correctly set according to user.h.

I tried to set Flag_enableOffsetcalc and Flag_enableRsRecalc true but same result about the delay.

No, RunIdentify was true and I just put IqRef = 3.0A or IqRef = 0.0A

I've just made a test with IqRef set to 3.0A and toggling RunIdentify and there is a big difference !!!

I modified my application to work with RunIdentify instead of IqRef or SpeedRef and I haven't noticed a delay yet.

The behavior is similar to the blue curve of my previous picture.

But when I modify the output of the speed regulator in order to dynamically change the current limitation, times to times the delay appears. I modify the output of the speed regulator with the function "CTRL_setMaximumSpeed_pu".

You can see the current limitation profile I'm using in the picture below (orange signal)

When I remove the limitation to 2 Amps, the system is stable again

Is anything wrong with this function or is there a specific way to use it?

Regards,

first, just some comments on user.h

you don't need to set this value at a strange decimal (it looks like your actual Rs / Ls), I suggest using just (500.0), that doesn't hurt anything.

#define USER_IQ_FULL_SCALE_FREQ_Hz        (270.83)

Is there a reason you are running the clock only at 80? At least for now can you please change to 90.0

#define USER_SYSTEM_FREQ_MHz             (80.0)

You need to keep this value at (1.0) unless you are using the svgen_current module introduced in proj_lab10

#define USER_MAX_VS_MAG_PU        (1.1547)

Please add a factor of 2 to this value to insure the forced frequency is 2x the frequency where ForceAngle is active.

#define USER_FORCE_ANGLE_FREQ_Hz   (2.0 * USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz)

also, since you have 30 KHz PWM and are using /3 for current and estimator change these to (10) to get 1 KHz effective

#define USER_NUM_CTRL_TICKS_PER_SPEED_TICK  (10)

#define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK   (10)

Sebastien Dassy said:

I modified my application to work with RunIdentify instead of IqRef or SpeedRef and I haven't noticed a delay yet.

Do you mean that you hard coded your variables for Iq_Ref_A and/or SpeedRef_krpm so they were already set on RunIdentify and ready to go?  As you'll notice in the labs, the user adjustments to things like Iq_Ref or SpeedRef are handled in a background task w/o interrupt priority, so there certainly could be some delay until the commands are issued. Setting the value to the global gMotorVars.IqRef_A is not setting it into the controller.

Also, you mentioned you were using proj_lab07 as the basis. Remember if you disable the speed controller and want to provide Iq_Ref_A, you need to still provide a speed reference with the proper +/- sign.

for example, in 5a there is a function just to use the global value to set the actual reference into the controler

void updateIqRef(CTRL_Handle handle)
{
  _iq iq_ref = _IQmpy(gMotorVars.IqRef_A,_IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A));

  // set the speed reference so that the forced angle rotates in the correct direction for startup
  if(_IQabs(gMotorVars.Speed_krpm) < _IQ(0.01))
    {
      if(iq_ref < _IQ(0.0))
        {
          CTRL_setSpd_ref_krpm(handle,_IQ(-0.01));
        }
      else if(iq_ref > _IQ(0.0))
        {
          CTRL_setSpd_ref_krpm(handle,_IQ(0.01));
        }
    }

  // Set the Iq reference that use to come out of the PI speed control
  CTRL_setIq_ref_pu(handle, iq_ref);

  return;
} // end of updateIqRef() function

the SpeedRef can be set directly into the controller

            // set the speed reference
            CTRL_setSpd_ref_krpm(ctrlHandle,gMotorVars.SpeedRef_krpm);

To change the limits of the output of the speed PI controller I would use

PID_setMinMax(obj->pidHandle_spd,outMin,outMax);

as are done in ctrl.c

these values are in per unit, so setting outMax as _IQ(1.0) would allow for an Iq_Ref_A of up to USER_IQ_FULL_SCALE_CURRENT_A value

I followed all your proposals but no changes about the delay.

I noticed :

1) when I set  #define USER_MAX_VS_MAG_PU  to (1.0) instead of (1.1547), the maximum speed of the motor is 2600rpm instead of 3000rpm due to the 86.6% duty cycle in that case, I guess.

2) When I'm using 

PID_setMinMax(obj->pidHandle_spd, -_IQ(gUserParams.maxCurrent/gUserParams.iqFullScaleCurrent_A), _IQ(gUserParams.maxCurrent/gUserParams.iqFullScaleCurrent_A));

instead of

CTRL_setMaximumSpeed_pu(ctrlHandle, _IQ(gUserParams.maxCurrent/gUserParams.iqFullScaleCurrent_A));

the current limitation doesn't change anymore.

Not really, in fact in my old software, I started the systems with EnableSys and RunIdentification and after that I used SpeedRef_krpm to give the desired speed. When the speed had to be equal to zero, I put a false value in the function "CTRL_setFlag_enableSpeedCtrl" and forced the IqRef to zero.

Yesterday, I modified my software to start the system with EnableSys, prepare the desire speed in SpeedRef_krpm and give the spinning command by settingRunIdentification true. When the speed had to be equal to zero, I keep RunIdentification false.

Thanks for the reminder about the speed reference with the proper +/- sign in torque mode. When I wanted to do this test, I went to the labs to check how to do it and I used the function "updateIqRef(ctrlHandle);" to set the proper sign. Into this function, I found the code you mentionned previously.

Sebastien Dassy said:

1) when I set  #define USER_MAX_VS_MAG_PU  to (1.0) instead of (1.1547), the maximum speed of the motor is 2600rpm instead of 3000rpm due to the 86.6% duty cycle in that case, I guess

Let me repeat, if you change the value in user.h > 1.0 you MUST use the technique and svgen_current module from proj_lab10 for this to work properly.  Do NOT just change this value in user.h and use the other labs that only have svgen module.

It's a bit hard to understand exactly what modifications you have made and what results you are now getting.

Looking at the state machine, there is some code that has to run, but it just runs the first time that the state has changed....it could effect start-up timing but I would expect it to be consistent. You could pull this out into your initizialization logic.

            if(flag_ctrlStateChanged)
              {

as for something that runs in the background loop, you want the

HAL_enablePwm(halHandle);

to be called as soon as possible, that way as the mainISR runs the output of the FOC control will actually go to the PWMs....that's the only thing I can think of that would cause these initial delays.