IPM Motor Simulation and FOC Software

[SciroccoEV]

Was about to order this but just checked and it would be coming from the USA - £33.58 delivery so think I'll leave it!

If I can find room to set up my book scanner, I'll scan some of the more interesting chapters.

[Pete9008]

If I can find room to set up my book scanner, I'll scan some of the more interesting chapters.

Thank you for the offer! The main thing that I'm interested in is the derivation of the IPM motor equations, in particular where the wLdId and wLqIq terms come from. If it has anything related to those then I would be very interested in seeing just those bits?

I think I know where they come from. We treat Ld and Lq as if they are separate, and they are for a stationary motor. The trouble is some of the flux that contributes to them is in the rotor and some in the stator. The bits in the rotor move with it so effectively stay with Ld or Lq as it rotates. The bits that are in the stator (the majority) don't move though so as the motor rotates the bits that were associated with Lq become part of Ld and vice versa. I think this is where those terms come from. What surprises me is that they are that simple, I would have expected something much more complicated, and so I'm keen to know whether the equations we are using are approximations of whether the maths really does does all cancel down to something that elegant?

[Pete9008]

Thought it would be usefull to capture my thoughts on future enhancements for the simulator while it's fresh in my mind. I'm unlikely to get to any of these for a little while but at least if they are posted here I'm less likely to forget about them.

In a vague order of implementation:

1. Logged data import and comparison - essentially allow the import of logged inverter data (ESP32 high speed log only). This would pop up another window which would allow a file to be selected, it would then run the logged motor voltage data through the motor model and correlate the results against the logged current data. Optionally it would allow a monte carlo style multiple run analysis to search for better matching motor parameters.
   Edit Feb23 - Done see viewtopic.php?t=3047
2. Motor Loss Modelling - At the moment the simulator reports motor shaft power. By also calculating electrical power going into the motor it would be possible to calculate and plot motor efficiency.
   Edit Feb23 - Done, included in latest github repo
3. Inverter Modelling - Desat - At the moment there is no current limiting in the model, infinite currents are allowed! It would be better to have a configurable threshold at which point a likely desat event is flagged and the simulation paused.
4. Inverter Modelling - Losses - At the moment the inverter is considered lossless. It would be possible to calculate the IGBT/diode voltage drops and IGBT switching losses and use these to reduce the DC bus voltage that is available to the motor. There is an accurate way and a simple way to do this. The accurate way is to break each control loop period down into the individual phase switching events and then run the motor model for each of these states. The simple way is to pro-rata the IGBT/diode voltage drops based on PWM value. The accurate way will give very good results but slow down the simulation. The simple way is likely to be 80-90% accurate and have no real impact on simulation speed. Not sure which way to go but probably the simple one. Either way switching losses would just be based on PWM frequency, configurable IGBT turn on/off times and estimates of average current decay profiles.
5. Battery Loss Modelling - Very simple approach, just allow the battery internal impedance to be entered and use this to calculate a voltage drop and power loss.

1. is mainly to see if we are using the right motor parameters.

2. 3. 4. and 5. are more to improve the realism of the simulation but also to allow the effect of different mtpa/mtpv schemes, particularly on efficiency, to be evaluated.

