Problems with STM32 PMSM FOC SDK

[tatus1969]

PS: I've been watching the STM forum and there are some complaints of problems at low speeds. However, the general problems are because they all use sensorless ... which is not my case.

I've also experienced that. I think that their mathematical models that translate motor parameters into parameters for their sensorless observer implementation aren't very good. I ended up with doing things in reverse, changing the STMCWB motor parameters and watching how that affected stability and accuracy. And I learned that probably only the Cordic algorithm is usable, I never managed to get the PLL mode stable under all speed/load conditions. But doing so, I came to satisfactory results. The motor is controllable down to 15 rpm (mechanically) / 4 Hz (electrically). (I hear you asking: no, no cogging at all... )

[Dave_PT]

I have prepared some videos that show how I validated the relationship between phase voltages, phase currents, and the rotor position feedback. Hope this helps

https://www.kicksurfer.de/index.php/2017/03/15/bldc-motor-and-foc-controller-phase-current-validation/

In the 2nd video I can not get a perfect wave if I turn without the gearbox.
In the picture, the blue line is the phase-star voltage.



Only with the gearbox I can have a perfect sinosoid.
I was able to align the encoder with the phase voltage.



I'm watching current Ia via DAC.
I'm triggering whith the sensor hall. But current Ia does not "stay in the same place"... does not stay synchronous.

https://meocloud.pt/link/24b6ff74-3164-4a8c-9493-e7d551fe78e8/VID_20170316_103615.3gp/

[tatus1969]

I was able to align the encoder with the phase voltage.

Just to be sure: you mean the Hall senror here, right?

I'm triggering whith the sensor hall. But current Ia does not "stay in the same place"... does not stay synchronous.

wait, do I get this right? In the setup with the magnet attached to the wheel, then you get a voltage waveform that is synchronous to the Hall signal, and a current waveform which is not?

Some other questions/ideas:
- what is the exact reduction factor of that gearbox? Is it an integer value? You can you expect the motor orientation to be the same every time the magnet passes the Hall sensor ONLY if that is the case.
- did you load the motor during phase current measurement?
- how did you measure phase current? I would not use the DAC channel here because it is the controller/firmware/encoder setup that we you are debugging, and I would only rely on "real" measurements (shunt, current probe, ...) at the moment.
- can you make another measurement, showing the encoder via DAC channel, the Hall sensor output, and the phase voltage?

[Dave_PT]

I was able to align the encoder with the phase voltage.

Just to be sure: you mean the Hall senror here, right?

Yes yes... my mistake.

[tatus1969]

I was able to align the encoder with the phase voltage.

Just to be sure: you mean the Hall senror here, right?

Yes yes... my mistake.

sorry by being picky, but that's necessary for me to follow closely from my "remote" position 

[Dave_PT]

wait, do I get this right? In the setup with the magnet attached to the wheel, then you get a voltage waveform that is synchronous to the Hall signal, and a current waveform which is not?

Apparently yes.
I do not have any current probe, so I'm watching it by the DAC of the micro. Can there be some delay here? But it should be constant, right?
Is the current Ia to be observed?

- what is the exact reduction factor of that gearbox? Is it an integer value? You can you expect the motor orientation to be the same every time the magnet passes the Hall sensor ONLY if that is the case.

The reduction is 29: 1.

- did you load the motor during phase current measurement?

Yes. The amplitude got bigger, but the timing was the same.

- how did you measure phase current? I would not use the DAC channel here because it is the controller/firmware/encoder setup that we you are debugging, and I would only rely on "real" measurements (shunt, current probe, ...) at the moment.

I was using the DAC to see Ia, but now I made probe at the ampop output. The result is the same.
https://meocloud.pt/link/1709d055-2f11-4f86-9a4f-60022009ac78/VID_20170316_111607.3gp/

- can you make another measurement, showing the encoder via DAC channel, the Hall sensor output, and the phase voltage?

I do not know if I understood correctly ... but would have to disconnect the motor again, put it like the first video and measure Vphase?


Another video.
Hall sensor with electrical angle.
https://meocloud.pt/link/9e546b85-a8cb-41aa-a6dd-bacc134cc18c/VID_20170316_112436.3gp/

[Dave_PT]

