Problems with STM32 PMSM FOC SDK

[tatus1969]

My problem is that I have to do "start motor" to be able to generate DAC outputs. But if I start to rotate manually the rotor, the controller (after some time) will start reacting because it should be at zero speed and the feedback tells it that it is running.
Tomorrow I will try to get around to this situation.

You can run the motor in control mode "torque", and set Torque ref (iq) to zero.

Thanks for all the help 

No worries :-)

[Dave_PT]

- is that really Iq? It doesn't look like it should. I would have expected a constant 1A value for that 700ms (or a linear ramp)

Yes. I configured the DAC channel to represent the current Iq ...
For about 5/10us it draws a pulse, but then begins to oscillate.

- the encoder seems to misbehave beginning with horizontal division 9. There seems to be some high frequency 'overlay', if we can assume that the motor is slowly accelerating.

In fact, after 700mS I should not have any more pulses on the encoder ...
At this point I have no explanation for that. Tomorrow I will test more closely to see if I can find an explanation.

It looks to me that the current PI control loop is oscillating. I suggest working on the motor current before looking at encoder feedback. You can use/repeat the alignment procedure to investigate that.

Okay. I'll repeat the procedure and analyze the results.
The control stabilizes initially, but then oscillates so I'll try adjust the PI values.

I was doing the alignment of the encoder.
The encoder pulses result from a "snap" given by the motor.
In this link you can see a small video that shows the moment of alignment.

https://meocloud.pt/link/ad0461a1-e651-44db-90a3-fefeb67b8227/VID_20161123_094942.3gp/

I've already tried adjusting the PI values of the current control, but I can not see any big differences ...



Detail of the oscillation type during encoder alignment.
This oscillation is caused by the DAC (update values?) because I have the same waveform when it represents the angle. Some kind of "noise".

[EDIT]: The frequency is 30KHz ... the same as the PWM.
So if we reject this signal, the current pulse during the alignment lasts only 7uS .

My problem is that I have to do "start motor" to be able to generate DAC outputs. But if I start to rotate manually the rotor, the controller (after some time) will start reacting because it should be at zero speed and the feedback tells it that it is running.
Tomorrow I will try to get around to this situation.

You can run the motor in control mode "torque", and set Torque ref (iq) to zero.

I really have to check what happens to the encoder!
I followed the procedure that you indicated to you and after 4 mec / rev the encoder was advanced about 45º ...

[Dave_PT]

Wait...

I think I got the motor run with the encoder ...
When I remove the cables, it stops and shows overcurrent failure...

Against all that is written, the encoder is configured with 500ppr.

Well ... let's move forward.

How can I start doing the first calibration of PI gains?

[tatus1969]

The frequency is 30KHz ... the same as the PWM.
So if we reject this signal, the current pulse during the alignment lasts only 7uS .

That is the crosstalk that I mentioned earlier, maybe you can also check the encoder signals for "purity". But in your video it seems that the motor has two cables, one for power and one for encoder. These seem to be shielded. Do you have a good connection of both shields to GND?
For the AOUT, I use to add a capacitance in parallel with the probe in such a situation.

I seems like the too short current pulse is a bug in the library, which is not controlling AOUT correctly during the alignment. But the video clearly shows that the alignment works, and it seems to ramp up the current nicely. I have another simple idea how the current loop can easily be verified. You need to tightly fix the motor shaft. Then, in torque mode, start the motor. As soon as you change the Iq value and click on "set references", the current must jump to the new value. You can then tune the gains like I described in an earlier post. Do this at maximum bus voltage, as this voltage is a gain term in the control loop.

I really have to check what happens to the encoder!
I followed the procedure that you indicated to you and after 4 mec / rev the encoder was advanced about 45º ...

Really strange. The encoder part works very well in my designs. But I am using F0 and F4 microcontroller series. For the F3, you found a limitation note in the documentation. I hope that it's not that. Can your scope count pulses? Can you verify that the encoder is configured correctly and produces 512 p/rev as specified? Did you check the cleanness of the input signals? Does adding filter capacitance lower the error? Some questions from my head 

[tatus1969]

Wait...

I think I got the motor run with the encoder ...
When I remove the cables, it stops and shows overcurrent failure...

Against all that is written, the encoder is configured with 500ppr.

Well ... let's move forward.

How can I start doing the first calibration of PI gains?

good success! Overcurrent failure is still an indication that the current loop is not stable. I didn't see this post while writing my previous one when answering the PI gain adjustment procedure

[Dave_PT]

I followed your directions.
I calibrated the PI gains. But I still have little current, and so little torque.

