Problems with STM32 PMSM FOC SDK

[Dave_PT]

I am inventing using the SDK.

I reduced the PWM frequency from 20KHz to 15KHz.
So, with my power circuit, the maximum modulation raise from 89% to 96%.

In this configuration the maximum rotation reaches 3100RPM.



[EDIT]
With a maximum modulation of 100% (fPWM=12KHz) the motor reaches a maximum rotation of ~3300RPM.
The same difference of -12% from your theoretical calculation for the measured rotation (100% modulation).

So, I think this is the true maximum speed I can achieve with this hardware ....

[tatus1969]

I am inventing using the SDK.

I reduced the PWM frequency from 20KHz to 15KHz.
So, with my power circuit, the maximum modulation raise the  from 89% to 96%.

In this configuration the maximum rotation reaches 3100RPM.

[EDIT]
With a maximum modulation of 100% (fPWM=12KHz) the motor reaches a maximum rotation of ~3300RPM.
The same difference of -12% from your theoretical calculation for the measured rotation (100% modulation).

So, I think this is the true maximum speed I can achieve with this hardware ....

sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot. If you can reduce this, it will also improve efficiency and reduce losses in the driver. During the deadtime, the motor current flows through the lossy MOSFETs body diodes.

[tatus1969]

I've been busy in the weekend ... sorry for the delay.

Excellent video! I understood what they are doing.
But if all the control firmware was designed by me, it would be easier to implement that.
In this case the SDK is very advanced and its algorithm forms a "web" that would be very difficult to modify.
I would have to find another solution (a simple one) ... otherwise I have a lot to "dig" into the firmware!

if you want to do that, you might want to get a copy of the library's source code, you can get this for free from your chip distributor. (ST will want you to sign an NDA.)

But maybe that will not be necessary. I was thinking about how to implement the anti-cogging feedforward. It is possible that it is enough to do this
- get current electrical rotor phase
- look up correction factor from a table (rotor phase is the index to the table, do linear interpolation to reduce table size)
- multiply the torque current setpoint value (Iq) with that factor
- apply range limitation to make sure the motor does not receive too much instantaneous current
- use the corrected value as input to PI controller for torque / current

All that would be done in MCTasks.c, function FOC_CurrController(). You don't need the library source code for that mod.

[Dave_PT]

sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot.

Maybe the dead time is a little big.
I was securing the worst case, but I can reduce it to 650nS.

350nS (rise) + 150nS(fall) + ~25%(deviation) = ~650nS

[Dave_PT]

sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot.

Maybe the dead time is a little big.
I was securing the worst case, but I can reduce it to 650nS.

350nS (rise) + 150nS(fall) + ~25%(deviation) = ~650nS

Stupid me.

350 (worst case) + ~ 25% (deviation) = 450nS is enough!

[Dave_PT]

- get current electrical rotor phase

I just have one DAC output.
I have to find a way to measure Iq and also measure the electric angle.

If I find a minimum operating Iq and get the graph of the electric angle variation?
I'll be able to have the rotation variation for the same torque ....

No ... probably I could not do anything with that information.

[Dave_PT]

Using torque control, I can lower the current Iq to a minimum of 0.35A with rotation rotation.

I can observe the variation of the electric angle ... but it is not enough information to move forward.

[tatus1969]

- get current electrical rotor phase

I just have one DAC output.
I have to find a way to measure Iq and also measure the electric angle.

If I find a minimum operating Iq and get the graph of the electric angle variation?
I'll be able to have the rotation variation for the same torque ....

No ... probably I could not do anything with that information.

You can make the two measurements one after another. Choose a speed that is as slow as possible but does not make rotation completetly chaotic. You can then use the index channel of your encoder to trigger, just make sure that you align the motor only once. If the encoder does not have an I channel, then I suggest stick a small magnet onto the motor shaft gear, and arrange a Hall sensor close to it.

[tatus1969]

Using torque control, I can lower the current Iq to a minimum of 0.35A with rotation rotation.

I can observe the variation of the electric angle ... but it is not enough information to move forward.

The speed variation seems quite sinusodial and hints to a torque variation of similar shape, maybe this is already enough to set up a correction function/table. You would just need to find gain and phase of that by try and error.

[tatus1969]

sounds good! But do your H bridges really need 800ns deadtime? That is quite a lot.

Maybe the dead time is a little big.
I was securing the worst case, but I can reduce it to 650nS.

350nS (rise) + 150nS(fall) + ~25%(deviation) = ~650nS

Stupid me.

350 (worst case) + ~ 25% (deviation) = 450nS is enough!