I didn't read the whole thread, just picked on the slow motion problems, yeah, sorry. Are you sure your encoder is behaving well at low speed? Or maybe the code isn't prepared to or doing enough "debouncing" on the encoder's signal (don't know which encoder you're using). Throwing out some possible causes at you

Yes, the thread is already going long!
Thanks to the precious help of tatus1969.

I've already manually turned the motor shaft and saw the encoder outputs (A + B) and that's fine.

But I'm beginning to believe that there might be some limitation in the firmware that prevents low revs. However I start to have problems below 300 / 400RPM ... it's not really "low revs" 

[Dave_PT]

...

a) forced rotor angle (here you can set the speed by changing the increment step) as already explained:
...

b) set controller to torque mode in STMCWB, and apply current.

This way the FOC algorithm will just create three sinusodial phase currents, rotating at a given frequency, no matter what the motor is doing. The encoder feedback is not used here.

...

This is it.

It runs in a similar way to what I did yesterday.

If I increase Iqref I feel the engine making more force before jumping.

I write 6 step commutation for being a simpler control method and I can do the whole firmware.
But in stepper the torque control gets very complicated...

[tatus1969]

wait, do I get this right? In the setup with the magnet attached to the wheel, then you get a voltage waveform that is synchronous to the Hall signal, and a current waveform which is not?

Apparently yes.
I do not have any current probe, so I'm watching it by the DAC of the micro. Can there be some delay here? But it should be constant, right?
Is the current Ia to be observed?

- what is the exact reduction factor of that gearbox? Is it an integer value? You can you expect the motor orientation to be the same every time the magnet passes the Hall sensor ONLY if that is the case.

The reduction is 29: 1.

- did you load the motor during phase current measurement?

Yes. The amplitude got bigger, but the timing was the same.

- how did you measure phase current? I would not use the DAC channel here because it is the controller/firmware/encoder setup that we you are debugging, and I would only rely on "real" measurements (shunt, current probe, ...) at the moment.

I was using the DAC to see Ia, but now I made probe at the ampop output. The result is the same.
https://meocloud.pt/link/1709d055-2f11-4f86-9a4f-60022009ac78/VID_20170316_111607.3gp/

- can you make another measurement, showing the encoder via DAC channel, the Hall sensor output, and the phase voltage?

I do not know if I understood correctly ... but would have to disconnect the motor again, put it like the first video and measure Vphase?


Another video.
Hall sensor with electrical angle.
https://meocloud.pt/link/9e546b85-a8cb-41aa-a6dd-bacc134cc18c/VID_20170316_112436.3gp/

Now that is certainly the breakthrough.

Summarizing: the gear reduction ratio is integer, proven by the fact that motor phase voltage stays synchronous with hall sensor. The encoder output (and thus also the current waveform, as it is generated from it) is *not* synchronous to the hall sensor.

This definitely means that the encoder's count per (mechanical) revolution is wrong. This also explains the huge cogging and low generated torque. It also explains the results from your experiments with open-loop control. I suggest that you concentrate now on getting the hall sensor / electrical to stay synchronized. As you have 2 pole pairs and a gear reduction rate of 29:1, you should expect to see exactly 58 full sawtooths per hall sensor pulse, and all that in synchronosity. As long as you don't see that, you can be sure that you have a mismatch between the generated encoder ppr and the expected number by the FOC library.

[Dave_PT]

This definitely means that the encoder's count per (mechanical) revolution is wrong. This also explains the huge cogging and low generated torque. It also explains the results from your experiments with open-loop control. I suggest that you concentrate now on getting the hall sensor / electrical to stay synchronized. As you have 2 pole pairs and a gear reduction rate of 29:1, you should expect to see exactly 58 full sawtooths per hall sensor pulse, and all that in synchronosity. As long as you don't see that, you can be sure that you have a mismatch between the generated encoder ppr and the expected number by the FOC library.

I already tested it yesterday and I was able to verify that the encoder pulses are correct.

I'll redo the tests again.

In speed control for 1500RPM.

(1500RPM / ratio 29) / 60 = 0.862Hz

The electrical rotations between the  hall sensor pulses are 58.

[tatus1969]

The electrical rotations between the  hall sensor pulses are 58.

If it were exactly 58, then you would see synchronicity between hall and encoder. Which you don't. Its probably 58.01, or 57.99.

