IPM Motor Simulation and FOC Software

[Pete9008]

Might have just clicked, the plots show what the controller thinks is the Uq and Ud, not what is actually being seen by the motor. I think this is the sync compensation issue that I was on about the other day. The controller uses the old angle to calculate Uq and Ud, the motor sees this 113us later (when the timer is reloaded) by which point the rotor angle has changed. The amount by which it has changed goes up with motor speed so the effect gets worse with speed. This will effectively shift current/voltage between q and d as seen by the motor/controller.

I think if the angle is recalculated (using an advance value of around 12) just before calling the inverse Parke/Clarke the shape of the logged plots will change considerably and better match the simulation.

Edit - and here are two plots modelling the effect. No compensation, voltages as seen by controller:

You can see there is a strong frequency dependant Ud component

And with compensation:

The Ud component is much flatter, not perfect but then the compensation is unlikely to be prefect either.

Think I'm happy with the model again but am more convinced than before that either reduced latency (preferable) or sync compensation would provide benefits.

Edit2 - this makes me wonder whether there are two sets of ki/kp that work. One that uses kp to do most of the work and one that uses ki. Will try it when (at some point in the dim and distant future!) I have some hardware to try things on.

[Ev8]

Thanks, I wish I was able to help more but this is just over my head, for now all I can do is test and play with tuning

[Pete9008]

Wondering if I've bitten off more that I can chew too!

Thanks for trying it - but please be careful! I still think there is enough instability to have some quite nasty regen if the motor speeds are pushed too far into field weakening at the moment (and I don't have a feel for how far too far is, it might be 10k in which case it's not an issues but it might be a fair bit lower).

I'm confident that johu's new code is going to help though.

[celeron55]

Not that I understand even half of this, but now it's again sounding like something that mirrors what I found when playing with syncadv on the MGR.

Do you agree syncadv can be used to compensate some of this, but with the downside of reduced low speed torque? Because that's what I found to be the case.

[johu]

Well then here is something for you to test. Best run yet
Parameters
curkp 50
curki 35000
curkifrqgain 0
fwkp 5
fwki 50
fwmargin 4500
syncofs 1000
syncadv 0.5
ldminuslq 1
fluxlinkage 90

Still somewhat shaky but drivable, no unwanted regen, no trips.
I have increased S&H time to 7.5 clocks again because I was seeing like 70A spikes in il1/il2! They were gone then.
Next I found that increasing curki improves stability. It is now at 35000 for my Leaf motor. So a good deal of shakiness is now gone, I think with a bit more tuning it could be eliminated. Throttle reacts a bit weird once entering field weakening, you suddenly get more acceleration but you can always compensate that by coming off throttle. It never accelerates on its own. I think that can be tuned out as well. I didn't have the patience now.

[johu]

Logic would say it must oppose Uq to reduce torque so again in phase with Uq?

Logic would say that the back emf should peak at the maximum rate of change of flux which is the quadrature component so again Uq?

Yet in the logged plots there is a clear speed dependant component in Ud and not in Uq - or am I misreading the logged plots somehow?

Maybe this is helpful. I was regenning downhill and briefly blipped throttle. In reaction, besides FW building up, ud becomes more negative while uq becomes less positive.
In steady state with regen uq is 30000 and ud -10000

[Pete9008]

Not that I understand even half of this, but now it's again sounding like something that mirrors what I found when playing with syncadv on the MGR.

Do you agree syncadv can be used to compensate some of this, but with the downside of reduced low speed torque? Because that's what I found to be the case.

It's vary hard to predict the effect that syncadv has (I'm still guessing most of the time which is why it worries me when I lose confidence in the simulator). This is partly as the impact of syncadv changes with speed and partly because errors in it cause requested Id at the controller to be seen as Iq by the motor and vice versa. Combined these can have all sorts of odd effects. When you combine that with field weakening, Mtpa, measurement noise, etc, there are lots and lots and lots of ways for it to go wrong.

I would agree that if you use the adjustments like syncadv to optimise for one area it is highly likely to adversely affect performance somewhere else.

Well then here is something for you to test. Best run yet
Parameters
curkp 50
curki 35000
curkifrqgain 0
fwkp 5
fwki 50
fwmargin 4500
syncofs 1000
syncadv 0.5
ldminuslq 1
fluxlinkage 90

Still somewhat shaky but drivable, no unwanted regen, no trips.
I have increased S&H time to 7.5 clocks again because I was seeing like 70A spikes in il1/il2! They were gone then.
Next I found that increasing curki improves stability. It is now at 35000 for my Leaf motor. So a good deal of shakiness is now gone, I think with a bit more tuning it could be eliminated. Throttle reacts a bit weird once entering field weakening, you suddenly get more acceleration but you can always compensate that by coming off throttle. It never accelerates on its own. I think that can be tuned out as well. I didn't have the patience now.