Even better. You only have to wait for the fall time to complete, until the other transistor can be switched on. So the minimum dead time could be 302ns.

[Dave_PT]

You can make the two measurements one after another. Choose a speed that is as slow as possible but does not make rotation completetly chaotic. You can then use the index channel of your encoder to trigger, just make sure that you align the motor only once. If the encoder does not have an I channel, then I suggest stick a small magnet onto the motor shaft gear, and arrange a Hall sensor close to it.

But this should be done in open loop, right?
I should be able to change the PWM and apply a value without controll loop.

[tatus1969]

You can make the two measurements one after another. Choose a speed that is as slow as possible but does not make rotation completetly chaotic. You can then use the index channel of your encoder to trigger, just make sure that you align the motor only once. If the encoder does not have an I channel, then I suggest stick a small magnet onto the motor shaft gear, and arrange a Hall sensor close to it.

But this should be done in open loop, right?
I should be able to change the PWM and apply a value without controll loop.

agree, that would the necessary. You can do that again in the FOC_CurrController() function. There should be a section like this, I added a line here:

Code: [Select]

  ...
  Vqd.qV_Component1 = 1000; Vqd.qV_Component2 = 0; // <<<<<<<
  Valphabeta = MCM_Rev_Park(Vqd, hElAngledpp);
 
  hCodeError = PWMC_SetPhaseVoltage(oCurrSensor[bMotor], Valphabeta);
  ...


[Dave_PT]

I made the changes ... but I do not have rotation.
I noticed that the FOC_CurrController function has a condition for "OPEN_LOOP".
Can we use this?

Code: [Select]

/**
  * @brief It executes the core of FOC drive that is the controllers for Iqd
  *        currents regulation. Reference frame transformations are carried out
  *        accordingly to the active speed sensor. It must be called periodically
  *        when new motor currents have been converted
  * @param this related object of class CFOC.
  * @retval int16_t It returns MC_NO_FAULTS if the FOC has been ended before
  *         next PWM Update event, MC_FOC_DURATION otherwise
  */
#pragma inline
uint16_t FOC_CurrController(uint8_t bMotor)
{
  Curr_Components Iab, Ialphabeta, Iqd;
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  Curr_Components IqdHF = {0,0};
#endif
  Volt_Components Valphabeta, Vqd;
  int16_t hElAngledpp;
  uint16_t hCodeError;
 
  hElAngledpp = SPD_GetElAngle(STC_GetSpeedSensor(oSTC[bMotor]));
 
  PWMC_GetPhaseCurrents(oCurrSensor[bMotor], &Iab);
 
  Ialphabeta = MCM_Clarke(Iab);
 
  Iqd = MCM_Park(Ialphabeta, hElAngledpp);
 
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  if (oHFI[bMotor])
  {
    IqdHF = Iqd; /* Stores the Iqd not filtered */
    Iqd = HFI_FP_PreProcessing(oHFI[bMotor], Iqd);
  }
#endif
 
//  Vqd.qV_Component1 = PI_Controller(oPIDIq[bMotor],
//            (int32_t)(FOCVars[bMotor].Iqdref.qI_Component1) - Iqd.qI_Component1);
//
//  Vqd.qV_Component2 = PI_Controller(oPIDId[bMotor],
//            (int32_t)(FOCVars[bMotor].Iqdref.qI_Component2) - Iqd.qI_Component2);
 
/****************************************/
  Vqd.qV_Component1 = 1000;
  Vqd.qV_Component2 = 0;
/****************************************/
 
#if defined(FEED_FORWARD_CURRENT_REGULATION) || (defined(DUALDRIVE) && defined(FEED_FORWARD_CURRENT_REGULATION2))
  if (oFF[bMotor])
  {
    Vqd = FF_VqdConditioning(oFF[bMotor],Vqd);
  }
#endif
 
  FOCVars[bMotor].Vqd = Vqd;
 
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  if (oHFI[bMotor])
  {
    Vqd = HFI_FP_VqdConditioning(oHFI[bMotor], Vqd);
  }
#endif
 
#if defined(OPEN_LOOP) || (defined(DUALDRIVE) && defined(OPEN_LOOP2))
  if (oOL[bMotor])
  {
    Vqd = OL_VqdConditioning(oOL[bMotor]);
  }
#endif
 
  Vqd = Circle_Limitation(oCLM[bMotor], Vqd);
 
  Valphabeta = MCM_Rev_Park(Vqd, hElAngledpp);
 
  hCodeError = PWMC_SetPhaseVoltage(oCurrSensor[bMotor], Valphabeta);
 
  FOCVars[bMotor].Iab = Iab;
  FOCVars[bMotor].Ialphabeta = Ialphabeta; 
  FOCVars[bMotor].Iqd = Iqd;   
  FOCVars[bMotor].Valphabeta = Valphabeta;
  FOCVars[bMotor].hElAngle = hElAngledpp;

#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  FOCVars[bMotor].IqdHF = IqdHF;
#endif
 
#if defined(FLUX_WEAKENING) || (defined(DUALDRIVE) && defined(FLUX_WEAKENING2))
  if (oFW[bMotor])
  {
    FW_DataProcess(oFW[bMotor], Vqd);
  }
#endif
 
#if defined(FEED_FORWARD_CURRENT_REGULATION) || (defined(DUALDRIVE) && defined(FEED_FORWARD_CURRENT_REGULATION2))
  if (oFF[bMotor])
  {
    FF_DataProcess(oFF[bMotor]);
  }
#endif
 
#if defined(HFINJECTION) || (defined(DUALDRIVE) && defined(HFINJECTION2))
  if (oHFI[bMotor])
  {
    HFI_FP_DataProcess(oHFI[bMotor], IqdHF);
  }
#endif
 
  return(hCodeError);
}
Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.
The problem is that I do not know nothing in this firmware