For example:
Motor at 1000RPM with the gear box bolted.
Suddenly I lock the shaft with a brake and the current never rises above 300mA.
So my torque is too low. I can easily block the shaft with my hand  .

[tatus1969]

I followed your directions.
I calibrated the PI gains. But I still have little current, and so little torque.

For example:
Motor at 1000RPM with the gear box bolted.
Suddenly I lock the shaft with a brake and the current never rises above 300mA.
So my torque is too low. I can easily block the shaft with my hand  .

What are your current controller gains? Just asking because if Ki is zero or too low, then the integrator cannot work or is too slow.
Can you make a scope picture showing Iq via DAC at free running, then increasing torque until blocking? How does the waveform look like for a blocked motor and Iq  0 --> max?

[Dave_PT]

What are your current controller gains? Just asking because if Ki is zero or too low, then the integrator cannot work or is too slow.
Can you make a scope picture showing Iq via DAC at free running, then increasing torque until blocking? How does the waveform look like for a blocked motor and Iq  0 --> max?

In this image you can see the controller gains.


Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?


[EDIT]:
In torque control was the motor supposed to rotate?

I blocked the motor shaft, but it does not make any force ...

[Dave_PT]

Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?

The controller is limiting the current to the motor nominal. But it does not match with the values measured by the ammeter ...


Watch this video.
I used a metal piece to lock the motor shaft.

https://meocloud.pt/link/bdcb0756-33a1-4614-ba09-7a00812e2c94/VID_20161123_181502.3gp/

[tatus1969]

What are your current controller gains? Just asking because if Ki is zero or too low, then the integrator cannot work or is too slow.
Can you make a scope picture showing Iq via DAC at free running, then increasing torque until blocking? How does the waveform look like for a blocked motor and Iq  0 --> max?

In this image you can see the controller gains.


Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?

Looks good! I think that the rubbish before the slope to 1.68A is again some undefined behavior of the library. You are right, 0A should correspond to 1.65V. But what is important in the picture is that there is only very little overshoot after the transition. This shows that you have found good controller gains. We can assume that this part is working now.

[EDIT]:
In torque control was the motor supposed to rotate?

I blocked the motor shaft, but it does not make any force ...

Of course the motor should run. It is torque that makes it accelerate. If the set point is high enough, then it will always rev up into full speed no-load rpm. That 1.68A should definitely be enough.

If the motor does not run, and the encoder feedback is working now, this is what I can think of:
- Had you executed encoder alignment before the test? This is essential after every power-up.
- the actual current is not what the library thinks it is (some conversion error). Don't think that this is the case, if all the other possibilities are ruled out then lets think how that can be checked.
- something is wrong with the encoder alignment. Try putting a value into the Id (flux) field instead (leave Iq at zero). Does the motor produce torque?

[tatus1969]

Supposedly the current Iq rises to 1.68A ... but in the ammeter it does not exceed the 350mA.
2.45V-1.65V=0.85V , (0.85*3.268)/1.65 = 1.68A
But at the beginning the voltage is ~ 2.03V and should be 1.65V, right?

The controller is limiting the current to the motor nominal. But it does not match with the values measured by the ammeter ...


Watch this video.
I used a metal piece to lock the motor shaft.

https://meocloud.pt/link/bdcb0756-33a1-4614-ba09-7a00812e2c94/VID_20161123_181502.3gp/

It is important to understand that you cannot measure the phase current (Iq is the amplitude of that) at the supply input. I had tried to explain that in an earlier post. You can compare the power stage and motor inductance with a switchmode buck regulator. You can have a very high output current, but if you short the output and force it to be zero volts, then the regulator does not produce any output power: P = V * I = 0V * {a lot of current}). And if it has a good efficiency, then it consequently does not draw any power from its input. An ideal buck converter with an ideal inductor could provide thousands of amperes without drawing a milliamp from its input. It is the same for the motor. When it does not rotate, then it does not produce mechanical output power. Then the supply current is small, even if you have 1.68A flowing through the motor inductance(s).

So the supply current that you observe when blocking the motor is perfectly reasonable. The problem is that the motor current does not seem to contribute to torque.

[Dave_PT]

- Had you executed encoder alignment before the test? This is essential after every power-up.

Yes. I always do the alignment of the encoder.

- something is wrong with the encoder alignment. Try putting a value into the Id (flux) field instead (leave Iq at zero). Does the motor produce torque?

Tomorrow I'm going to do this test again.
I experimented today and had no torque at the motor shaft.

