Problems with STM32 PMSM FOC SDK

[tatus1969]

Should I worry about this?

Page 8, 3.2.1 - http://www.st.com/content/ccc/resource/technical/document/release_note/b1/3f/4e/1b/cc/7f/45/c1/DM00068242.pdf/files/DM00068242.pdf/jcr:content/translations/en.DM00068242.pdf

Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not 

[Dave_PT]

- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?

Yes it has an incremental output (I channel).
The encoder is this (PDF downloads automatically): https://ams.com/kor/content/download/725051/1853902/file/AS5047P_DS000324_2-00.pdf
It also gives absolute rotor angle.

- do you need to be able to rev up the motor under load?
- after rev up, do you need to be able to provide torque at standstill?

The motor will always be in effort. This may have several applications, but the most immediate will be a larger-sized robot.
I need the engine to start rotating with the engine weight to overcome the inertia moment.

The FOC algorithm interpolates the Hall sensors while the motor is turning, so there will be no degradation. But you have a 10-20% torque loss at very slow velocity (probably far slower than the numbers that you mentioned) and standstill. If that is not a problem in your application, then you'd be fine. And your possible encoder software/microcontroller limitation from your last post would become unimportant (I vaguely remember that I needed to sacrifice a GPIO for that, can check this evening).

Very low speed maybe is very slow even for me  .
A minimum speed of 100RPM in the motor goes through the gearbox, and I get output rotation of approx 1.5RPM.


PS: I just tested with sensorless on primary control and with encoder on auxiliary control, but the motor does not rotate properly. The motor runs for a while (1/2sec) and then stops and it is consuming current.

[Dave_PT]

Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not 

I do not see anything in scope.
I've tried several variables for the DAC, but the output is always static.

[Dave_PT]

After some adjustments the encoder is operating on the main controller.
The controller energize the motor to align the encoder and starts running from there. If I understood correctly ...
After some tuning it works.

But I still can not control the speed at low speed. The motor runs out of torque ...

How can I fine tune the torque?

[tatus1969]

Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not 

I do not see anything in scope.
I've tried several variables for the DAC, but the output is always static.

Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

[tatus1969]

- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?

Yes it has an incremental output (I channel).
The encoder is this (PDF downloads automatically): https://ams.com/kor/content/download/725051/1853902/file/AS5047P_DS000324_2-00.pdf
It also gives absolute rotor angle.

As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.

[Dave_PT]

Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE


In the "UI_TaskInit" file the DAC is enabled.


I am using serial communication to use STMCW...

As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.

OK friend.

I'm going to do just one more test and switch to hall sensor emulation. But the sensor and magnet in the rotor not need to be aligned?

[tatus1969]

Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE

In the "UI_TaskInit" file the DAC is enabled.

I am using serial communication to use STMCW...

Hmmm, hard to say without having the hardware on my table. The AOUT feature worked without hassles right from the beginning for me and was of great help, but I remember having removed all the eval board stuff in the very beginning, because I was using my custom board right from the start. The NUCLEO board is supposed to deliver the analog signal at X2 / pin 3 ("A2"). I hope you didn't probe at pin 5 "A4".

As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.

OK friend.

I'm going to do just one more test and switch to hall sensor emulation. But the sensor and magnet in the rotor not need to be aligned?

It needs to. You can configure the offset in degrees in STMCWB -> hall motor feedback parameters "placement electrical angle". The "sensors displacement" must be 120°.

The simplest way to find out the correct offset is the following (alternatively you can grab a scope and probe phases and halls, but there can be a lot of pitfalls in interpreting them correctly):
- start with offset 0
- start the motor with maximum torque and velocity settings
- the motor will likely spin in one or the other direction
- now repeat the process, but increment the offset by, lets say, 30 degrees per try, until you find the precise offset in which the motor does *not* turn anymore. you may also turn the shaft by hand and feel if the counter torque is equal in both directions. decrease your offset step width until you have found that precise offset angle

Now set this value, plus 90 degrees, as your final offset value.

If the motor spins in opposite direction as you want, add another 180 degrees.

