IPM Motor Simulation and FOC Software

[Pete9008]

Have you thought about the critical point of the high inductance motors?

See edit4 above

Yes, things are starting to repeat, celeron55 called this "characteristic current" search.php?keywords=characteristic&t=1683&sf=msgonly

So for the Prius motor that would be way less, if I remember 90mW and 2 mH, so 45A only!

Also for the first time I see syncadv in a paper:

grafik.png

Look in the upper right corner

I seem to recall seeing some posts on this before but didn't understand it well enough for it to mean anything. Now it all sudenly makes sense!

Hoping the allergy season is over and my brain is finally starting to work properly again!

Edit - nice to see synadv starting to appear in papers, knew someone had to be doing it.

Edit2 - I think @LeonB had it spot on in that post you referenced!

[johu]

I am allergic to greek symbols, so season all year

So assuming 45A is the characteristic current aka critical current of the Prius motor, does it mean FW current must not exceed 45A? Anything above is useless or even counter productive?

[Pete9008]

I am allergic to greek symbols, so season all year

So assuming 45A is the characteristic current aka critical current of the Prius motor, does it mean FW current must not exceed 45A? Anything above is useless or even counter productive?

Downside is once the allergies subside Ill be well enough to do DIY so software and simulation work will slow down (although its already fairly slow due to brain fade)!

I think the Mtpa curve should still be right as some Id is there for torque production. Its more when you start using FW or limiting that it matters.

Edit - sorry you were asking specifically about FW, this is why I was going to simulate a higher inductance motor before trying anything. Also a little suspicious about 45A for the Prius, wondering if we have the flux linkage value right for it?

Edit2 - need to add the import for logged data and parameter calculation to the simulator, getting a bit tired of making assumptions based on guessed values

Edit3 - thinking a little more in the critical current = 45A case Im guessing that Mtpa should never ask for more than 45A (need to do some sums to check) so FW should always start from less than that value and should never need to go above it (although a safety check in the code would be sensible but only if we have good flux linkage and inductance data). The most critical bit is that the throttle limit trajectory must not take it past as that could produce some very odd effects.

Edit4 - but that doesn't make sense based on the typical values Mtpa gives, need to simulate it. Still a bit suspicious about the 45A though!

[Pete9008]

Just clicked, torque production and bemf are two different things. I think field weakening only affects the field seen by the winding (and so the bemf) not what is seen by the rotor (and so torque), Id above critical can still contribute to torque. The difference is that if Mtpa leads to Id above the critical current then the FW stage (zone3) in the diagram is missed and it should go straight to throttle limiting. So yes, there needs to be a test to ensure that FW does not increase Id further than specified by Mtpa id above critical current.

Still not convinced whether real motor values would ever allow this scenario in real life though?

[Pete9008]

Just tried a high inductance motor (3mH and 5mH) in the simulator and so far I can't get it to spin past 60Hz with any kind of torque.

Looking for bugs in my code (and my understanding)!

Edit - the problem seems to be the wLqIq term in the Vd equation. For example with Iq at just 100A and Lq at 5mH a speed of 60Hz gives a Vd of 188V. This is enough to take up pretty much all the battery voltage and leave very little Vq to drive torque producing Iq. Reducing the torque demand reduces Iq which reduces Vd which allows more Vq and more speed. Looks like this may trying to operate outside the voltage limit elipse before we even get to field weakening?

Edit2 - OK, this isn't going to work without the throttle limiting. Essentially the PWM amplitude limit is being hit, FW tries to come in but because the limit is due to hitting the voltage limit elipse not not the current limit circle it can't do anything and just makes matters worse. We need to add the test for voltage or current limit (not sure yet if this is the same as Id above or below critical current) and then either move to FW or throttle limiting dependant on the result.

Based on simulation results so far I can see why running high inductance motors has been disappointing.

[johu]

I have removed the voltage based limiter and replaced it with this:

Code: Select all

s32fp limitedIq = fp_sqrt(iMaxSquared - idRefTotal * idRefTotal);
s32fp iqMtpaAbs = ABS(iqMtpa);
limitedIq = SIGN(iqMtpa) * MIN(limitedIq, iqMtpaAbs);
qController.SetRef(limitedIq);