[tatus1969]

That's not a proof that the encoder is counting correctly. It it would count 501ppr instead of 500, then you would not be able to notice it from the measurement that you show here... What do you see if you zoom in at both cursor positions? You should see exactly the same voltage at AOUT whenever the hall sensor output is at trigger level.

[Dave_PT]

Can such a small difference be caused by the gear box and the error wheel - hall sensor?

The encoder is set to 500ppr so you should only produce these pulses for each mec. Rev. ...

In fact there is a slight difference at the end of a rotation ...

First pulse:


Last pulse:


After doing the math, there are about 57.94 pulses.
Therefore the encoder counts 500.52 pulses per rotation.
I have an error of approx 0.36º.

[Dave_PT]

If I change the encoder pulses per revolution to 501 or to 499, the effect is this.
The motor does some rotation and then stops.

https://meocloud.pt/link/c76a2aa2-0a29-4f02-9a8d-a242b5ef009c/VID_20170316_152233.3gp/

[tatus1969]

These are planetary gear boxes, unless there is a mechanical problem like a loose motor gear, they cannot slip.

I checked the motor datasheet where they list the available gear reduction ratios, that lists a 2-stage planetary gear box with a reduction ratio of 28.9. Nothing with 1:29.


Are you absolutely sure that the phase voltage was always in sync with the hall sensor?

Your test with ppr=499 and 501 also suggests that the encoder ppr=500 is correct, and that the out-of-sync between hall and encoder/current comes from a fractional gearbox reduction ratio.

Looking at your last two screenshots, I get
- time for one electrical motor rev = 19ms
- lag of hall sensor after 58 electrical motor revs = 2.4ms

From that I calculate a lag of 2.4 / 58 / 19 = 0.218%.

If the gearbox is 1:28.9 instead of 1:29.0, then this would cause a lag of 0.1/29.0 = 0.345%.

Just one more question: the sawtooth in the screenshots is motor electrical angle, and not "raw" encoder angle, right? Otherwise I would have expected ~29 cycles only per wheel rev.

[Dave_PT]

I'm not sure there was any printing error, but on the sticker I got the indication that it's a 29: 1 reduction box

Are you absolutely sure that the phase voltage was always in sync with the hall sensor?

That's the best I can do manually.

Looking at your last two screenshots, I get
- time for one electrical motor rev = 19ms
- lag of hall sensor after 58 electrical motor revs = 2.4ms

I can give you these values.

- time for one electrical motor rev = 20.02ms
- lag of hall sensor after 58 electrical motor revs = 1.7ms

1.7/58/20.02 = 0.00146

Just one more question: the sawtooth in the screenshots is motor electrical angle, and not "raw" encoder angle, right? Otherwise I would have expected ~29 cycles only per wheel rev.

Yes. The sawtooth wave is the electrical angle motor.

[Dave_PT]

 

It's not easy to solve this.

 

[nuno]

Thanks to the precious help of tatus1969.

Maybe they rounded the number for the sticker.

[mrflibble]

I have not read the entire thread, just the last bits, so I might have
missed something... That said, if I understand correctly there is still some
uncertainty regarding the gear ratio, correct?

It should be 29:1 , but it just might be 28.9:1.

In the measurement in this image it's indeed rather difficult to guess if it's 29:1 or 28.9:1.

Maybe you've already done what I'm about to suggest, in which case disregard.
But if not, one possibility is this:

1 - Trigger on the positive edge of the blue signal
2 - change timebase such that you get about 2.5 full waveforms in view.
    If you use 1500 RPM ==> 25 revs/sec, then a timebase of 10 ms / div
    should do just that.
3 - Turn on persistence
4 - Use the right trigger type ....

And the "right" trigger type depends a bit on the capabilities of your
scope. If it can do equivalent time sampling, use that. If it doesn't
have ETS then you probably can do a divide-by-N. As in set it to trigger
on every Nth positive going edge of the blue signal. So what N to choose?

The two candidate ratios and their prime decompositions are:
29:1   --> 290/10 = 290/(2*5) =      29/1
28.9:1 --> 289/10 = 289/(2*5) = (17*17)/(2*5)
                         ^^^--------------------------- See (*) comment below about 2's in the denominator.