It is important to understand that you cannot measure the phase current (Iq is the amplitude of that) at the supply input. I had tried to explain that in an earlier post. You can compare the power stage and motor inductance with a switchmode buck regulator. You can have a very high output current, but if you short the output and force it to be zero volts, then the regulator does not produce any output power: P = V * I = 0V * {a lot of current}). And if it has a good efficiency, then it consequently does not draw any power from its input. An ideal buck converter with an ideal inductor could provide thousands of amperes without drawing a milliamp from its input. It is the same for the motor. When it does not rotate, then it does not produce mechanical output power. Then the supply current is small, even if you have 1.68A flowing through the motor inductance(s).

Excellent explanation!
Very good!

So the supply current that you observe when blocking the motor is perfectly reasonable. The problem is that the motor current does not seem to contribute to torque.

In torque mode the motor does not rotate, but in speed mode the motor shaft exerts some force...
Compared to the torque I got on the Renesas board with the same current, it remains low.

[tatus1969]

In torque mode the motor does not rotate, but in speed mode the motor shaft exerts some force...
Compared to the torque I got on the Renesas board with the same current, it remains low.

For me, all this points to encoder alignment problems. In speed mode, the speed controller generates a command for the torque controller. In torque mode, you do this yourself. Why should that make a difference to the generated torque... I guess that the encoder alignment is wrong, and randomly you get little torque, or none. As if it is 90 degrees out of phase.

p.s. I'm sure that you are very close to reaching the goal

p.p.s. if you manage today to bring full torque to the shaft, and continue working with a lab supply, I strongly suggest that you add overvoltage protection to the DC bus, like a beefy 28V zener diode. Otherwise, you'll likely blow the circuit, and possibly your lab supply, when first attempting a deceleration from full rpm to zero with full torque. The regenerated electrical energy will pump up your DC bus capacitors.

p.p.p.s: another question. How do you plan to control the motor in your system? Do you want to keep the entire ST software as it is and send commands via RS232 like STMCWB is doing, or do you plan to implement your own control software? If the second, then I can compile you an extract of how I do it, and the library primitives and structures you need for that.

[Dave_PT]

For me, all this points to encoder alignment problems. In speed mode, the speed controller generates a command for the torque controller. In torque mode, you do this yourself. Why should that make a difference to the generated torque... I guess that the encoder alignment is wrong, and randomly you get little torque, or none. As if it is 90 degrees out of phase.

You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...

p.s. I'm sure that you are very close to reaching the goal

Thanks for your help !!

p.p.s. if you manage today to bring full torque to the shaft, and continue working with a lab supply, I strongly suggest that you add overvoltage protection to the DC bus, like a beefy 28V zener diode. Otherwise, you'll likely blow the circuit, and possibly your lab supply, when first attempting a deceleration from full rpm to zero with full torque. The regenerated electrical energy will pump up your DC bus capacitors.

The EVB I am using now does not support more than 2.8A. But in the future, when I move to a circuit that has more power, I'll take that into account. Thank you.

p.p.p.s: another question. How do you plan to control the motor in your system? Do you want to keep the entire ST software as it is and send commands via RS232 like STMCWB is doing, or do you plan to implement your own control software? If the second, then I can compile you an extract of how I do it, and the library primitives and structures you need for that.

In a future design I want to create my communication protocol and leave the original as well.
I am going to use a selection jumper. If the jumper is on, then the firmware will use all the ST functions to communicate with the STMCWB. If the jumper is off, the firmware will use my protocol, with simpler frames: set speed, set direction, currents, checksum and little else.
If you could show me how you did it would be great!

You deserve 2 of the best Portuguese beers!   

[Dave_PT]

You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...

Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on. 

[tatus1969]

You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...

Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on. 

what do you mean by that?

[Dave_PT]

You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...

Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on. 

what do you mean by that?

I was trying to use 0.5A (Iq = 5013).
Now I changed the value to 1A (Iq = 10026) and the motor runs ease ..

New question:
All the settings I made are 4000RPM max.
But the STMCWB does not let rise above 2500RPM. Will there any parameters that I am not changing?

[tatus1969]

You're right, it should not make any difference.
But in torque mode I can align the encoder and the motor rotor rotates just like in the video I showed you.

[EDIT]
If I rotate the shaft with my hand, it starts to rotate ...

Solved.
I recalculated the current and put the Iq Ref higher.
The motor is now starting with the gear box on. 

what do you mean by that?

I was trying to use 0.5A (Iq = 5013).
Now I changed the value to 1A (Iq = 10026) and the motor runs ease ..

New question:
All the settings I made are 4000RPM max.
But the STMCWB does not let rise above 2500RPM. Will there any parameters that I am not changing?

