IPM Motor Simulation and FOC Software

[Ev8]

Just managed a quick test of this software, so far I’m impressed, no unwanted regen when lifting off, I’ve not tested any field weakening yet as generally I don’t exceed 5k rpm, had a quick play with MTPA parameters but not sure by how much I should be experimenting or what to expect, I need to get reading on mtpa

[Pete9008]

Just went for another test drive with fwmargin set to 6000 and fwkp=50 (which is really 50/32 because of scaling). Now we come alive! Unfortunately the FW controller oscillated strongly but when it oscillated towards much field weakening I could feel how much power is in there. Reducing fwkp leads to the controller outputting too little FW current (fwkp=5 on the left side, 15 on the right side). So I think adding fwki might help here.

Getting there, that plot makes much more sense!

Have had a play with the simulator, a bit of PI gain tweaking has got to this:

That's using a margin of 2000 (2100 gave very similar results), kp=2000, ki=100, FW kp=1, FW ki=20. I found any more FW kp caused serious oscillations. It's also with Mtpa disabled to make the plots clearer.

It looks pretty good apart from the very odd dip on Iq when FW starts to come in, not too sure what's causing that yet.

If you let the simulation carry on it runs out of Id as speed increases and looses control again.

[Pete9008]

Just managed a quick test of this software, so far I’m impressed, no unwanted regen when lifting off, I’ve not tested any field weakening yet as generally I don’t exceed 5k rpm, had a quick play with MTPA parameters but not sure by how much I should be experimenting or what to expect, I need to get reading on mtpa

Depends on your motor. Run with it Mtpa off (lqminusld set to 0) to get a baseline then increase it by say 0.2mH at a time until you stop getting any improvement. I wouldn't go above 2mH though.

[Pete9008]

johu, any reason why you changed it from lqminusld to ldminuslq in the param file?

[johu]

Here is what I found:

id1 is with ldminuslq=5.8 mH and fluxLinkage=90 mWeber
id2 is with ldminuslq=5.8 mH and fluxLinkage=150 mWeber
id3 is with ldminuslq=1 mH and fluxLinkage=90 mWeber
id4 is with ldminuslq=1 mH and fluxLinkage=150 mWeber

So the greater ldminuslq the higher the reluctance torque ratio and the higher the d-current component. The higher the fluxLinkage the lower the reluctance torque ratio and the lower the d-current. Spread sheet attached if you want to have a play.

Ideally you'd actually find out these values for your motor and enter them. Less ideally you just play with just one of them and see what is performing best. catphish would love this

johu, any reason why you changed it from lqminusld to ldminuslq in the param file?

In the formula I found in the "old motors new tricks" video that's what it said. But now I realized here https://www.mathworks.com/help/mcb/ref/ ... rence.html it's the way around that you did it. Will change back.

[SciroccoEV]

Following this with anticipation. I'm going to need the full 9000rpm from the EM61 (or preferably 10,000+) in the Excel with single reduction ratio.

[Pete9008]

Found the cause of the dip, if margin is too small it runs out of Utotal while adding Ud so has to back off Uq, increasing margin to 2500 just gets rid of it to give this:

[Pete9008]

Been wondering about self tuning, I think it should be possible for the inverter to measure Lq and Ld, flux linkage and probably syncofs. Not sure it's worth it though - any thoughts?

[johu]

Some controllers already do this, I believe VESC and Lebowski have some characterization mode. This would be something you could test with your simulator, right?
Would probably do this in manual mode or something. So run once, remember the values, then never run that code again.

[Pete9008]

Some controllers already do this, I believe VESC and Lebowski have some characterization mode. This would be something you could test with your simulator, right?
Would probably do this in manual mode or something. So run once, remember the values, then never run that code again.

Was thinking maybe a separate build, it's not the kind of thing you want to accidentally run. Could it update the parameters in flash so that they could be picked up by the normal code when it was put back on?

Might be possible to do some of it on the simulator but it would be heavily dependant on motor characteristics (things like transmission backlash and rotor inertia in particular for Lq and Ld) which I don't have numbers for so it might have to wait till I have an inverter and motor set up.

[Pete9008]

BTW - I was still a little worried about the floats in the Mtpa calculation (the mantissa is only 23bit - less than the number of floating bits in the adjusted fixed point version) so I ran it against the fixed point version just to check.

For 1mH:

and 0.1mH

The float does a better job, especially at lower lqminusld values (rounding errors on the fixed point version), which is good

Also nice to see the same answer coming out of two different implementations!

[johu]

Cool, good to know!

Regarding autotuning just want to cross link to bexanders original post: viewtopic.php?p=28905#p28905

[Pete9008]

I'm going to need to make a few changes to the simulator for it to work with the new code (currently hacked to work). It would be nice if it could conditionally compile to suit the old and new versions. Is there a firmware version #define anywhere in stm32-sine that I could use to do this?