Triggering is always on the blue signal.

Now if you trigger on every 290th edge, with persistence on then:
If you have a 29:1 gear then for those 290 edges in the blue signal you
should get 10 edges in the orange signal. Nice integer multiples. If on the
other hand you happen to have a 28.9:1 gear then no nice integer multiples.

Possible results:
A1 - Nice clean edges for the orange signal   ==> absence of bad news, probably good news (29:1 as you expect)
A2 - Orange signal smeared all over the place ==> Nope, that's no 29:1 gear ratio

And as a sanity check do it the other way around. Trigger on every 289th edge, again with persistence on.

Now the possible results are:
B1 - Nice clean edges for the orange signal   ==> absence of good news, probably bad news (28.9:1, nooooo)
B2 - Orange signal smeared all over the place ==> highly unlikely it's a 28.9:1 gear ratio

What you want is results A1 and B2. Then it's pretty sure that it is a 29:1 gear, and not a 29.9:1 gear.

What you definitely do not want is results A2 and B1, because then in all likelyhood it's a 28.9:1 ratio
as per the datasheet that tatus1969 mentioned.

Is say things like "pretty sure" and "probably" because I've seen enough
funky shit with triggering on some scopes. Anyways, you will be able
to judge that since you know your scope. Case in point, on my HP boat anchor
I would trust the results and say "sure" and "certain". But doing those same
measurements on my rigol I would have to stick with "pretty sure" and "probably". 

(*) If you worry about a factor of 2 because I "accidentally" used a factor of
29 instead of 58, then no worries. I did that accidentally on purpose. We can
happily ignore this factor of 2 because both ratios have a 2 in the denominator
of the prime decomposition.

So if you insist on a factor of 58 then you still get similar results. The main
difference being that now for every 290 (**) blue edges, you would get 5 orange
edges instead of 10.

(**) Well, either 290 or 289, depending on it being a 29:1 or a 28.9:1 gear.

Anyways, hope this helps in finding out what's going on.

PS: Assuming that 1500 RPM really is 1500 RPM, then based purely on the delta T for Cursor 1 the ratio is closer to 28.9:1 than 29:1.
Depends a bit on the standard deviation. Oh yeah, almost forgot to mention that. If you turn on the statistics for that
Cursor 1 then you might be able to do an educated guess too. If the stddev on that 1.154 s is high, then chances are good that it is not 29:1.
If the stddev is low, then it probably is 29:1. And this "high" and "low" being relative to the period of the blue signal. Quick guess ... stddev
larger than 1/3 * period of blue signal ==> probably not an integer multiple, so no 29:1 ratio.

[tatus1969]

I'm not sure there was any printing error, but on the sticker I got the indication that it's a 29: 1 reduction box

The manufacturers ofen round the numbers. From the label plate, the gearbox could be this one here:

https://www.imsgear.com/en/imsbaseline?file=tl_files/assets/downloads/engl/products/PLG/IMS.baseline_PM52_EN.pdf

They have a model with reduction ratio 1:28.93

Are you absolutely sure that the phase voltage was always in sync with the hall sensor?

That's the best I can do manually.

I guess that you were moving the wheel forth and back around the hall sensor trigger point when aligning the motor phase, and that you didn't make do full revs of the wheel at this time. So probably if you would repeat that setup and do that, you would also see the phase walking around.

Looking at your last two screenshots, I get
- time for one electrical motor rev = 19ms
- lag of hall sensor after 58 electrical motor revs = 2.4ms

I can give you these values.

- time for one electrical motor rev = 20.02ms
- lag of hall sensor after 58 electrical motor revs = 1.7ms

1.7/58/20.02 = 0.00146

If my guess for that gearbox is right, then it does a slip of (29 - 28.93) / 29 = 0.0024. Not very close, but maybe close enough to come to this conclusion.

To me this means
- the encoder ppr is properly setup. It measures exactly 1 mech / 2 electrical cycles per real mech rev. The test with 499 / 501 ppr proves this best. When the motor can run continuously on 500ppr, you also know that the signal integrity is good.
- the gear box does not have an integer ratio, so you cannot use a magnet on the wheel for these measurements
- your encoder alignment does not work yet, so we have to come up with a different approach to find a working alignment angle