So now sqrt(iqRef² + (idMtpa + ifw)²) can never exceed 100*throtcur
I also introduced parameter fwcurmax the lets you set the maximum FW current

Will push shortly, haven't tested it on any car though

[Pete9008]

I've done this:

Code: Select all

         s32fp ifw = fwController.RunFW(Param::GetInt(Param::amp), idMtpa);

         int32_t vLimit = voltageLimitController.Run(Param::GetInt(Param::amp));

         s32fp limIqRef = (iqRef * vLimit)/256;
         s32fp limIdRef = ((ifw - idCrit) * vLimit)/256 + idCrit;

         qController.SetRef(limIqRef);
         dController.SetRef(limIdRef);
         Param::SetFixed(Param::ifw, ifw);

About to test

Edit - the limiting is done within the controller, minY is iCrit but idMtpa can still push it lower. Should avoid discontinuities when coming on off throttle.

Edit2 - iCrit is calculated from Ld (which is now a parameter) and flux linkage

Edit3 - Not quite right yet, need to play with FW controller a bit more!

[Bigpie]

I have removed the voltage based limiter and replaced it with this:

Code: Select all

s32fp limitedIq = fp_sqrt(iMaxSquared - idRefTotal * idRefTotal);
s32fp iqMtpaAbs = ABS(iqMtpa);
limitedIq = SIGN(iqMtpa) * MIN(limitedIq, iqMtpaAbs);
qController.SetRef(limitedIq);

So now sqrt(iqRef² + (idMtpa + ifw)²) can never exceed 100*throtcur
I also introduced parameter fwcurmax the lets you set the maximum FW current

Will push shortly, haven't tested it on any car though

is the PWM overflow merged in too?

[Pete9008]

It's only working !!

Need to add a couple of parameters to make tuning the gains easier but it has gone from useless to not half bad. I'll add the parameters, tune it a little and get some plots up.

[johu]

is the PWM overflow merged in too?

I must have missed that, where is it?

[Romale]

I also introduced parameter fwcurmax the lets you set the maximum FW current

Will push shortly, haven't tested it on any car though

this is great news! I will definitely try it one of these days.

[Pete9008]

May have jumped the gun slightly with the last post, it's working but when compared side by side the differences are subtle.

Worth mentioning that I've dropped the current down to 100A for these as with yesterdays code odd things seemed to happen at higher currents (unfortunately didn't grab a plot).

First yesterdays code (latest OpenInverter build but with the old limiter disabled):

Bit of instability at the end but ok until you realise that the Id and Id currents are wandering all over the place and when the controller tries to add Ifw Id actually reduces!

Next with the new code that prevents Ifw above the critical current (higher Id due to Mtpa is still allowed) and a limiter that drives the operating point towards the critical current point if the amplitude gets too big:

Better but not perfect. Id is now pretty well controlled by Iq isn't. What is really interesting is that the limiter has actually tried to reduce the throttle to 0 (Ifw shows the throttle reduction in these plots, 256=full throttle, 0=no throttle at all). The reason for this is that Vq isn't allowed to go negative in the standard code.

Last plot with Vq allowed to go negative:

Now there is some oscillation appearing in the limiter at higher speeds but apart from that it looks pretty good, both Iq and Id are well controlled and at sensible values. Acceleration isn't bad and the PWM amplitudes are kept under control. The throttle limiter is also doing sensible things.

Now the problem - I don't know why Vq is limited to stay positive. I'm sure there is a good reason but want to fully understand it before even thinking of allowing it to go negative in real code!

[Pete9008]

I must have missed that, where is it?

See viewtopic.php?p=47101#p47101, should be able to pull it from the logger repo.

[johu]

Now the problem - I don't know why Vq is limited to stay positive. I'm sure there is a good reason but want to fully understand it before even thinking of allowing it to go negative in real code!

Yes been at that point with the Prius A2 at some stage, thought it would be fixed by introducing inverse transform syncadv again.

The reason it is limited to positive or negative values was low speed stuttering. When going really slow it would change signs and that produced pretty disturbing stuttering. Limiting the sign fixed that. At some cost apparently...