I have looked but can't find one.

[johu]

Was thinking maybe a separate build, it's not the kind of thing you want to accidentally run. Could it update the parameters in flash so that they could be picked up by the normal code when it was put back on?

Might be possible to do some of it on the simulator but it would be heavily dependant on motor characteristics (things like transmission backlash and rotor inertia in particular for Lq and Ld) which I don't have numbers for so it might have to wait till I have an inverter and motor set up.

Yes, that would be possible if parameter uids are kept identical.
Couldn't you simulate a locked rotor? The rotor naturally locks on the d-axis (I'm reading that smart document, that's how I know)

[Pete9008]

Cool, good to know!

Regarding autotuning just want to cross link to bexanders original post: viewtopic.php?p=28905#p28905

Good idea!

I'm thinking kind of along those lines for Lq and Ld but using rotor inertia to try to avoid having to lock the shaft in the correct positions. No idea whether it will work as there are a lot of factors that could prevent it.

[Pete9008]

Yes, that would be possible if parameter uids are kept identical.

Is there a firmware version number in the parameter file, or could one be added?

[Pete9008]

Couldn't you simulate a locked rotor? The rotor naturally locks on the d-axis (I'm reading that smart document, that's how I know)

What I'm thinking for Lq and Ld is to slowly rotate the rotor using a strong field with a superimposed high frequency signal and watch how the high frequency signal current changes with rotor position. Maximums give Lq and minimums Ld (edit - or is it the other way round??).

Flux linkage just needs a measurement of BEMF and we effectively do that when coasting (accuracy isn't great as we don't have the true 3phase voltages but we can calculate them from the pwm values and Udc well enough for our needs).

Syncofs could be done at the same time as Lq and Ld (mins and max positions) or just by applying stationary fields to the windings and seeing where the rotor settles.

The Lq and Ld one is highly dependant on rotor inertia, pwm bandwidth, current measurement bandwidth, etc so might not be possible. If it is possible the inverter would need to run in a very different mode to get the measurement accuracy which is why a separate build would be better.

Edit - of course the other way is to have a routine that runs in the background on the standard inverter code. When enabled it makes small adjustments to the lqminusld value and watches for changes in performance. You find a long, straight, flat road (as in very flat!), engage cruise control, enable the routine and let it get on with it.

[Ev8]

Ohh interesting changing the mtpa d/q split towards the q has quietened down a lot of what I had assumed was a noisy rear diff. Also I am now seeing better performance than with the old software and high syncadv, talking of which I see in your simulation your running syncadv 0, I’m on 0.5 should I lower it? I did still experience a lift off regen at 5k rpm this morning but I have kp=96 ki=3000 as this seemed smoother with the old software, I will update to 100/2000 and see what difference it makes

[Pete9008]

Ohh interesting changing the mtpa d/q split towards the q has quietened down a lot of what I had assumed was a noisy rear diff. Also I am now seeing better performance than with the old software and high syncadv, talking of which I see in your simulation your running syncadv 0, I’m on 0.5 should I lower it? I did still experience a lift off regen at 5k rpm this morning but I have kp=96 ki=3000 as this seemed smoother with the old software, I will update to 100/2000 and see what difference it makes

Great news (well apart from the regen )

Are you running johu's latest code, what parameter values have you ended up with?

Anything below 1 in Syncadv should be fine. It depends a bit on what adc sampling scheme johu is using in his latest code and Im not sure which it is.

I think the old Mtpa algorithm was generating way too much Id and that was not helping power. Wondering if the noise was instability in the control loops causing motor torque to fluctuate rapidly.

I doubt a change to ki and kp will make much difference but worth a try, they need tuning to suit the inductance of each motor anyway (and the values in my simulation were guesses and probably on the high side for most motors). On the regen the fwki and kfwp for the field weakening will have most effect, I found fwkp in particular needed to be kept low now the loop is running in the 10ms loop. 1 (fwkp) and 20 (fwki) worked well in simulation.

[Pete9008]

Just figured out why you are losing power without syncadv!

Its not Mtpa its the rotor angle calculations. The way the code is at the moment syncadv it trying to do two jobs and not doing either properly.

If you run low syncadv you get the correct answer from the park/clarke for iq and id but then use the wrong angle value for the inverse transform andg get vq and vd wrong - better stability but poor power.

If you run high syncadv you get the wrong answer from park/clarke transform for iq and id so any vq and vd calculated from by the inverse transform them will be wrong whatever angle is used for the inverse transform.

What we need to do is calculate iq and id without syncadv but then use scynadv to recalculate the rotor angle before doing the inverse transforms for vq and vd. This will give us iq and id based on the rotor angle at the point of measurement and vq and vd for the projected rotor angle at the point where the new duty cycles are loaded into the timer and vq and vd actually come into effect. It should give us good stability AND good power.