Does your encoder have an index channel? If yes, and because I think that we can trust the encoder signal, then you could use that instead of an external hall sensor for scope triggering.

Then, can you use the output gear of your second motor to drive the one under test, to obtain nice back-emf voltage waveforms?

If that is all not feasible, then I have a different approach. The goal of all this is to find the correct rotor angle. If you have that, then the motor will operate with maximum torque in both spinning directions. If you are off by 90°, then the motor will produce zero torque. If you are off by a small amount, then the motor will spin better in one direction than in the other.

We can use this to find the best angle. What you can do is, to repeat the open-loop setup with

Vqd.qV_Component1 = 4000;
Vqd.qV_Component2 = 0;

You also need to load the output shaft in a controlled way. You could connect the two motors back-to-back, and use the second one as a generator. Use 6 diodes to create a three-phase full wave rectifier, and connect a power resistor to the output. You could even use the power stage of your FOC controller, and connect the resistor directly across the DC bus. The MOSFET's body diodes will act as the recifier then.

Then, adjust the encoder alignment angle in small steps, from -90° to +90°, lets say in 5° steps.

Each time, run the alignment (I suggest to use maximum target current here, and 1s alignment time), and let the motor drive the load. Watch the resulting rpm under load.

After you have found the alignment angle that results in the most rpm under load, then repeat the test with this setting

Vqd.qV_Component1 = -4000;
Vqd.qV_Component2 = 0;

This reverses spinning direction. Watch if you get the same rpm. If not, then continue searching for the right alignment angle, until you find one that produces the same rpm under load in both spinning directions.

[tatus1969]

Thanks to the precious help of tatus1969.

Always good to receive other opinions, we're a bit stuck here.

[Dave_PT]

Thanks for all the answers.
I'll read everything carefully.

For now I have a question.

Does your encoder have an index channel? If yes, and because I think that we can trust the encoder signal, then you could use that instead of an external hall sensor for scope triggering.

Then, can you use the output gear of your second motor to drive the one under test, to obtain nice back-emf voltage waveforms?

My encoder has an index channel.
I can use it to trigger the oscilloscope.
In theory the index signal will always appear on the same point of the Bemf wave, right? - in this case, the index will appear every 2 revolutions.

What are we looking here?
Any lags?

Another thing that is creating doubts ...
If I were to use a hall encoder, I understand that it would be important to align the magnet with the rotor and get the UVW switches at the right time.
If I am using an incremental encoder, should the encoder alignment angle not always be zero?
I think that when encoder alignment is done, the algorithm simply clears the timer 2 register and all calculations are done based on that.
This was the great advantage of being able to do self alignment. The magnet is glued to the motor shaft at any position and the auto alignment compensates for the deviation.

Modifying encoder alignment angle is the same as rotating the magnet.

Am I realizing this well?



PS:
I'm thinking that the problem might be the SDK or FOC algorithm in this motor...
I've been seeing alternatives and these may be the best if we do not get any progress from here.
What do you think?

https://my.st.com/content/ccc/resource/technical/document/user_manual/group0/90/b6/9f/0c/50/c1/47/1d/DM00334922/files/DM00334922.pdf/jcr:content/translations/en.DM00334922.pdf

[tatus1969]

My encoder has an index channel.
I can use it to trigger the oscilloscope.
In theory the index signal will always appear on the same point of the Bemf wave, right? - in this case, the index will appear every 2 revolutions.

Exactly.

What are we looking here?
Any lags?

No. As you explain further below in your reply, that is fully compensated for during encoder alignment. Let me explain what I am trying to achieve with the methods that I proposed in my last posts.

First, to the encoder alignment procedure. In details, it works this way:
- force electrical angle to the angle that you provided as the "offset" in STMCWB, and keep it like that during the entire procedure (they do this by temporarily switching to a "virtual" speed feedback module that does not listen to any sensor, it just holds the angle that you give it)
- linearly ramp up current with Iq=0 and Id=current
- when the ramp has reached its final level, then also set the electrical angle of the encoder feedback module to the offset value that you provided
- set current to zero again, switch to encoder position feedback, motor can start