If your magnet orientation is not repeatable in later mass production (I hope it is), you can also implement this strategy in software.

[tatus1969]

After some adjustments the encoder is operating on the main controller.
The controller energize the motor to align the encoder and starts running from there. If I understood correctly ...
After some tuning it works.

But I still can not control the speed at low speed. The motor runs out of torque ...

How can I fine tune the torque?

If the motor runs out of torque, then there still is a problem with configuration. FOC basically works as two nested PI control loops:
- the outer loop controls velocity and calculates a torque value: set_torque = PI ( set_velocity, current_velocity )
- the inner loop controls torque and calculates motor set_voltage: voltage = PI ( set_torque, current_torque )

For a PMSM, motor torque is proportional to phase current (magnitude of 3-phase current vector), so you can replace torque by current in the above.

The set_torque resp. set_current value is limited by the rated motor current that you provide.

You can see that you'll get full torque in all situations, also in standstill. This makes FOC ideal for servo applications like yours. I have made a 25kW servo using this, and I have it made playing music by controlling velocity setpoint for fun. I had to make sure it is tightly bolted to the table, or it would jump off just from rotor inertia. It was amazing, you couldn't even *hear* it accelerating or decelerating.

[Dave_PT]

Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.

EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.

My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE

In the "UI_TaskInit" file the DAC is enabled.

I am using serial communication to use STMCW...

Hmmm, hard to say without having the hardware on my table. The AOUT feature worked without hassles right from the beginning for me and was of great help, but I remember having removed all the eval board stuff in the very beginning, because I was using my custom board right from the start. The NUCLEO board is supposed to deliver the analog signal at X2 / pin 3 ("A2"). I hope you didn't probe at pin 5 "A4".

In fact I'm doing probe of the A4 pin. This pin is marked on the schematic as the DAC pin.


EDIT:



Once again you're right.
The resistor R76 is not assembled and so in J7 there is no DAC.
But on pin C7_32 I already have the triangular shape of the encoder.

[Dave_PT]

If the motor runs out of torque, then there still is a problem with configuration. FOC basically works as two nested PI control loops:
- the outer loop controls velocity and calculates a torque value: set_torque = PI ( set_velocity, current_velocity )
- the inner loop controls torque and calculates motor set_voltage: voltage = PI ( set_torque, current_torque )

For a PMSM, motor torque is proportional to phase current (magnitude of 3-phase current vector), so you can replace torque by current in the above.

The set_torque resp. set_current value is limited by the rated motor current that you provide.

You can see that you'll get full torque in all situations, also in standstill. This makes FOC ideal for servo applications like yours. I have made a 25kW servo using this, and I have it made playing music by controlling velocity setpoint for fun. I had to make sure it is tightly bolted to the table, or it would jump off just from rotor inertia. It was amazing, you couldn't even *hear* it accelerating or decelerating.

I have to work on it.
I do not have to calibrate the values of Iq and Id PID's?

Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...
For some reason, I can only use integers.

[tatus1969]

one more idea: to test if everything is working as it should, you can
- use speed control mode
- have the motor rev up and find its encoder alignment
- set zero rpm

The motor has to abruptly stop. When you try to turn the shaft by hand, you should feel the same holding torque in both directions. If that is asymmetrical instead, it is a direct indication of an incorrect encoder alignment.

[Dave_PT]

There is something very wrong!

I unplugged the encoder cables and did "start_motor" and the motor started  .

[tatus1969]

I do not have to calibrate the values of Iq and Id PID's?

(Although they name it PID control, it is actually PI control (no differential term)...) STMCWB automatically calculates a set of Kp / Ki based on the motor parameters that you typed in, and that should be good to start with. But as I mentioned in an earlier post I did my own tuning and don't trust their calculations a lot anymore. The difficulty with own tuning, as mentioned, is that you need a step input for the torque/current setpoint, and you don't want the motor to be able to move, even a little, in order to be able to obtain a nice clear step response reading on your scope (set AOUT = Iq).