[Pete9008]

Yes been at that point with the Prius A2 at some stage, thought it would be fixed by introducing inverse transform syncadv again.

You've lost me there?

The reason it is limited to positive or negative values was low speed stuttering. When going really slow it would change signs and that produced pretty disturbing stuttering. Limiting the sign fixed that. At some cost apparently...

OK, so letting it go negative is worth considering then. Was the stuttering on a Prius Gen2 inverter - could it have been the overly intelligent drivers?

Edit - It's a fairly major change though, need to sort the stability and then run though both the low inductance and high inductance tests just to make sure nothing strange shows up.

Still pretty disappointed by the speeds possible with the high inductance values in simulation, not convinced they are realistic. How would you rate the acceleration on the A2? What kind of 0-60mph do you think you were getting?

[johu]

See viewtopic.php?p=47101#p47101, should be able to pull it from the logger repo.

Ouch, did this really go unnoticed for all that time? It's pretty standard for high amplitudes to be mapped to "full on" for 1/3 of the period. But makes sense, FP_FROMINT(2) in FOC context is equivalent to 2 << 15 = 1 << 16 = 65536. In int16 that is 0.

You've lost me there?

I found the A2 was self accelerating because uq wasn't allowed to change sign. I thought the need for it to change sign was an artifact of missing syncadv.

OK, so letting it go negative is worth considering then. Was the stuttering on a Prius Gen2 inverter - could it have been the overly intelligent drivers?

no, that was with the Leaf inverter

[Pete9008]

Ouch, did this really go unnoticed for all that time? It's pretty standard for high amplitudes to be mapped to "full on" for 1/3 of the period. But makes sense, FP_FROMINT(2) in FOC context is equivalent to 2 << 15 = 1 << 16 = 65536. In int16 that is 0.

Think it's safe to assume it might have been causing some of the nuisance trips!

I found the A2 was self accelerating because uq wasn't allowed to change sign. I thought the need for it to change sign was an artifact of missing syncadv.

Got you. It's good that you have seen the effect on the A2, gives me a bit more confidence in the simulation.

Edit - I think what actually happens is that the Id generates Vq and then the Vq can generate Iq (unless the inverter is able to stop it by forcing Vq negative).

no, that was with the Leaf inverter

Shame, will have to find a different fix then.

[johu]

Yeah, many things need revisiting these days

overflow fix attached

[Romale]

I have removed the voltage based limiter
...

I checked several times. now there is something strange with the pinswap field

[johu]

what does it display with a known good version? By itself it doesn't look wrong, I have the same value in my Gen2

[Romale]

what does it display with a known good version? By itself it doesn't look wrong, I have the same value in my Gen2

this field cannot be configured right now. in obviously working firmware versions, this is a field with pop-up options for selecting settings.

[Romale]

very strange, but only when I flashed the old firmware version, downloaded and applied the old settings file, and then updated it again to this latest firmware, only then the pinswap field returned to normal! probably this is a bug of updating via WiFi.

[johu]

It's a known bug. When there is an enum field but its value doesn't match any of the enum values it is considered a flag field that cannot be edited because I was too lazy to implement a flag editor. If just one pinswap is selected it seems to be a normal enum. Not sure why it would behave differently between software versions

[Romale]

It's a known bug.

Oh! this is important information.
I think it should be added to the wiki. Thank you for your clarifications.

[johu]

Ouch, did this really go unnoticed for all that time? It's pretty standard for high amplitudes to be mapped to "full on" for 1/3 of the period. But makes sense, FP_FROMINT(2) in FOC context is equivalent to 2 << 15 = 1 << 16 = 65536. In int16 that is 0.

Just thought this over again. The dutycycles array in FOC is 32 bits. So no overflow there. In pwmgeneration the 32-bit value is shifted for using in the timer hardware. So now 65536 will become, say 4096 which is also the wrap around value programmed in TimerSetup(). In fact any value above the wrap value will just map to full-on. That's why this hasn't really caused any issues.

So this "overflow" presents a problem to the logger but not to the timer hardware. In fact I'm thinking the "fix" might be counterproductive as it shortly turns off the PWM signal.