Really should also add some sanity checks on data entry fields and possibly allow changes to inverter parameters to be persisted across program restarts (rather than just reinitialising from the param_prj.h file each time - a button would also be needed to allow a manual refresh from the file though.

Any other ideas, or differing views on priorities, please let me know.

[johu]

Thumbs up on the above.

Got an early forum release for you

[johu]

Prius likes over modulation very much! Cranked up modmax to 44000 and went for a drive

So when we do (iq * uq + id * ud) / FOC::GetMaximumModulationIndex() we arrive at 43000*90/44000=88A DC (because uq=0) and that is pretty much what I saw on my power meter. So now I can maintain 30 kW across the constant power region.

I think on the next release I will made modmax a parameter that defaults to 2/sqrt(3)*32768 and can be increased up to... 45000 or so. Then by default over modulation is off and maybe brought in

[SciroccoEV]

Prius likes over modulation very much! Cranked up modmax to 44000 and went for a drive

How about going to six step?

[johu]

How about going to six step?

That's pretty much what it is. I reckon crank the amplitude up even higher, that's where you'd arrive. Don't know by how much though

EDIT: see waveform here https://openinverter.org/forum/viewtopi ... 638#p48638

[Ev8]

Hmm gen2 inverter likes over modulation, makes you wonder if thats the intelligent gate drives doing something interesting, it would be interesting to go full square wave on the inverter input and scope the output

[Bigpie]

Some way of simulating a syncoffs error would be nice to have, both for simulating the affect and potential for developing code to auto tune.

Edit, just noticed it's already a parameter

[Ev8]

I can confirm that the Prius gen2 inverter does indeed love a bit of over modulation… I’ve now seen for the first time over 300amps on the dc bus, (twin motors remember) however I did once trip mg1 inverter and instead of it restarting and resuming as normal when lifting off the pedal it restarted with the motor chattering which persisted even when stationary…this stoped after a proper key off restart

[Romale]

is this release useful only for Toyota motors with high inductance, or will the latest official firmware be better for Nissan too?

[johu]

It should squeeze more power from the Nissan also, but I haven't tested. For me Nissan is already powerful enough without it, I even don't max out the inverter (throtcur could be 6.5 but I set it to 5.5)

[Bigpie]

What sort of figures are high inductance vs low inductance? I'd assume my motor (0.1mH to 0.3mH) is low inductance?

[johu]

I guess it's a pretty arbitrary classification and practically also linked to flux linkage. I'd say a motor whos base speed is below 150 Hz or so needs strong field weakening more than a motor whos base speed is above that.

[Bigpie]

Trying to build with the 5.24R but struggling:

Code: Select all

/Users/jamiejones/open-inverter/IPMMotorSim/build-IPMMotorSim-Qt_6_3_2_for_macOS-Debug/pwmgeneration.o:-1: error: Undefined symbols for architecture x86_64:
  "PwmGeneration::slipIncr", referenced from:
   PwmGeneration::SetFslip(int) in pwmgeneration.o
   PwmGeneration::CalcNextAngleAsync(int) in pwmgeneration.o
   PwmGeneration::CalcNextAngleConstant(int) in pwmgeneration.o

any ideas? Tried different QtKits but I'm not vary familiar with Qt. pwmgeneration.cpp does contain them definitions.

[Romale]

...needs strong field weakening more...

in firmware 5.20, it was intuitively clear how to disable the weakening completely and it worked. in new firmware, to completely disable, fwcurmax you need to put -1000 or 0

[johu]

Trying to build with the 5.24R but struggling:

Code: Select all

/Users/jamiejones/open-inverter/IPMMotorSim/build-IPMMotorSim-Qt_6_3_2_for_macOS-Debug/pwmgeneration.o:-1: error: Undefined symbols for architecture x86_64:
  "PwmGeneration::slipIncr", referenced from:
   PwmGeneration::SetFslip(int) in pwmgeneration.o
   PwmGeneration::CalcNextAngleAsync(int) in pwmgeneration.o
   PwmGeneration::CalcNextAngleConstant(int) in pwmgeneration.o

any ideas? Tried different QtKits but I'm not vary familiar with Qt. pwmgeneration.cpp does contain them definitions.

Almost seems like a CONTROL=FOC directive missing somewhere.
EDIT: no, it's probably because it's a debug build it doesn't dismiss unused functions. May nee to copy the definition of uint16_t PwmGeneration::slipIncr; from pwmgeneration-sine.cpp to pwmgeneration.cpp

in firmware 5.20, it was intuitively clear how to disable the weakening completely and it worked. in new firmware, to completely disable, fwcurmax you need to put -1000 or 0

-1000 to disable? nooooo. 0 it is

[Bigpie]

Looks to be already there.

[johu]

That's just the declaration, doesn't allocate memory

[Bigpie]

Code: Select all

uint16_t PwmGeneration::slipIncr;

In pwmgeneration-foc.cpp, as you said

[johu]

Forked IPMMotorSim https://github.com/jsphuebner/IPMMotorSim

It fixes above issue and also links in the matching firmware version as a submodule

Pull request created also

[Ev8]

At risk of exposing myself as the dummy I am could someone give me a step by step guide to building the simulator?

Obviously I start with GIT clone ……

[Pete9008]

Forked IPMMotorSim https://github.com/jsphuebner/IPMMotorSim

It fixes above issue and also links in the matching firmware version as a submodule

Pull request created also

Sorry, been meaning to have a look at this but have been feeling a bit rough recently.

Not too keen on commenting out that block without understanding why the simulator doesn't like it (in case it indicates a bug with the simulator) so have had a look at it.

This is the standard code:

And this is with the block commented out:

What you can see from this is that Vq does actually need to go negative during the acceleration to keep full control of Iq. You mostly get away with it but do partially loose control until the frequency reaches 30Hz and Vq is allowed to go negative. Can't see any reason why this would be any better in the real world in the car (unless the currents are lower, it doesn't show up at all on lower throttle current values?, or it might be hard to feel as it only lasts a fraction of a second). I'm sure that if you go looking for it you will find traces of it so I think it would be better to fix it rather than commenting out the code for the simulator.

This is the best fix I have come up with:

Code: Select all

      if (frqFiltered < FP_FROMINT(5))
         qController.SetMinMaxY(dir <= 0 ? -qlimit : 0, dir >= 0 ? qlimit : 0);
      else
         qController.SetMinMaxY(-qlimit, qlimit);

which gives this:

I can't quite remember why this block is here but would reducing the frq threshold from 30 to 5Hz be acceptable as it virtually eliminates the problem?

[Pete9008]

At risk of exposing myself as the dummy I am could someone give me a step by step guide to building the simulator?

Obviously I start with GIT clone ……

Again sorry should have done this sooner!

First install Qt, https://www.qt.io/download-qt-installer. I'm still using an old version but it should work fine with the latest too. The open source version is fine for this. Qt should be happy on Linux, Windows, Mac, etc.

Once it has downloaded create a directory and then clone the simulator code into it

Code: Select all

git clone https://github.com/Pete9008/IPMMotorSim

if using Johannes repository which has the submodule already there you can include --recurse-submodules to also get the openinverter firmware. Otherwise if using mine move to the IPMMotorSim subdirectoty (the one that contains the IPMMotorSim.pro file) within the project and get the firmware

Code: Select all

git clone --recurse-submodules https://github.com/jsphuebner/stm32-sine

Open up Qt and then open the IPMMotorSim.pro file. It should then ask about configuring the project, selecting the default kit (that should already be selected) will be fine. Then just to be safe do a rebuild (under build menu) and run (either the play icon or F5) and it should run. You will probably need to adjust the settings in the param_prj.h file (same directory as the .pro file) to match your install but make sure that both the resolver and motor poles are set to 4 (other values should also work but I haven't tested it, the resolver and motor poles values do have to match though).

[Pete9008]

One other though on the above code mod. Wondering if this is what is actually causing the low speed trips when stepping hard on the throttle from standstill. It would fit all the symptoms - not allowing Vq to go negative means that Iq rises in an uncontrolled way to a much higher value (460A plus another 150A of Id in the above example - with the limit set to 300A!) which could well cause a desat event?

@Bigpie - might be worth a try?