That's looking good Not too keen on the way that Ifw comes in in lumps and then is pulled out too much at a time though. I'll put it into the simulator now to see what it looks like.

Any chance that you could try a couple of things?

First a mod to repurpose syncadv temporarily to see whether sync compensation does have the effect of the logged data that I'm hoping for

Code: Select all

in foc.c
void FOC::SetAngle(uint16_t angle, uint16_t syncadv)
{
   sin = SineCore::Sine(angle + syncadv);
   cos = SineCore::Cosine(angle + syncadv);
}

inpwmgeneration-foc.c
at the top
      CalcNextAngleSync(dir);
      FOC::SetAngle(angle, 0);
      
and lower down
      s32fp syncadv = FP_MUL(frqFiltered, Param::Get(Param::syncadv));
      syncadv = MAX(0, syncadv);
      FOC::SetAngle(angle, FP_TOINT(dir * syncadv));

      FOC::InvParkClarke(ud, uq);

A syncadv value of 12 should then compensate for the pwm timer loading delay.

And second a custom PI controller for the field weakening (I know the coding is a bit hacky but just as a test):

Code: Select all

int32_t PiController::RunDebug(s32fp curVal)
{
   s32fp err = refVal - curVal;
   if(err > 100)
       err = 100;
   if(err < -2000)
       err = -2000;
   s32fp esumTemp = esum + err;

   if((kp != 0) || (ki != 0))
   {
       int32_t y = FP_TOINT(err * kp + (esumTemp / frequency) * ki);
       int32_t ylim = MAX(y, minY);
       ylim = MIN(ylim, maxY);

       if ((ylim == y) || (ABS(esumTemp) < ABS(esum)))
       {
          esum = esumTemp; //anti windup, only integrate when not saturated or if will reduce saturation
       }
       return ylim;
   }
   return minY;
}

EDIT2 - Just simulated this PI controller mod and it doesn't seem to give the benefit that I previously saw when using you ki and kps so probably not worth trying after all.


Thanks

EDIT - forgot - also need to disable the old syncadv functionality:

Code: Select all

      //Compensate rotor movement that happened between sampling and processing
      //syncOfs += FP_TOINT(dir * syncadv);

[Pete9008]

Maybe this is helpful. I was regenning downhill and briefly blipped throttle. In reaction, besides FW building up, ud becomes more negative while uq becomes less positive.
In steady state with regen uq is 30000 and ud -10000

The back emf is definitely in phase with Uq in that plot which makes sense, the Id, Iq, Ud and Ifm make sense too. The Uq is less obvious but I think that the increased -Id meant that the back emf dropped so a reduced Uq could actually drive current into the motor?

Edit - On thinking about it that is all doing exactly what you would expect

[Pete9008]

Well then here is something for you to test. Best run yet
Parameters
curkp 50
curki 35000
curkifrqgain 0
fwkp 5
fwki 50
fwmargin 4500
syncofs 1000
syncadv 0.5
ldminuslq 1
fluxlinkage 90

Still somewhat shaky but drivable, no unwanted regen, no trips.
I have increased S&H time to 7.5 clocks again because I was seeing like 70A spikes in il1/il2! They were gone then.
Next I found that increasing curki improves stability. It is now at 35000 for my Leaf motor. So a good deal of shakiness is now gone, I think with a bit more tuning it could be eliminated. Throttle reacts a bit weird once entering field weakening, you suddenly get more acceleration but you can always compensate that by coming off throttle. It never accelerates on its own. I think that can be tuned out as well. I didn't have the patience now.

Simulator output:

Zoomed in on the controller currents to see a bit more detail of Ifw:

And with the effect of -Id on the back emf tweaked (reduced from 0.3 to 0.1%/AId)

Not too bad a match. It seems that to simulate field weakening accurately we need a bit more data on how the flux linkage changes with Id. The leaf motor looks to be somewhere between 0.1 and 0.3.

[johu]

That last one looks very good! What exactly did you tweak there?

Also I noticed you let the simulation run to 900 Hz. The Leaf motor is only specd to 10500 rpm or so i.e. 700 Hz. Not sure I'd dare run it at that speed for now, but 8000 rpm would be nice.

[Pete9008]

That last one looks very good! What exactly did you tweak there?

Also I noticed you let the simulation run to 900 Hz. The Leaf motor is only specd to 10500 rpm or so i.e. 700 Hz. Not sure I'd dare run it at that speed for now, but 8000 rpm would be nice.

TBH I wouldn't dare go too far into the field weakening region at all yet. The model still shows strong regen just on acceleration (you can see it at around 900Hz in the above plots) or as soon as you aggressively come off the accelerator at even fairly modest frequencies in FW.

