IPM Motor Simulation and FOC Software

[johu]

It's an irrelevant value for the Gen2 Prius because there is no comparator. The Prius inverter just shuts off when it pleases

[Romale]

It's an irrelevant value for the Gen2 Prius because there is no comparator. The Prius inverter just shuts off when it pleases

but if I use a Toyota motor with a nissan inverter, then should I specify this value above?

[Pete9008]

Not sure, but I did observe the attenuation coming in a lot later on the actual motor. Increasing flux linkage makes it come in even earlier. Never tried values below 90 though.

Higher flux linkage = higher bemf = lower base freq. Think the values we are typically using are too big on low L motors and too small on low L. Basically the faster the motor is designed to spin, the smaller the flux linkage has to be. Need more data!

Well see here: viewtopic.php?p=47848#p47848
Code also on github (master)

Actually meant before and after simulator plots

[johu]

but if I use a Toyota motor with a nissan inverter, then should I specify this value above?

No, use a higher value like 400 or 500A

100A is meaningless, it is just the default.

[Romale]

Thank you )

[johu]

Higher flux linkage = higher bemf = lower base freq. Think the values we are typically using are too big on low L motors and too small on low L. Basically the faster the motor is designed to spin, the smaller the flux linkage has to be. Need more data!

Actually meant before and after simulator plots

Ok, understood so maybe it's just 50 mWeber or something.

More plotting hopefully tomorrow

[Pete9008]

Ok, understood so maybe it's just 50 mWeber or something.

More plotting hopefully tomorrow

Now that syncadv is sorted and uq and ud are representative you can measure it fairly easily. This is the equation:

vq.png (3.01 KiB) Viewed 1398 times

If you are coasting below base freq (Iq and Id are zero) the only term remaining in the above is the last one (the bemf). So measure vq, divide by 2xPIx(electrical motor speed) and you should have the flux linkage

Edit - but only trust the measurements if vd is zero, as well as iq and id, while coasting. If it isn't there is still a sync offset somewhere.

[Ev8]

Took johu’s latest bin for a spin early this morning, I didn’t get to play much, first impressions are it is very smooth, but at least 30kw down on the tune I was running (hopefully this can be adjusted with some playing), motors make a little movement and then stop when you power the inverter, and also inverter makes an audible hum at around the time it feels like the limiter comes in. Rolled back to a previous build to drive to work, I might get time to play with it properly one evening this week

[johu]

ok cool. You might need to up fwcurmax a bit.
Also found the filter isn't initialized right, that gives the little twitch when starting

[Ev8]

Cool

[johu]

Tried the firmware on Touran and there it was a disappointment. Sluggish above 4000 rpm and even tripped out at 7000 rpm when going into regen.

[Ev8]

Sorry to hear that things were looking positive.

[johu]

Yes, best yet for Prius motor, at least in terms of stability. But for Leaf motor not so great. I think the Leaf motor doesn't want its MTPA D-current reduced. The software I published earlier that worked great in Touran didn't reduce D current at all. It took whatever was larger, field weakening or MTPA.

[Ev8]

Seems a one software for all solution isn’t easy…

Pete

Higher flux linkage = higher bemf = lower base freq. Think the values we are typically using are too big on low L motors and too small on low L. Basically the faster the motor is designed to spin, the smaller the flux linkage has to be. Need more data!

Does this mean the flux linkage value we set directly alters the base frequency or the base frequency is what it is regardless but we need to match our value to that base frequency for best performance

Hopefully that makes sense

[Pete9008]

Seems a one software for all solution isn’t easy…

It should be possible, I know its only simulation but with the right setup my experimental code works better on both low and high L motors than any other build I've tested. It does need the critical current set right though as it uses that to decide whether to increase or decrease Id in field weakening (low L motors need more -Id and high L motors need less (edit - well sometimes, on high L also depends on Mtpa and load)).

Does this mean the flux linkage value we set directly alters the base frequency or the base frequency is what it is regardless but we need to match our value to that base frequency for best performance

The later. A motor designer has to choose between torque or speed (for a given voltage) when choosing the geometry and winding configuration, this choice then largely determines the inductance and flux linkage for the motor. We need to setup the controller to match these values.