Something like this:

Code: [Select]

Vqd.qV_Component1 = FOCVars[bMotor].Iqdref.qI_Component1;

[Dave_PT]

I found the paper of the video.
http://www.roboticsproceedings.org/rss10/p42.pdf

But I can not figure out how to start PWM ...
I continue to explore the firmware code.

[tatus1969]

I made the changes ... but I do not have rotation.
I noticed that the FOC_CurrController function has a condition for "OPEN_LOOP".
Can we use this?

I have checked, yes, but it is doing exactly the same as our code. This is the function's source code:

Code: [Select]

Volt_Components OL_VqdConditioning(COL this)
{
  pVars_t pVars = CLASS_VARS;
  Volt_Components Vqd;
 
  Vqd.qV_Component1 = pVars->hVoltage;
  Vqd.qV_Component2 = 0;
 
 return(Vqd);
}

Our code should also work, but I noticed that it has a problem: it is always active. We don't want it active during encoder alignment. Please try this modification:

Code: [Select]

if( StateM1 == RUN )
{
    Vqd.qV_Component1 = 1000; Vqd.qV_Component2 = 0;
}
Did you check with higher values as 1000? I think 32767 equals 100% voltage.

[tatus1969]

I found the paper of the video.
http://www.roboticsproceedings.org/rss10/p42.pdf

But I can not figure out how to start PWM ...
I continue to explore the firmware code.

Interesting. They propose to compensate for cogging by adding a correction value instead of multiplying in a factor. I was already wondering which one would be the best approach

[tatus1969]

Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.

That is not completely correct. The Iq current is always an input to the current/torque PI controller. Only the output from that is a voltage that is translated into the PWM values. Remember the PWM creates a voltage. Current only starts to flow because there is a load.

I also don't know the open-loop mechanism works that they implemented, and how to use it. Maybe there is an example, but I doubt that you can control it from STMCWB.

[Dave_PT]

Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.

That is not completely correct. The Iq current is always an input to the current/torque PI controller. Only the output from that is a voltage that is translated into the PWM values. Remember the PWM creates a voltage. Current only starts to flow because there is a load.

I also don't know the open-loop mechanism works that they implemented, and how to use it. Maybe there is an example, but I doubt that you can control it from STMCWB.

What I want to say was pick up the Iq value that is sent to the MCU (via STMCWB ) and pass it directly to the PWM.
So it ranged from 0 to 32767 using STMCWB and immediately updated the PWM value.
It would be faster than modifying the value and compile all again...

But I'm talking without the knowledge of the tasks that occur at low level ...

[Dave_PT]

Did you check with higher values as 1000? I think 32767 equals 100% voltage.

I was gradually rise up to 32000.
I have no rotation after doing start motor.
But the motor shaft makes some force ...

Code: [Select]

State_t StateM1;
StateM1 = STM_GetState(oSTM[M1]);
if( StateM1 == RUN )
{
Vqd.qV_Component1 = 3000; Vqd.qV_Component2 = 0;
}

[Dave_PT]

Code: [Select]