Don't read anything into the speeds, Ive just been running the simulations until it stops accelerating or control is lost. However, it does suggest the the inverter/firmware should be physically capable of running motors at high speeds if we can sort the stability/FW.

The tweak was to the strength of the back emf. Essentially how much the back emf is reduced for each amp of -Id. I've no idea what a sensible value is here which is why I'm interested in trying to reproduce actual logs to get a feel for what values are realistic.

[SciroccoEV]

The Leaf motor is only specd to 10500 rpm or so i.e. 700 Hz. Not sure I'd dare run it at that speed for now, but 8000 rpm would be nice.

People have run them well past stock. Someone did manage to seriously damage a motor when the rotor touched the casing but that rotor had exceeded 20,000rpm.

The 63kWh Leaf+ lists a top speed of 98mph, so unless they've changed the gearing, an online calculator equates that to about 11,000rpm (I've heard the inverter limit is 11,330).

[Pete9008]

Yes that's how I was taught also but it didn't work at all for this control problem. That's because a pure p-controller can never keep up with the increased voltage demand as the motor speeds up. I couldn't get the car to perform at all with low KI gains. No guide, as I arrived at them rather randomly by reading many papers...

Just thinking out loud here but is it possible that the windup bug in the PI controller could have had an impact on this? High ki and low kp values might have help mask this while low ki and high kp exaggerated it. When I started trying to tune gains I couldn't get it to work until the windup bug was fixed.

The simulator now suggests that both approaches work so is it worth revisiting it in the car to see if there is any improvement?

[johu]

Just thinking out loud here but is it possible that the windup bug in the PI controller could have had an impact on this? High ki and low kp values might have help mask this while low ki and high kp exaggerated it. When I started trying to tune gains I couldn't get it to work until the windup bug was fixed.

The simulator now suggests that both approaches work so is it worth revisiting it in the car to see if there is any improvement?

Search the forum for "cocain" for a bit of a history lesson In short: with low ki the motor didn't even perform at low revs.

I thought about ifw coming in in lumps. That must be because of the somewhat clumsy calculation:

Code: Select all

int32_t y = FP_TOINT(err * kp + (esumTemp / frequency) * ki);

More spelled out that means

Code: Select all

int32_t y = (err * 10 + (esumTemp / 8800) * 100) / 32;

So say we have an error of -1000 digits (PWM amplitude above setpoint). After 9 cycles esumTemp is high enough to make it through the integer division resulting in

Code: Select all

int32_t y = (-1000 * 10 + (-9000 / 8800) * 100) / 32 = -315

Later this is then treated as s32fp so every 9 cycles or every 1ms we'd add -1A of FW current. So it takes 100ms to arrive at -100A which might be too slow. But it means the "lumps" we are seeing are just a plot artifact - polling 10 values, plotting, polling next values. Takes a while.

So looking at this calculation maybe fwki should be raised.

[Bigpie]

Just out on a shopping trip but had logger running on my phone. High rpm wasnt an issue. Had a couple of cutouts.

Definitely more torque though. Was able to accelerate up hill in 2nd gear

[Pete9008]

Search the forum for "cocain" for a bit of a history lesson In short: with low ki the motor didn't even perform at low revs.

I thought about ifw coming in in lumps. That must be because of the somewhat clumsy calculation:

Code: Select all

int32_t y = FP_TOINT(err * kp + (esumTemp / frequency) * ki);

More spelled out that means

Code: Select all

int32_t y = (err * 10 + (esumTemp / 8800) * 100) / 32;

So say we have an error of -1000 digits (PWM amplitude above setpoint) for 1000 cycles (about 1/8 of a second). After 9 cycles esumTemp is high enough to make it through the integer division resulting in

Code: Select all

int32_t y = (-1000 * 10 + (-9000 / 8800) * 100) / 32 = -315

Later this is then treated as s32fp so every 9 cycles or every 1ms we'd add -1A of FW current. So it takes 100ms to arrive at -100A which might be too slow. But it means the "lumps" we are seeing are just a plot artifact - polling 10 values, plotting, polling next values. Takes a while.

So looking at this calculation maybe fwki should be raised.

Agree, I did have a look at that before finding the windup bug and tried doing the multiply first and then the divide to avoid it. Seemed to get overflows though so went back to standard as it seemed to work OK with the windup fixed. Sure it can be improved though.

Dont think the lumps are an artefact, I saw them in simulation too. I think they are due to the interaction between the loops, as fw is increased then iq/id finds it has a bit more headroom and adjusts which then affects fw and so on. I found slowing the fw changes gave the biggest improvement (hence the low kp/ki and above changes to limit the error signal and try to limit how quickly it can increase or decrease the output).

[Pete9008]

Just out on a shopping trip but had logger running on my phone. High rpm wasnt an issue. Had a couple of cutouts.

Definitely more torque though. Was able to accelerate up hill in 2nd gear