If we set them up wrong we lose either performance, controllability or efficiency

[Ev8]

Ok that makes sense I upped flux-linkage to 200 on mg2 and things just felt better

[Bigpie]

My front motor goes from 0.1mH to 0.3mH

[Pete9008]

Wow, these numbers are really coming in a bit lower than I expected! That's virtually the same as my Outlander rear.

With values that low it really would make a lot of sense to move to current sampling synchronised with the PWM. If I ported Johannes adc2 changes to the logging OI build would you be ok to give it a try? @johu - is the adc2 code ready to use?

With the existing sampling point it will be heavily under reading, particularly on Id (lower inductance).

[Bigpie]

Of course. Keeping the front outlander motor in now for sure, doing the pullup resistors on my esp32 today.

[johu]

With values that low it really would make a lot of sense to move to current sampling synchronised with the PWM. If I ported Johannes adc2 changes to the logging OI build would you be ok to give it a try? @johu - is the adc2 code ready to use?

Yes I ran that on Audi

No noticeable difference though.

EDIT: wouldn't use dir=Encoder::GetRotorDirection(); though

[Pete9008]

Been thinking about PWM and current ripple and have come to the conclusion that I have been missing something fairly fundamental!

With low inductance currents we have calculated that the ripple currents will be more than 100A. I now don't think this is corrent right and it brings both good and bad news.

Think about the way PWM works. When we want no voltage on the motor we output 50% pwm on all three phases, now this means that al three phase terminals are spending half their time a 0V and half at the DC bus voltage but because they all do it together there is no net voltage across any phase. As we start to move away from zero motor volts on phase pwm goes up, say to 55%, and the other two go down to say 45% (not quite true but just to keep it simple). Now this means for 90% of the time the phase terminals still see the same voltage (as they are all still at either at 0 or DC bus) but for 10% of the time there is the full bus voltage appearing across the windings. Now we use centre aligned PWM, this means that the 10% is actually split into two, one bit at each end of the PWM pulse. This means that for most of the time the current modulation frequency seen by the motor is actually TWICE the pwm frequency.

Now the good news - this halves the ripple current which makes a lot of sense in explaining how low inductance motors seem to work so well in real life. 100A ripple becomes just 50A.

And the bad news - this fundamentally changes the best way to do current sampling!

The bad news probably also explains why the late angle fix made things worse, why using adc2 made things worse and why using a median on multipe adc results seems to work so well - so maybe it is actually good news

Need to think about the implications of this a bit more but it is definitely going to change some things!

Apologies if this is one of those things that is already well known, understood and taken for granted but I've only just figured it out

[johu]

Never really thought about it!
So then eventually we could even go back to full period sampling. Maybe this can be further stabilized by using ADC2 for the phase currents only. But since it shares one DMA channel with ADC1 we have to see whether this actually works.

[johu]

Touran is back on its feet and I took it for a spin with the new main board. It's probably a placebo but I found the motor ran quieter. Current sensor gains are 2.3 digits/A instead of 1.75 so maybe that helps ripple a bit.

I ran it with the "angle fix" i.e. FOC updated with recent angle before doing the transform and it seemed to make no difference.

[Ev8]

Ok so I’ve just worked out how to compile a build for myself, took a while to get there as it turns out getting the tool chain isn’t as simple as it once was! A good step by step guide can be found here though which might be worth adding to the read me for us idiots out here! https://lindevs.com/install-arm-gnu-to ... -on-ubuntu

Anyway as build for my own use while over more intelligent people people do real dev I’d like to build a version of what I’m running now which is 5.20 with syncadv added in that Pete built for me, but I’d like to add in some of the recently added in fixes, in particular the pwm overflow fix, as I seem to be having cut outs on mg1 that don’t necessarily tie in with the max current it’s delivering.

I’m still learning about git hub and looking back though file histories, so I might have issues finding bits, is there a simple way to find the version of the included files for a particular build?

[Pete9008]

I think most of the fixes are now in Johannes github version (including the latest pwm overflow, mtpa and the syncadv change) so probably worth giving that a try. The build I did for you was before I started using git so unfortunately it isn't on there but if you need it I can dig it out and send it over.