/**
  * @brief Check whether Vqd.qV_Component1^2 + Vqd.qV_Component2^2 <= 32767^2
  *        and if not it applies a limitation keeping constant ratio
  *        Vqd.qV_Component1 / Vqd.qV_Component2
  * @param  this related object of class CCLM
  * @param  Vqd Voltage in qd reference frame 
  * @retval Volt_Components Limited Vqd vector
  */
Volt_Components Circle_Limitation(CCLM this, Volt_Components Vqd);

This makes some limitations ...
But in fact the applicable maximum is 32767.

[tatus1969]

Ideally we could use the workbench application to vary the ref current Iq and enter that value into the PWM. Somewhere in this function should appear Iqref, if we pass it to the PWM function should work.

That is not completely correct. The Iq current is always an input to the current/torque PI controller. Only the output from that is a voltage that is translated into the PWM values. Remember the PWM creates a voltage. Current only starts to flow because there is a load.

I also don't know the open-loop mechanism works that they implemented, and how to use it. Maybe there is an example, but I doubt that you can control it from STMCWB.

What I want to say was pick up the Iq value that is sent to the MCU (via STMCWB ) and pass it directly to the PWM.
So it ranged from 0 to 32767 using STMCWB and immediately updated the PWM value.
It would be faster than modifying the value and compile all again...

But I'm talking without the knowledge of the tasks that occur at low level ...

i misunderstood that good idea,sorry

[tatus1969]

Code: [Select]

/**
  * @brief Check whether Vqd.qV_Component1^2 + Vqd.qV_Component2^2 <= 32767^2
  *        and if not it applies a limitation keeping constant ratio
  *        Vqd.qV_Component1 / Vqd.qV_Component2
  * @param  this related object of class CCLM
  * @param  Vqd Voltage in qd reference frame 
  * @retval Volt_Components Limited Vqd vector
  */
Volt_Components Circle_Limitation(CCLM this, Volt_Components Vqd);

This makes some limitations ...
But in fact the applicable maximum is 32767.

This function limits the voltage vector amplitude such that the max PWM duty cycle is not exceeded, no worries about that.

[tatus1969]

Did you check with higher values as 1000? I think 32767 equals 100% voltage.

I was gradually rise up to 32000.
I have no rotation after doing start motor.
But the motor shaft makes some force ...

Code: [Select]

State_t StateM1;
StateM1 = STM_GetState(oSTM[M1]);
if( StateM1 == RUN )
{
Vqd.qV_Component1 = 3000; Vqd.qV_Component2 = 0;
}

can you try increasing Vqd.Component2 instead, and leaving Vqd.Component1=0 ? If the motor then turns, then there is probably something very wrong with the encoder alignment.

[Dave_PT]

can you try increasing Vqd.Component2 instead, and leaving Vqd.Component1=0 ? If the motor then turns, then there is probably something very wrong with the encoder alignment.

Yes, the motor is already running.

What can this mean?

[tatus1969]

can you try increasing Vqd.Component2 instead, and leaving Vqd.Component1=0 ? If the motor then turns, then there is probably something very wrong with the encoder alignment.

Yes, the motor is already running.

What can this mean?

I think that the encoder alignment does not work as expected. There seems to be an (electrical) phase shift of around 90 degrees between what it does and what it should do.

If it would be working correctly, then the FOC algorithm would make sure that the magnetic field created by the stator windings is (electrically, magnetically) always exactly 90 degrees away from the magnetic field vector of the rotor's permanent magnets. This makes sure that the attraction/rejection forces within the motor are radial, which maximizes motor torque.

In your case, there seems to be a 90° error in phase. If that is the case, then the forces are axial instead, and the stator poles just axially "pull out" the permanent magnets, resulting in no movement.

I just validated the sensorless algorithm a few weeks ago because I wasn't sure how well that is working. You can do the same with the encoder algorihm, allowing you to debug it:

- place small permanent magnet onto motor shaft/gear
- place Hall sensor in some orientation, such that it triggers once per mechanical rev, connect to scope channel, use it as trigger
- connect oscilloscope between two motor phases
- turn motor by hand and determine voltage zero crossing on scope --> this is your zero phase reference; you can now move the hall sensor such that its trigger point is right at the zero crossing; alternatively you can determine the phase between the two
- now attach the driver, setup a certain motor speed, and load the motor
- measure Ia value via DAC via scope and determine phase between hall sensor triggering (zero crossing) and current

At this point you are able to measure the phase between motor current and the motor's rotor orientation. I am a bit lost here to suggest the correct phase (I did it differently by measuring real phase current with a probe instead), but there is an easy way for you to determine that: make the measurement once with sensorless feedback, I am confident that you can trust it. Then you know the phase that you should see when switching to encoder feedback.