Another thing that may important. You can adjust the current controller's update rate in multiples of PWM cycles. Don't make it too slow, or the controller may become instable. If your motor inductance is low, then you need a fast current controller. I suggest to set  (Drive Management -> Drive Settings -> Torque&flux regulators -> Execution rate) to get an update rate of > 5kHz to stay on the safe side.

Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...

Torque ref / Iq is the current setpoint value for the current PI controller that I am talking about. That is the current that you want to flow through the phases. The other value, Flux ref / Id, is always zero in a servo application. I made some explanations on this in another thread: https://www.eevblog.com/forum/chat/regulating-speedtorque-of-induction-motor-methods/?all

For some reason, I can only use integers.

Probably a bug, but maybe they forgot the conversion between float[amps] and their internal fixpoint integer values. What happens when you set 1? If the motor spins, then it is Amperes. If not, try larger numbers up to +-32767.

[tatus1969]

There is something very wrong!

I unplugged the encoder cables and did "start_motor" and the motor started  .

It starts sensorless, and tries to switch over to encoder, but only if it is present. The library always monitors the validity of its connected speed sensors. If you disconnect the cable, it will stay in sensorless mode.

[Dave_PT]

Another thing that may important. You can adjust the current controller's update rate in multiples of PWM cycles. Don't make it too slow, or the controller may become instable. If your motor inductance is low, then you need a fast current controller. I suggest to set  (Drive Management -> Drive Settings -> Torque&flux regulators -> Execution rate) to get an update rate of > 5kHz to stay on the safe side.

This should not be a problem. My execution rate is 2 PWM period (15KHz).

Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...

Torque ref / Iq is the current setpoint value for the current PI controller that I am talking about. That is the current that you want to flow through the phases. The other value, Flux ref / Id, is always zero in a servo application. I made some explanations on this in another thread: https://www.eevblog.com/forum/chat/regulating-speedtorque-of-induction-motor-methods/?all

Thank you.
I'll read the post.

For some reason, I can only use integers.

Probably a bug, but maybe they forgot the conversion between float[amps] and their internal fixpoint integer values. What happens when you set 1? If the motor spins, then it is Amperes. If not, try larger numbers up to +-32767.

Yes it is a bug.
I can only use integers in the "monitor". In the STMCW configurator I can enter current with decimal places.

[Dave_PT]

There is something very wrong!

I unplugged the encoder cables and did "start_motor" and the motor started  .

It starts sensorless, and tries to switch over to encoder, but only if it is present. The library always monitors the validity of its connected speed sensors. If you disconnect the cable, it will stay in sensorless mode.

I think the controller is not using the encoder channels even after I select the encoder on the main sensor.
Already after the motor is running I turn off one of the channels of the encoder and still it continues to run properly.
In this situation I'm pretty sure it would give a fault.

It's a strange situation ...

[Dave_PT]

Am I doing something wrong?

One question: in the last image I do encoder align and then start motor, but the motor does not rotate. Was not this the right procedure?

[Dave_PT]

I'm starting to walk in circles ...
I'm not making progress.

In this link is the SDK configuration file.

https://meocloud.pt/link/ba2e6d66-9d51-4cac-80eb-46542dcb6d27/ro_mot.rar/

[tatus1969]

Am I doing something wrong?

One question: in the last image I do encoder align and then start motor, but the motor does not rotate. Was not this the right procedure?

Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position. Also very make sure that
- the encoder angular resolution matches the reality, in your case 512 (I see that the encoder chip is programmable)
- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.

[tatus1969]

I'm starting to walk in circles ...
I'm not making progress.

In this link is the SDK configuration file.

https://meocloud.pt/link/ba2e6d66-9d51-4cac-80eb-46542dcb6d27/ro_mot.rar/

Checked the file and have a few questions.
- you have enabled motor temperature sensing, are you sure that this is not triggering? Maybe temporarily disable it, maybe also disable bus voltage monitoring and over-current protection to be on the safe side
- I saw the nucleo power board can be configured to one-shunt and 3-shunt, is that set to 3-shunt?
- you can try to reverse the encoder's counting direction in STMCWB (in Drive Management -> Speed Pos... -> Main sensor), if these mismatch the motor can also never run
- 15kHz current loop update rate is quite high, don't know if the CPU can handle that. Maybe try :4 ratio from PWM instead of :2
- you have enabled current feed forward ("Additional Features and PFC settings"). Possible instability if motor parameters are not perfect, suggest to disable that temporarily