[johu]

Just out on a shopping trip but had logger running on my phone. High rpm wasnt an issue. Had a couple of cutouts.

Definitely more torque though. Was able to accelerate up hill in 2nd gear

Putting up to 400A total into the motor. FW didn't become active at all. What are fwkp, fwki and fwmargin set to? Was it cutting out on acceleration or liftoff?

[johu]

Dont think the lumps are an artefact, I saw them in simulation too. I think they are due to the interaction between the loops, as fw is increased then iq/id finds it has a bit more headroom and adjusts which then affects fw and so on. I found slowing the fw changes gave the biggest improvement (hence the low kp/ki and above changes to limit the error signal and try to limit how quickly it can increase or decrease the output).

Yes it is quite a multi feedback system Still need to find a way to bring in FW fast enough before amplitude maxes out but then keeping the gain low as you say.

[Pete9008]

Putting up to 400A total into the motor. FW didn't become active at all. What are fwkp, fwki and fwmargin set to? Was it cutting out on acceleration or liftoff?

Been wondering about this, is it possible that on some motors the -Id added by Mtpa is enough to do fw while on the accelerator? If so you would only see FW come in during coasting or deceleration above base frew and I don't see much of that in the plot. It would be interesting to see the Uq and Ud voltages on the plot too as that would show whether Ifw should have been added.

[Pete9008]

Yes it is quite a multi feedback system Still need to find a way to bring in FW fast enough before amplitude maxes out but then keeping the gain low as you say.

Does FW need to come in that fast? It should only need to come in as quicly as the motor can accelerate and that is very slow compared to Id and Iq. An amp per ms would probably be plenty!

[Pete9008]

Been thinking about where I'm personally at with this. The original goal was to enable me to make the decision on whether to stick with OpenInverter or move to the Outlander inverter. There were a number of issues that were bothering me, mainly the unwanted regen when coming off the throttle but also comments on disappointing performance on the Outlander and MGR motors.

I'm pretty confident now that johu's changes are going to sort these issues

Unfortunately while using the simulator I've become fairly convinced that there is still a control stability issue when pushing further into the FW region of motor speed. From what I've seen in simulation it's could also be a very rapid transition from working fine to strong unexpected regen and the further you push past base frequency the stronger the regen gets. I'm hoping I'm wrong here, that the simulator isn't accurately modelling things, that the instability isn't there and it all works fine at high speed, the trouble is the only way to tell is to accelerate to high speed in a car and if the problem is there, and exhibits itself at high speed, it could get nasty. While I'm willing to take a chance while I'm driving I need to be 100% confident when it's someone else.

So - the job for this weekend it to have another go at tweaking the code to reduce latency. If I can get that to work, and in a way that is unlikely to break anything else, I'll stick with the Prius inverter running OpenInverter code. If not then I'm going to move to an Outlander inverter running OEM code (and I'm really not keen on that option as it affects a whole load of other things on the car that I was hoping to do using features that only the Prius inverter has!)

[bobby_come_lately]

I was in the same position as you, and now have Outlander inverter and one of aot93's board's prepped. However...

Even without the beta build that Jamie posted yesterday, I'm now seeing decent performance from Gen 3 inverter and outlander rear, after some tweaks (phase wiring, setting syncofs properly). I have the beta build on there now and will do some testing tomorrow with luck.

Really appreciate your and Johu's work on this - if we can extract a bit more out (safely) then that would be amazing.

[Pete9008]

I was in the same position as you, and now have Outlander inverter and one of aot93's board's prepped. However...

Even without the beta build that Jamie posted yesterday, I'm now seeing decent performance from Gen 3 inverter and outlander rear, after some tweaks (phase wiring, setting syncofs properly). I have the beta build on there now and will do some testing tomorrow with luck.

Really appreciate your and Johu's work on this - if we can extract a bit more out (safely) then that would be amazing.

Thanks for your comments, appreciate it. The work is all Johu's though, getting OpenInverter to work is a major achievement! - I'm just messing about with the maths!

I'm hopeful that we can get is sorted. I'm just feeling a bit uneasy that with the mods to date it looks like it's going to be much easier to exploit the FW region of motors and if the issue I think is there, is actually there, that could lead to 'problems'.

[Bigpie]

Attaching latest log as a method of getting it off my phone.

Getting in bother for experimenting with the kids in the car.

Cut outs always on acceleration, I'd love to get the bottom of why it's cutting out, maybe overshooting? I can sometimes get my foot to the floor, others not so.
"fwkp": 1,
"fwki": 1,
"fwmargin": 2000,

If I wanted to graph from my log, would I be plotting the avg columns?

EDIT, Sorry wrong params attached. Updated

At 435 on the bottom axis looks to be where I had 3 coutouts in a row. The brown plot in the temperature from the inverter.