PMSM motor control with FOC using STM32F407

[Mrt12]

Hi guys,
I want to control a PMSM motor iwth the FOC using an STM32F407. Just to test whether I can implementi it by myself, I don't want to use a library for that but I want to code it myself :-)

So far I have implemented the center aligned PWM signal generation and the encoder interface is also working. Using a three phase H bridge I still had on my bench is used as power stage, and with that, I can now rotate a motor using external commutation together with SVPWM. So far this was fairly easy. However for the next steps I have a few questions...

1) for the measurement of the phase current, I have added 2 shunt resistors and OpAmps to my H-bridge. To measure phase current, the ADC needs to be triggered in the phase where all 3 PWM signals are HIGH. How would you do that on STM32F4? I know there is a possibility to trigger the ADC on a PWM signal, but there are multiple possibilities to do it. Currently, I use TIM1 to generate the PWM signals on CH1, CH2 and CH3. I could either use CH4 as an internal signal to trigger the ADC or perhaps it is also possible to trigger the ADC when the timer overflows.

2) the motor which I want to use has both, an incremental encoder (1024 steps per turn) and hall sensors. On startup of the motor controller, I cannot know the rotor angle exactly, I can only read the hall sensors which gives a rough estimate of the rotor angle +/-30°. So at some point, I need to align the encoder to the hall sensors. How would I do that?

[Sal Ammoniac]

1) You want to use the timer overflow (when the center-aligned PWM counter reaches its maximum and starts to count down) to trigger the ADC conversion. The reference manual should have the details of how to set this up.

2) Here's what I would do: drive one of the motor phases momentarily to align the magnets and use that as your "zero" by clearing the encoder count you maintain in software. You don't need to know the absolute position of the rotor.

[lucazader]

You can also do the alignment by haveing the tree 120 degree of set phase voltages and then slowly ramping up the current into those phases which will pull the magnets into line.
The slow ramp up helps reduce oscillations around the "center" point as the magnets move into place.

[bhave]

2) the motor which I want to use has both, an incremental encoder (1024 steps per turn) and hall sensors. On startup of the motor controller, I cannot know the rotor angle exactly, I can only read the hall sensors which gives a rough estimate of the rotor angle +/-30°. So at some point, I need to align the encoder to the hall sensors. How would I do that?

There are many different ways to align the motor on start-up.  The easiest way is to ramp up a current on the D-axis and force the Q-axis to zero.  If you know where the index pulse is on your encoder, you can line that up at this time.  Otherwise, you can integrate your calculated speed to create the rotor angle internally and not worry about lining the encoder up.  Once all that is done, every time you start the motor you do the same thing with the D-axis and Q-axis.  Then, set your rotor angle to zero, drop the D-axis command to zero, and give the Q-axis some command.  The Q-axis command generally comes from some sort of speed PI regulator.

[Harjit]

There are many different ways to align the motor on start-up.  The easiest way is to ramp up a current on the D-axis and force the Q-axis to zero.  If you know where the index pulse is on your encoder, you can line that up at this time.  Otherwise, you can integrate your calculated speed to create the rotor angle internally and not worry about lining the encoder up.  Once all that is done, every time you start the motor you do the same thing with the D-axis and Q-axis.  Then, set your rotor angle to zero, drop the D-axis command to zero, and give the Q-axis some command.  The Q-axis command generally comes from some sort of speed PI regulator.

So, before the inverse Park transform, ramp up the D-axis current and then the inverse Park transform and inverse Clark transform will do their thing? Oh, this will cause the rotor to gently rotate and the encoder will pick that up and then start commutating from there?

Can't the rotor start off going the opposite direction?

The approach I was considering was use a magnetic encoder on the motor shaft. Read that. Compute 90 deg. ahead and directly generate the three phases. At startup, I was going to set the max. current to some empirically determined value and once some speed was achieved, turn on the current loop. Would this work?

[bhave]

The control works like this:

1.  Read your currents
2.  Do a clarke transform on them
3.  Do a park transform on the output of the clarke transform using your rotor angle
4.  Create the D and Q axis current commands
5.  The output of the park transform and your D and Q axis current commands create the error inputs to current PI regulators
6.  Do an inverse park transform on the output of the current PI regulators using your rotor angle
 
You can make the motor spin in a certain direction by forcing rotation in the rotor angle even if you do not know the correct angle to start.  This requires the current loops to be active and some predetermined current command to be used in either the D or Q PI.  Once the motor is spinning a certain speed, you use the measured rotor angle and close the loop around the current command.  Generally, this is some sort of speed PI loop or torque command.  The output of this loop becomes the Q current command.  The D current command is then forced to zero, unless you are field weakening.