when you stick to torque mode for now, there is no speed limit. have you tried setting Id instead of Iq? if that produces more torque that would be a clear indication of encoder alignment problems. btw: do the alignment procedure at max possible current, this will let the motor lock more accurately.

[Dave_PT]

For the motor to rotate in the same direction, Id = -Iq. It's normal?

Clockwise rotation:
Iq = 10026, Id = 0

Counterclockwise rotation:
Iq = 0, Id = 10026

Clockwise rotation:
Iq = 0, Id = -10026

[tatus1969]

For the motor to rotate in the same direction, Id = -Iq. It's normal?

Clockwise rotation:
Iq = 10026, Id = 0

Counterclockwise rotation:
Iq = 0, Id = 10026

Clockwise rotation:
Iq = 0, Id = -10026

Id would not contribute to torque at all if encoder alignment was good. how much torque do you have in these situations? that is most interesting for me.

[Dave_PT]

I noticed now that when I connect the EVB with Iq=0 and Id=10026 the motor does not rotate. But in some situations I can get Iq=0 and Id=10026 and the motor runs.
Even before I wrote this answer, it was working like that, but then I tried to figure out why, I can not repeat it.
Let's assume it's a small bug ... while I try to find out if there is any pattern (sequence of events).

[tatus1969]

I noticed now that when I connect the EVB with Iq=0 and Id=10026 the motor does not rotate. But in some situations I can get Iq=0 and Id=10026 and the motor runs.
Even before I wrote this answer, it was working like that, but then I tried to figure out why, I can not repeat it.
Let's assume it's a small bug ... while I try to find out if there is any pattern (sequence of events).

That behavior doesn't really make sense to me. I really would like to know which combination produces good torque, and which one produces less or none.

I have assembled something for you based on my working solution, I hope it does not contain too many errors.

It also contains a working encoder alignment procedure, maybe you want to try this out.

Code: [Select]

#include "PWMnCurrFdbkClass.h"
#include "SpeednTorqCtrlClass.h"
#include "SpeednPosFdbkPrivate.h"
#include "MCTuningClass.h"
#include "MCInterfaceClass.h"
#include "MCTasks.h"
#include "Parameters conversion.h"
#include "Timebase.h"
#include "UITask.h"
#include "MCLibraryISRPriorityConf.h"

#define NBR_OF_MOTORS 1
extern FOCVars_t FOCVars[NBR_OF_MOTORS];
extern CSTC oSTC[NBR_OF_MOTORS];
extern CPI oPIDSpeed[NBR_OF_MOTORS],oPIDIq[NBR_OF_MOTORS],oPIDId[NBR_OF_MOTORS];
extern CPWMC oCurrSensor[NBR_OF_MOTORS];
extern CSPD oSpeedSensor[NBR_OF_MOTORS];
extern CSPD oVSS_M1;
extern CUI oDAC;
CMCI oMCI[MC_NUM];
CMCT oMCT[MC_NUM];

#define FIRMWARE_VERS "STM32 FOC SDK\0Ver.4.0.B"
const char s_fwVer[32] = FIRMWARE_VERS;

#define PHASECURRENT_FTOI( current ) ((int16_t)( current * (65536.0f * (float)(AMPLIFICATION_GAIN / MCU_SUPPLY_VOLTAGE) ) ))
#define VELOCITY_FTOI( velocity ) ((int16_t)( velocity / (0.1f * 60.0f) ))

volatile uint32_t time = 0;
bool bReferenced=FALSE;

void wait( float delay )
{
  uint32_t then;
 
  then = time + (uint32_t)(delay * (float)SYS_TICK_FREQUENCY);

  while( (int32_t)(then - time) > 0 );
}

int main(void)
{
  // Enable interrupt preemption via priority
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_3);
 
  // MCInterface and MCTuning boot
  MCboot(oMCI,oMCT);

  // Systick configuration
  SysTick_Config( (SystemCoreClock) / SYS_TICK_FREQUENCY );
  NVIC_SetPriority(SysTick_IRQn, SYSTICK_PRIORITY);
  NVIC_SetPriority(PendSV_IRQn, PENDSV_PRIORITY);
 
  // Initialize DAC output
  UI_SetDAC(oDAC, DAC_CH0, MC_PROTOCOL_REG_I_Q);
 
  // Assign virtual speed sensor (electrical angle = 0)
  SPD_Clear(oSpeedSensor[M1]);
  SPD_Clear(oVSS_M1);
  STC_SetSpeedSensor(oSTC[M1],oVSS_M1);

  // Initialize to zero torque/flux
  FOCVars[M1].Iqdref.qI_Component1 = 0; // torque, Iq
  FOCVars[M1].Iqdref.qI_Component2 = 0; // flux, Id

  // Current sensor calibration
  PWMC_CurrentReadingCalibr(oCurrSensor[M1],CRC_START);
  while( !PWMC_CurrentReadingCalibr(oCurrSensor[M1],CRC_EXEC) );

  // Enable power stage
  PWMC_SwitchOnPWM(oCurrSensor[M1]);