You have to look closely to what happens here, they did some clever things that are not easy to notice. At first, they do "Iq=0 and Id=current". During normal operation, you know that you will do "Iq=current and Id=0" instead. The trick here is: when they ramp up the current at a given (and constant) electrical angle, then the motor will lock into that angle which yields minimum magnetic force. This angle is exactly 90° away from the one with maximum force that we are seeking for. The vectors "Iq=0 and Id=current" and "Iq=current and Id=0" are just those 90° apart from each other.

The other trick is regarding the offset. As I mentioned earlier, it is not just added somewhere. The idea here is to give you the choice at which absolute electrical angle you want the alignment procedure to happen. If you set that to 0°, then the procedure will create a 3-phase current with (x + 90°) angle (the 90° comes from using Iq instead of Iq), meaning U=cos(x+90°)*current, V=cos(x+210°)*current, W=cos(x+330°)*current. If you would increase that offset angle stepwise and repeatedly execute the alignment, then you would actually see the motor rotating slowly. It is basically the same as doing that stepper motor scheme.

The last part of the trick is quite simple: when the alignment is done with a 3-phase current at angle (x + 90°), then it can be expected that the motor has been mechanically locked to angle (x + 90°), and we know that angle x will be the one that will yield maximum torque. So they set the encoder angle to x.

There is one very important thing to understand here. During alignment, the motor jumps to an angle with zero torque. But what we want to find is the angle that would do maximum torque. So we have to assume that they are exactly 90° away from each other.

Here lies the problem: this assumption implies that the motor behaves sinusodial. Your motor is far away from that. So if the alignment procedure creates a current vector of 0°, then the motor may lock into a physical angle of e.g. 30°. And we also cannot assume that the angle of maximum torque is 90° away from that.

But what we know is that the alignment error that we have is something that moves around the correct value once we start varying the offset angle. There will be settings where we measure a too high angle, there will be some where we measure a too low value, but there also will be offsets that happen to result in correct alignment.

Therefore I proposed to stepwise vary the alignment offset. But how can you measure how good the alignment was (how close it is to producing max torque)? Therefore I proposed two methods:
1) comparing back-emf voltage with generated phase current, they are exactly in phase on success. All you need to do here is repeat the procedure, but use the index channel to trigger.
2) apply torque and run the motor in both directions. If torque is equally high, then success.

Phew... hope I explained clearly

Another thing that is creating doubts ...
If I were to use a hall encoder, I understand that it would be important to align the magnet with the rotor and get the UVW switches at the right time.

That is only true for 6-step algorithms. FOC works differently here, because it has to interpolate between the 6 states that it receives, in order to maintain an electrical angle value with fine resolution. Otherwise it could not produce sinusodial waveforms. You can better see the hall encoder as a low-update-rate speed and position sensor here. You can imagine that it is very easy for them to allow an angular offset to all this. You can set this in the hall sensor config page. So, the actual orientation here is not important (in contrast to 6-step commutation!).

PS:
I'm thinking that the problem might be the SDK or FOC algorithm in this motor...
I've been seeing alternatives and these may be the best if we do not get any progress from here.
What do you think?

https://my.st.com/content/ccc/resource/technical/document/user_manual/group0/90/b6/9f/0c/50/c1/47/1d/DM00334922/files/DM00334922.pdf/jcr:content/translations/en.DM00334922.pdf

I think that, after you have debugged the alignment process, you will end up with a setup with correct angle relationships creating maximum torque. And the jumpiness at low revs will also be drastically reduced.

EDIT: As your goal is softness at low revs, you will not come closer to it by switching to  6-step commutation, because that can only jump into 6 different states / angles per electrical rev.

[tatus1969]

is it possible that there is a problem in the power stage, or the current sensing? to check that, you can run the motor again as stepper, and probe the three phase voltages (add a RC lowpass before the scope probe) as well as Ia and Ib via DAC. the currents must be perfect sinusodial, and the voltages must be SVPWM style. scratching my head of what is happening there at your desk.

can you notice that the motor locks at changing angles when you change the alignment offset? does it start when you help it manually? if not, does it feel the same in both directions?

[Dave_PT]

I've been varying the angles to see when the motor runs.
I have had values in which the motor does not spin and others in which it spin.

But when I connected the motor to the gear box, the motor does not have enough torque to turn the gears at any angle.

I will continue to vary values and observe what happens.