Syncadv will then need to be set to the equivalent of 180us (the measured latency).

Does that make sense?


Edit - thinking about it my attempts to reduce latency have been trying to reduce the need to do the above, however, with the above the latency becomes less of an issue. I'd still like to see the TI observer article if anyone has a copy - pretty sure that tha it was aimed at compensating for latency too.

Edit2 - just tried to simulate this using the standard firmware in the model and it's not showing the torque increase I was expecting which is a little surprising. Will be interested to hear whether it makes a difference on a real motor as there is either a problem with my understanding or a bug in the simulator.

Edit3 - It's my understanding! The actual value calculated for Vd and Vq really isn't that important, it doesn't actually mean anything, it's just the output of the control loops, what matters is the id/iq being right. The loops themselves compensate to a degree for the angle error meaning that the recalculation of the angle prior to the inverse transform is less important than I thought it was. Adding the recalculation will help slightly with stability as it makes life slightly easier for the control loops (and I do see this in the simulation) so it is still worth doing.

Hopefully fixing the Mtpa will help with power- the original one does seem to ask for an awful lot of unneeded Id which does reduce the iq available so it should help. Simulations show around a 10% improvement in torque just by turning Mtpa off!

It's been bugging me why the above didn't work as expected so I decided to have another look. I think the following three plots sum it up:

No angle recalculation:

With angle recalculation (equivalent to a SyncAdv of 12):

With angle recalculation (equivalent to a SyncAdv of 20):

Note that the SyncAdv field shown in the plots has been repurposes for sync compensation.

It's fairly clear that the angle recalculation has very little effect on performance, the acceleration being virtually identical across the three plots. What it does do is improve loop stability. In the plot without compensation the control loops lose it around 835Hz (9.9krpm on a 5pole motor) producing very strong regen (4-5 times as strong as the max acceleration!). Using a sync compensation value of 12 still gives the strong regen but at 14krpm (45% increase). Increasing sync compensation to a value of 20 keeps the control loops stable for the entire simulation period (the max speed is equivalent to 17krpm on a 5pole motor!). The value of 20 will actually allow the motor to run up to 30k, it does get a bit unstable above 20k but never produces strong regen.

So sync compensation could be worth it depending on the motor and what speed it needs to be driven up to.

EDIT - Note all the above is straight acceleration, no lifting off the throttle! This is just the loops losing control and getting strong unwanted regen purely due to increasing speed while accelerating.

EDIT - just had a play with the above and its effect on unwanted regen when lifting off on the throttle - basically it provides a slight improvement but nothing that really makes a difference. Limiting the rate of throttle change does help a bit but the further you push into the field weakening region the less effective it is, by the time you get up to 10k even very slow throttle removal (seconds) isn't enough to keep things stable. The problem is that this is also a snap effect, it's fine at one speed but you go a bit faster and it goes into full regen the moment you come off the throttle. To get up to 10kprm type speeds I think we're going to have to look again at reducing the measurement to output latency.

[Ev8]

Yes latest code he posted up
Currently 1mH and 150mWeber

[Pete9008]

Yes latest code he posted up
Currently 1mH and 150mWeber

The binary or the source code?

[Ev8]

Binary, unfortunately I’ve not got myself up to speed with compiling, audiuno ide is my limit!

[Pete9008]

Just had another look at the firmware - I hadn't realised that timer3 is dedicated purely to the resolver interface, that opens up quite a few mechanisms for reducing latency that I hadn't previously considered.

If we slave timer3 to timer1 (the pwm timer) and synchronise to the update event. Ttimer3 will then run at 8.8kHz locked to timer1, we can then use one timer3 capture/compare channel in toggle output mode to generate the 4.4kHz resolver waveform but align it so that the resolver sample point is optimally aligned for reducing latency. Another capture/compare channel is then used to generate the injected ADC trigger at this point. This would get latency down to around 113us. A third capture/compare could be used to trigger PwmGeneration::Run() to offset it later into the pwm period to further reduce latency, with this we could get the latency down to the Run() execution time. With johu's recent restructuring of iut this could be down to 20-30us which should be enough to fix all the loop stability issues and prevent the unwanted regen under all conditions.

[Pete9008]

Binary, unfortunately I’ve not got myself up to speed with compiling, audiuno ide is my limit!

OK, in that case I'd hold off adjusting the PI gains for now as the ones I posted are only relevant to his latest source code on github.

Compiling for the STM is pretty easy on linux, haven't tried it on windows though. See here for details on setting it up if you're interested viewtopic.php?p=44826#p44826, compiling just needs the first couple of steps in the install section, all the rest is for setting up the debugger.

Edit - The code you are running also hasn't got all the regen fixes in yet so it's not surprising you are still getting it.