/*
  // current controller tuning
  while(1)
  {
    FOCVars[M1].Iqdref.qI_Component1 = PHASECURRENT_FTOI( 2.0f );
    wait( 0.007f );
    FOCVars[M1].Iqdref.qI_Component1 = 0;
    wait( 0.04f );
  }
*/

  // Apply 2A current for 1sec for alignment
  FOCVars[M1].Iqdref.qI_Component1 = PHASECURRENT_FTOI( 2.0f );
  wait( 1.0f );
  FOCVars[M1].Iqdref.qI_Component1 = 0;

  // Set encoder angle
  SPD_SetMecAngle( oSpeedSensor[M1], (65536/4) / POLE_PAIR_NUM );

  // Switch to encoder feedback
  SPD_Clear(oSpeedSensor[M1]);
  STC_SetSpeedSensor(oSTC[M1],oSpeedSensor[M1]);
  bReferenced = TRUE;

  keep_doing_something();
}

// This function must be called at SYS_TICK_FREQUENCY rate via interrupt - add it to
// function TB_Scheduler() in file Timebase.c.
void Main_Scheduler(void)
{
  int16_t wAux;
  int16_t i16CurrentVelocity;
  int16_t i16CommandedVelocity;
  int16_t i16MotorCurrentLimit;
  int16_t i16MotorCurrent;

  // Update DAC output
  UI_DACExec((CUI)oDAC);

  // Update motor velocity measurement
  SPD_CalcAvrgMecSpeed01Hz(oSpeedSensor[M1],&wAux);
  i16CurrentVelocity = SPD_GetAvrgMecSpeed01Hz(oSpeedSensor[M1]);

  // Prevent motor activation while not referenced
  if( !bReferenced )
  {
    return;
  }
 
  // Set commanded velocity
  i16CommandedVelocity = VELOCITY_FTOI( 1000.0f );

/*
  // velocity controller tuning
  {
    static int k;
    k++;
    if(k%1000 < 500)
    {
      i16CommandedVelocity = PHASECURRENT_FTOI( 3500.0f );
    }
    else
    {
      i16CommandedVelocity = PHASECURRENT_FTOI( 2500.0f );
    }
  }
*/

  // Velocity control with torque limitation,
  // the PI controller uses the speed PI parameters from STMCWB
  i16MotorCurrentLimit = PHASECURRENT_FTOI( 2.0f );
  PI_SetUpperOutputLimit( oPIDSpeed[M1], +i16MotorCurrentLimit );
  PI_SetLowerOutputLimit( oPIDSpeed[M1], -i16MotorCurrentLimit );
  i16MotorCurrent = PI_Controller( oPIDSpeed[M1], (int32_t)(i16CommandedVelocity - i16CurrentVelocity) );
  FOCVars[M1].Iqdref.qI_Component1 = i16MotorCurrent;
}


[tatus1969]

I noticed now that when I connect the EVB with Iq=0 and Id=10026 the motor does not rotate. But in some situations I can get Iq=0 and Id=10026 and the motor runs.
Even before I wrote this answer, it was working like that, but then I tried to figure out why, I can not repeat it.
Let's assume it's a small bug ... while I try to find out if there is any pattern (sequence of events).

The motor should not run at all with Id > 0. Something's wrong with the encoder alignment! How much torque do you have with Iq=10000 Id=0, how much do you have with Iq=0 Id=10000?

[Dave_PT]

The motor should not run at all with Id > 0. Something's wrong with the encoder alignment! How much torque do you have with Iq=10000 Id=0, how much do you have with Iq=0 Id=10000?

For now I can not put Iq=0 and the motor continues to run.
But with this sequence, I can get the motor to rotate ...

[Dave_PT]

That behavior doesn't really make sense to me. I really would like to know which combination produces good torque, and which one produces less or none.

I have assembled something for you based on my working solution, I hope it does not contain too many errors.

It also contains a working encoder alignment procedure, maybe you want to try this out.

Thank you very much. 
Now I will study the serial communication using the SDK ...