[Dave_PT]

Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position.

Apparently nothing.
I was hoping the current of my power supply would increase. But that does not happen.

- the encoder angular resolution matches the reality, in your case 512 (I see that the encoder chip is programmable)

I already received the motor with the encoder mounted. Initially I thought it was 1024 pulses per mec/rev (this is the default value).
However, I activated the oscilloscope pulse count and it counts ~ 512 pulses per 1 mec/rev (without the reduction box, of corse).

- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.

I think the motor has 3 pairs of poles, but the seller says it has 4 poles, 2 pairs.
Tomorrow I will do this test to verify. Thank you!

Checked the file and have a few questions.

Luckily for me .

- you have enabled motor temperature sensing, are you sure that this is not triggering? Maybe temporarily disable it, maybe also disable bus voltage monitoring and over-current protection to be on the safe side

The temperature is measured next to the motor driver.
It rarely rises above 40 ° C (my tests are very short).
But I can deactivate all these safety features momentarily.

- I saw the nucleo power board can be configured to one-shunt and 3-shunt, is that set to 3-shunt?

It is indeed.
All headers are in the correct position for FOC and 3 shunt measurement.

- 15kHz current loop update rate is quite high, don't know if the CPU can handle that. Maybe try :4 ratio from PWM instead of :2

I'll try this and also lower the PWM frequency to 25KHz.
With a ratio of :4, the loop current control is done at 6.25KHz.

- you have enabled current feed forward ("Additional Features and PFC settings"). Possible instability if motor parameters are not perfect, suggest to disable that temporarily

I enabled this feature for testing.
Since I was having poor results, I activated this function to see if the system would react differently.

I do not understand, if everything is set up to work with the encoder (and this sensor is the only feedback), why can I remove the wires and it will continue to work fine.
The encoder reading is certainly not being activated.

[Dave_PT]

- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.

I think the motor has 3 pairs of poles, but the seller says it has 4 poles, 2 pairs.
Tomorrow I will do this test to verify. Thank you!

The motor indeed has 2 pairs of poles. There is 2 "snaps" per rev.

I've done some more tests and the result is still the same ...

[tatus1969]

Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position.

Apparently nothing.
I was hoping the current of my power supply would increase. But that does not happen.

I do not understand, if everything is set up to work with the encoder (and this sensor is the only feedback), why can I remove the wires and it will continue to work fine.
The encoder reading is certainly not being activated.

If you select encoder, then the motor should never be able to spin without it, and the motor referencing must apply current to the motor for that one second that you configured, you must see the motor snapping into a certain position (I think they are slowly ramping up the current though, so it would not be a snap but a 'tightening'). And you must see current consumption increasing. But attention: don't expect the system draw 1 amp when it should generate 1 amp of motor current. The motor doesn't generate shaft power (shaft power = 2*PI * M * n, and n is zero), so an ideal system would not consume input power. It only does because of resistive / switching losses.

Something must be going horribly wrong. I can only see the build system and project setup as a possible root cause here (unless ST has messed up evrything in ver 4.3).

I suggest to debug the code and see if the right code is being executed. First step into MCTasks.c / MCboot, and see which lines contain code and which not. See if the encoder object is being initialized (oSpeedSensor[M1]). If that is okay, run the remote control and set a breakpoint in the large case switch, in case "ALIGNMENT". Trigger the alignment procedure, and you should arrive at the breakpoint. If that is the case, then you can check the values that are written into the IqdRef struct, the qI_Component2 element must contain increasingly large values.

[Dave_PT]

Wait ... on file MCTasks.c, can you explain the logic to this? 

Code: [Select]

#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1;                         /* only if M1 is sensorless*/
#endif

Now it makes some sense.
They are not even initializing the encoder. Just like I thought ...

"encoder" is never defined.