There are lots of little details required, but that is the general idea.

[Mrt12]

 :bullshit:Hey guys,
thanks so far for your hints. I see that it should be possible to "guess" the rotor angle from the current hall sensor states.
In one application note from Microchip I read that the alignment may be done as follows:

Excite the d-axis with some current and wait until the rotor settles. Then, the rotor angle can be determined.

However, how can I do this alignment if I don't want my rotor to spin? e.g. when you are building a segway it can be dangerous if the rotor first needs to move to align the encoder to the hall sensors. There must be a more sophisticated algorithm, because many commercial PMSM controllers don't need to rotate the motor for the initial alignment. How do they do it?

[bhave]

However, how can I do this alignment if I don't want my rotor to spin? e.g. when you are building a segway it can be dangerous if the rotor first needs to move to align the encoder to the hall sensors. There must be a more sophisticated algorithm, because many commercial PMSM controllers don't need to rotate the motor for the initial alignment. How do they do it?

You can either use an absolute encoder or something like high frequency injection to determine the rotor position on startup.  This is an area of extremely active research.

[lucazader]

If you have an encoder like a TLE5102b, ma302 or as5047x then usually these will give you an absolute position even after power loss.
You would then just have to calibrate this angle against the magnetic position once, and save this into some form of non volatile storage.
You also gain super accurate mechanical feedback of the rotor angle which will help if you need to do slower speed movements or positions controlled movements.

[Mrt12]

haha, sorry for that "bullshit" in my last post, I didn't intend that :-) I was typiing on the smartphone and apparently hit some wrong button without realising it.

@lucazader,
unfortunately I have no such encoder. I have only a very simple one which gives me A and B signals, I don't even have an index pulse. :-(

[bhave]

unfortunately I have no such encoder. I have only a very simple one which gives me A and B signals, I don't even have an index pulse. :-(

Your simple encoder is fine to get your code and hardware tested.  Once you are controlling the motor the way you like, then you can start to optimize certain aspects of it such as rotor alignment.  You will need very accurate position feedback if your goal is to provide really tight zero or low speed performance.

[lucazader]

Your simple encoder is fine to get your code and hardware tested.  Once you are controlling the motor the way you like, then you can start to optimize certain aspects of it such as rotor alignment.  You will need very accurate position feedback if your goal is to provide really tight zero or low speed performance.

Agreed. These magnetic style encoders are quite affordable and also very reliable for production environments.
A cheap one you could look into is the a1333 or a1338, they can be had for around $1.60-$1.80 in volume.

[Sal Ammoniac]

unfortunately I have no such encoder. I have only a very simple one which gives me A and B signals, I don't even have an index pulse. :-(

Unless your application is a servo motor or a steering controller, your 1024 count encoder is more than good enough. Commercial FOC controllers typically work with AC motors with 32 or 64 count encoders, which have more than an order of magnitude less position resolution than your encoder.

Ditto for an index pulse--absolute position is really needed only for a servo or steering controller, and those controllers typically "fake it" by slowly rotating the motor at start-up until an index pulse is encountered to establish the zero point.

What exactly is your application? That may determine how you align the motor poles. For the tiny motors I work with, just turning on a single phase at startup won't be very dramatic, but if you have a big, massive motor, you probably want to gradually build up the current in a phase using PWM rather than just turning it on all at once.

[bhave]

Unless your application is a servo motor or a steering controller, your 1024 count encoder is more than good enough. Commercial FOC controllers typically work with AC motors with 32 or 64 count encoders, which have more than an order of magnitude less position resolution than your encoder.

Ditto for an index pulse--absolute position is really needed only for a servo or steering controller, and those controllers typically "fake it" by slowly rotating the motor at start-up until an index pulse is encountered to establish the zero point.

I am just curious, what kind of commercial FOC drive for an AC induction motor uses a 32 PPR encoder (I need to figure out what they are doing!)?  I develop drives for very large induction motors and have never been able to get decent low speed torque regulation using 32 PPR without playing games with flux observers and sensorless control.  It works fine for things like fans and pumps.  Anything that starts under load while crossing zero or at zero speed, seems to require more resolution.  We have standardized on 1024 PPR for most stuff.

His encoder resolution is fine, but if he wants to align the rotor without any rotation, he needs to dip into some more complex controls or use an encoder that gives him an accurate rotor angle on power up.