IPM Motor Simulation and FOC Software

User avatar
johu
Site Admin
Posts: 5789
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 157 times
Been thanked: 1023 times
Contact:

Re: IPM Motor Simulation and FOC Software

Post by johu »

Yes this should also be tested! I hope someone can volunteer as we take the car for a longer trip tomorrow and I don't want to play with the software while not home ;)

Did you simulate the recent release without any syncadv?
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

johu wrote: Mon Sep 12, 2022 1:36 pm Yes this should also be tested! I hope someone can volunteer as we take the car for a longer trip tomorrow and I don't want to play with the software while not home ;)

Did you simulate the recent release without any syncadv?
Thought it brave testing it last week for that very reason!

No, but I've been simulating everything with Syncadv disabled for a while now so it shouldn't make any difference.

Need to tidy up the simulator and mod it to support the new build. Is there a version number anywhere (either a #define or parameter) that can be used to distinguish the new source code from the old?
User avatar
johu
Site Admin
Posts: 5789
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 157 times
Been thanked: 1023 times
Contact:

Re: IPM Motor Simulation and FOC Software

Post by johu »

Pete9008 wrote: Mon Sep 12, 2022 1:41 pm Need to tidy up the simulator and mod it to support the new build. Is there a version number anywhere (either a #define or parameter) that can be used to distinguish the new source code from the old?
You can use the VER define in param_prj.h . It's a string "5.20.R"
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Also just came across this:
F103Rx.png
I'd been sure that the processor had only one ADC (changing to 3 on the high density devices) but this seems to indicate that there are 2. It is the STM32F103R8 that's used isn't it, what am I missing?
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

johu wrote: Mon Sep 12, 2022 1:44 pm You can use the VER define in param_prj.h . It's a string "5.20.R"
Perfect, thanks.
User avatar
johu
Site Admin
Posts: 5789
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 157 times
Been thanked: 1023 times
Contact:

Re: IPM Motor Simulation and FOC Software

Post by johu »

Pete9008 wrote: Mon Sep 12, 2022 1:45 pm Also just came across this:
F103Rx.png
I'd been sure that the processor had only one ADC (changing to 3 on the high density devices) but this seems to indicate that there are 2. It is the STM32F103R8 that's used isn't it, what am I missing?
Wait, really? It's the STM32F103RBT6 and sometimes R8T6 (64k flash)

Says the same here: https://www.st.com/en/microcontrollers- ... 103rb.html

2 ADCs. Ok, some things to try when I get back!
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

No idea, completely bemused, even the low density parts seem to claim 2 now.

I'm positive that when they first came out they just had the one as I remember choosing the high density part because of the extra ADCs.

Definitely opens up a number of very interesting options if true :)
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Ok had a play after work today, i somehow convinced myself during the day that my issues were down to syncof being to far advanced, I have it set to 15500 because that where it makes the best power but thats at the far end of the dead band when foc tuning. ( i figured the uncontrolled acceleration was because I was already advanced so far from the d axis that further weakening of the field lead to the acceleration, sounded good in my head! but probably show my poor lvel of understanding) so i set it back to the middle of the dead band, entered Johus field weakening params and off a went until at around 2.5k rpm the was a big thump and the worst noise i ever heard from a motor, slowly and noisy cogging to a stop, my heart sank, but i restarted the inverter and all was ok! tried playing with the f/w controller gains repeated this event a few times until i knew i wasn't getting anywhere. I then reloaded my parms with the higher syncof and f/w disabled and went for a drive to check i hadnt hurt anything.
it was then i noticed that i ws no longer getting unwanted regen when lifting off the throttle or when braking, The only diffrence being i had a more or less full battery, not so full as to disable regen but more than i had been testing with. Im wondering if my issues may be down to my lower nominal voltage, as im only 80s not 96.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Now that's not good :( Very relieved to hear nothing seems to be broken though.

Trouble with tuning the parameters is that they all interact to a degree and it's quite possible to use one to mask the effects of another. I wondered before whether syncofs was sometimes tuned to tweak the effect of syncadv and I think this is what you've effectively been doing.

While the right syncofs has always been important it's especially so with the new version; it's not a good idea to run the new code with syncofs not set to the centre of the deadband. If you have been running with it offset then it's quite likely that other parameters will need tuning to get you back to where you were.

That being said what you experienced sounds like the Iq or Id control loop loosing control and driving the wrong currents into the motor. This could explain Bigpie's inverter trips too.

Now I've never tuned a motor controller (so feel free to ignore the following) but have tuned a number of other control loops in the past and have played with the simulator quite a lot too. The way I would suggest going about this is to break it down. First set syncofs to the centre of the deadband, disable Mtpa (by setting lqminusld to 0), disable FW by setting fwkp and fwki to zero and see how it runs (it will be operating just on Iq so will be a down on power). Tune kp and ki till it behaves (responds quickly to changes but without overshooting and is stable when cruising). When you are happy with kp and ki enable Mtpa by setting lqminusld to a low value (0.5mH) and see how it behaves. Keep increasing lqminusld until it stops improving and then back it off to the last good value. Ki and kp they may need tweaking while doing this but shouldn't need big changes. Only when you are happy with all the above try adding FW back in.

I've learnt quite a lot about motors while doing the simulator - would it be of any help if I tried to summarise my understanding here?

Edit - One though on the regen - is is possible that a parameter didn't get set back to the original value and is still using johu's value?
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Thanks for the reply, this is what I attempt to do this evening, I had the car driving quite happily with a centred syncof, but couldn’t get a good tune, unfortunately i can’t put the Motors through that abuse repeatedly just to see if I can get the software to work as intended (yes I said motors I have 2 motors on a common shaft each on its own inverter just to make tuning easier) I may just have to live with how it is for now, as any move away from this syncof does create extra motor noise as well as less power,
Ultimately I don’t need field weakening I am happy with upto 5krpm as I have a manual gearbox and choice of gears.
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Will double check Parma’s in the morning to see if something is different,
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Understand that. It's the main reason why I'd like to get the simulator a bit closer to reality if possible. It would be really nice to be able to get somewhere close before trying it on a car. Not sure it will ever get there but worth a try.

Could the two motors be fighting each other? Two motors makes the whole control problem a whole lot more difficult.

Edit - Do you have syncofs offset on both motors or just one?
User avatar
Bigpie
Posts: 1595
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 75 times
Been thanked: 304 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

Getting the simulation to match close to reality would be awesome.

A big yes please on the summary.
VW Beetle 2003
Outlander front generator
Prius Gen 3 inverter (EVBMW logic board)
Outlander charger
3x Golf GTE batteries
Chademo Charging
Outlander water heater
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Syncof on both motors the same, initial tuning was done on each motor with the other electricly disconnected. Before both were hooked up but all further tuning has been done with both.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Just had a look at your build thread, some fantastic engineering going on there!

Do you have any more detail on the motors? Are they the same number of poles, do they run at the same speed or is there some gearing between them?
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Thanks, I do wish sometimes I had made life easier for myself and gone single motor! But Yes same number of poles, no gearing between then so they run at the same speed
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Bigpie wrote: Mon Sep 12, 2022 7:22 pm Getting the simulation to match close to reality would be awesome.
It's probably unrealistic but it would be good to have.
Ev8 wrote: Tue Sep 13, 2022 2:01 am Thanks, I do wish sometimes I had made life easier for myself and gone single motor! But Yes same number of poles, no gearing between then so they run at the same speed
Been thinking about this - two motors with two controllers on a single rigid axle does make me uneasy. Normally when you have two motors there is a bit of give between them, separate axles on a car or a planetary gear set between them that allows each motor a bit of independence. The trouble with locking them together is that the control loops in one controller can start to fight with the ones on the other controller.

With everything perfectly tuned two controllers should work but I think it's going to take quite a lot of time to get to that point.

One other thought on the rigidly coupled motors. How coggy are they when unpowered? I'm wondering whether, while doing the foc tuning, the unpowered motors coggyness is causing the wide dead band you saw - anything that makes the motor hesitant to turn could effect the foc tuning. The best way to do it would be to foc tune each motor before they are coupled together.

Have you considered trying to run them as a single motor? If they run at the same speed and have the same number of poles then it should be possible to mechanically align the poles so that the motor windings are in phase with each other and can be run in parallel from a single inverter/controller? The other option is to have two inverters but slave them together so that there is only a single set of control loops driving both? Of the two options mechanically aligning the motors is physically awkward (motor out, etc) while sharing control loops is difficult electronically and in software. Both are a fair bit of work but I'm wondering whether in the long run they may be the quickest way to a working solution?

Any idea what the power/torque split between the two motors is? Are they physically similar in size or is one significantly larger.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

OK, the following is a summary of my understanding of permanent magnet motors and their control in the hope that it may prove useful to others.

Sorry for the length of it, when I started writing I only expected a fraction of this but it just seemed to keep expanding.

Any errors (and I'm sure there are) please let me know and I'll correct them. I'm no expert on the subject and this is just the way I find useful in visualising and understanding how motors work (and how the way we control them might affect things).

It's mostly relevant to IPM motors but a lot will be relevant to SPMs too.

I’m going to start at a fairly basic level, so apologies if it seems too basic, but I want to try and make sure I’m not using terms and ideas without explaining the background behind them. I’m also going to try and avoid jargon, mainly because I can’t remember a lot of the correct terminology without looking it up first. I’m going to aim for understanding not maths!

Two basic concepts fundamental to motors are:
1) A wire carrying a current in a magnetic field will experience a force on it – this is why a motor turns.
2) A wire in a changing magnetic field will have a voltage induced in it and the direction of the induced voltage is so as to oppose the change in field that produced it – this is why a motor has a maximum speed.

I’m going to start with traditional DC motors as I find it easier to understand these and then build on it to move to other motor types. In a traditional DC motors the coil of wire is on the inside (on the moving bit – the rotor) with the magnets on the outside (the stationary bit – the stator). The magnets generate a magnetic filed around the coil and currents flowing in the coil then generate a force on the coil. Now with a coil there are orientations where the forces from the magnet on different parts of the wire cancel out and there are orientations where they will add. With a DC current applied the motor rotor will move till it reaches a position where they cancel and the rotor will stop. On a DC motor the commutator (the copper contacts and brushes on the motor shaft near one end of of the motor) are arranged so that a new set of windings are switched in, and the old set switched out, before this position is reached. The new windings will continue to experience a force and the motor will continue to turn until the next commutation event. There is quite a good animated diagram of this here https://en.wikipedia.org/wiki/DC_motor, about half way down on the right hand side.

Now our motors are a bit different, there is no commutator but the principle is much the same. Current in the coils causes a force which turns the rotor. Now without a commutator a DC current will cause the motor to turn till it reaches a position where all the forces on the windings cancel (coil vertical on the above linked digram). Now with the motor in this position the current flowing is called direct current or Id. Id does not generate torque – it does not produce movement. It is actually best at holding the rotor stationary (this is what’s used in stepper motors to hold them still). For an ideal (for ideal read non-existent – it’s a term used in physics/engineering to temporarily ignore all the real world behaviours that are also there!) motor that is trying to generate rotational power Id is wasted energy (please note the ideal, our motors aren’t and I’ll get back to Id doing something useful later).

Now if you imaging the rotor being 90degrees from this position (or horizontal in the above linked diagram) this is where all the forces on the coil add, or where we generate maximum torque. Current in the coil with the rotor in this position is called quadrature current or Iq. For an ideal motor this is what we want, it generates the torque which spins the motor and moves the car. The more current, the more torque, the greater the acceleration.

You can imagine that for any rotor position a current flowing in the coil can be considered to be a combination of Id and Iq; with the rotor vertical it is all Id, with it horizontal all Iq. At positions in between it is a combination of both. The commutator on a DC motor is a crude way of trying to maximise Iq and minimise Id for all rotor positions and you can probably see that the effectiveness of the commutator will depend on how many switches it does per rotation. Fewer switches (or fewer segments on the commutator) causes large variation in Iq and Id as the rotor turns (but makes for a simpler and cheaper motor to manufacture). More segments on the commutator gives better performance but at higher manufacturing cost. The commutator also can’t provide a lot of other features that we need so we don’t use one! Instead commutation is done electrically within the inverter which allows much, much better control.

One other nice thing about the commutator is that since it is on the rotor shaft it moves with the coil giving it an absolute reference of the rotor position. The position of the rotor precisely determines when the commutation events occur. Our motors don’t have a commutator so don’t have this reference. Instead a position sensor is used, typically an encoder or resolver. How these work is not relevant here, all that is important is to understand that the resolver is used to tell the electronics exactly what the angular position of rotor is so that it can work out how to drive the coils to generate the correct values of Iq and Id (and for an ideal motor Id=0). Any error in the resolver directly becomes error in Iq and Id.

When we talk about FOC tuning what we are actually doing is teaching the electronics what resolver output corresponds to the rotor being in the direct current position. Once the electronics ‘knows’ that it can work out how to drive the coils.

The other difference on our motors is that the magnets are in the middle on the rotor and the coils are on the outside on the stator in the form of windings around a laminated core. The core is there to concentrate the magnetic field produced by the windings and focus it onto the magnets in the rotor.

So far I’ve just talked about currents, they are what produce torque. We also need to talk about voltages, these produce the currents. We apply a voltage to the coils and this, imposed across the resistance and inductance of the coils, causes the current to flow. We want torque, to generate torque we need amps and to generate amps we need volts. The control for the motor is all about working out what volts we need to apply to the coils, and when we need to apply it, to generate currents in the windings that correspond to the Iq and Id needed to get the motor to do what we want.

Now for a quick diversion into voltage/current representations. I don’t know about you but I just can’t think in terms of 3-phase systems. All the above is talking about single phase, or one coil, and that I can just about cope with. Getting my head around the above for a 3 coil, 3-phase, system is too much. Fortunately we don’t have to There are a couple of really nice transforms called the Park and Clarke transforms, what they do is take the rotor position and the 3-phase coil/winding currents and turn them into the Iq and Id components. We can then work with these much simpler Iq and Id components to do all the control stuff to calculate direct and quadrature voltages (Uq and Ud) and then use the inverse (reverse) Park and Clarke transforms on these to get back to 3-phase voltages to actually apply to the motor.

The control algorithm inside the motor controller is basically to take in the rotor position and use this along with the target torque (or accelerator position) to calculate what voltages to apply to the motor windings to generate this toque.

Unfortunately we now need to start talking about the non-ideal (i.e. real) behaviour of motors. An ideal motor would have no resistance, no reactance, no eddy current losses, no back EMF, no saliency, no inertia, no backlash, no saturation, etc, but they do have all of these. Some of these hurt performance, some have minimal impact but some actually help.

I’m not going to consider all of them, just the ones that are relevant to understanding the operation and control of the motor. The main ones are inductance, back EMF and saliency.

Inductance first. Inductance is essentially a measure of how a component affects current flow, in particular how it affects changes in current flow. A piece of wire has low inductance, you can ramp currents though it up or down very, very quickly with very little voltage. A coil or a winding has high inductance. What this means is that if you apply a voltage across an inductor the current will increase relatively slowly, how slowly depends on the size of the inductor. I’m trying to avoid equation, but some are useful – the voltage needed to produce a particular rate of change in current in an inductor is given by V = L*di/dt. To give an example, say we have a winding inductance of 10mH and we want to change the current by 100A in 1ms, the equation then gives a required voltage of 0.01*100/0.000001 or 1000V. This is a significant number of volts, a lot more than our batteries can provide. To look at it another way, how quickly can we ramp up the current, on the same inductor, with a 350V pack - i/t = V/L so 35A/ms. This may seem pretty quick but the motor control loop typically runs at 8.8Khz or 113us per loop round so in each loop the motor inductance limits the maximum current change to 4A – no much. The take home message from this is that the inductance means that the control loop is limited in how quickly it can actually control the motor, you can’t just set the new current value you need to ramp towards it. You might say why not reduce inductance? The trouble is you reduce inductance by reducing the number of turns or reducing the size of the lamination, both reduce magnetic flux and so both reduce torque. A big motor that generates high torque will typically have high inductance.

There is a silver lining with inductance though, without it PWM control wouldn’t work. We don’t actually apply a voltage, we apply a a pulse width modulated pulse. This is a waveform that is a full DC bus voltage for a percentage of the time and at 0V for a percentage of the time. The inductance of the motor effectively filters this to give a net current change that is the same as the averaged voltage over the same period would provide. The inductance is also what allows regen below base frequency to work (see here for more detail and a great simulation catphish did that explains it viewtopic.php?p=38772#p38772).

The back electro-motive force (BEMF) is the next one. Remember at the start I said that a wire in a changing magnetic filed has a voltage induced in it, well this is the BEMF of the motor. Imaging an unpowered motor spinning, the windings are seeing the magnets in the rotor go past, this is a changing magnetic field to them and so a voltage is induced in them. This is how generators work. The same happens when the motor is powered, a BEMF is generated which actually opposes the Uq term. As the motor speed increases the BEMF increases. The effect of this is that some of the Uq that the controller is applying to the motor to get it to accelerate is being used to counter the BEMF instead of producing torque producing Iq. The effect of this is that the acceleration of the motor slows. This continues until the BEMF actually equals Uq at which point the motor can no longer accelerate. This is what is often called the motors base speed. The way round this is called field weakening. Essentially to go faster we need to reduce the BEMF, to reduce the BEMF we need to reduce the flux linkage. You can sort of think of this as reducing how much of the flux from the rotor magnets links into the stator windings. On motors that use windings on both the stator and the rotor the normal way to do this is to reduce the current in the rotor winding, this reduces the flux and reduces the BEMF. With permanent magnets in the rotor we can’t do this but what we can do is create a magnetic field in the stator windings that opposes the field of the permanent magnets in the rotor – effectively this reduces the apparent strength of the permanent magnets, which reduces the flux and so reduces the BEMF. If you imagine that as the rotor turns the controller generates a rotating opposing field in the windings that moves exactly in sync with the rotor and cancels out part of the magnets field. It sounds complicated that way but due to the magic of the Park/Clarke transforms it just becomes the addition of a continuous negative Id current. As long as the -Id is there the BEMF is suppressed and the motor is able to spin up to higher speeds. The problem comes if, for any reason, the -Id is lost. If it is removed then the full BEMF for the higher speed reappears which can then force high currents back through the converter and into the battery. This is the unwanted regen effect which can be seen; it means that for some reason the -Id has been lost.

Saliency of the motor is when the inductance seen by the Id and Iq currents are different. It’s due to the different magnetic permeabilities of the magnets themselves and the steel lamination that the rotor is made of (SPM tend to be low saliency, IPM high). When the rotor is in the Id position there is more magnet material in the flux path which gives a lower inductance, in the Iq position there is more steel giving a higher inductance. This is also the reason why and IPM tends to have more coggyness than an SPM. The difference also means that that it’s not just Iq that creates torque, on a high saliency motor negative Id can also create torque. I still don’t fully understand why this happens (there are plenty of equations for it but I haven’t found a good way of actually understanding it). This is where MTPA (maximum torque per amp) comes in. There are a number of equations that can be used to calculate what the best combination of Iq and Id are to produce the maximum torque for a given current for a given set of motor characteristics. The relevant characteristics are flux linkage and Lq – Ld which can either be measured or found by trial and error.

With these effects in mind you can see what the inverter controller needs to do. Each time it runs it measures the instantaneous rotor position and uses this along with the instantaneous 3-phase motor currents to calculate the instantaneous values for Iq and Id (using the Park/Clarke transforms). Separately it then uses the torque request (accelerator position), MTPA algotithms and field weakening requirements to calculate what Id and Iq should actually be. PI controllers are then used to compare the measured Iq/Id and the calculated Iq/Id currents and produce control outputs which are the voltages Uq and Ud which need to be applies to the windings to move the currents from the measured values towards the ideal calculated values. The inverse Park/Clarke transform is then used to convert these Uq and Ud values back to the 3-phase voltages that are used to drive the PWM duty-cycles. In the steady state (constant speed) the PI controllers should hold Iq and Id pretty much at the ideal values. Under acceleration, deceleration, changing load or changing battery voltage there will be some delay and so some error but the controllers should always be pushing the measured Iq and Id values closer to the ideal values.

PI controllers are another topic completely and I’m not going to try to cover them here but it is worth covering a couple of terms that regularly get used when discussing them. Closed loop is when the controller output is controlling the monitored input, it’s when the loop is actually controlling the value and a change in the input causes a change in the output. Open loop is when the output has hit the end stops, when it can no longer move any more. At this point the controller is no longer in control of the monitored input as input changes have no effect on the output. The normal goal with controllers it so keep them in the closed loop region, when they move in to the open loop mode things can get unpredictable, they may gracefully transfer back into closed loop without any problem but they also may lose control completely. Stability is desirable in a control loop as it makes it easier to stay in the closed loop region.

The final thing to mention is pole counts. The motor in the linked diagram is a single pole pair motor (one pair of magnetic poles). Our motors are typically 4 or more pole pairs. The number of pole pairs does not make any real difference to the above discussion. Motors with an increased number of pole pairs work in exactly the same way they just compress a single magnetic rotation into a fraction of a mechanical rotation so for example a 4pole pair motor will go though a full 360degree magnetic rotation in just 90degrees of physical rotation. The extra pole pairs help in a number of ways, torque goes up because all the pole pairs work in parallel, the more compact angular dimensions make aligning the magnetic flux easier, they reduce the torque ripple, reduce winding inductance, etc. The only downside is that they need higher levels of commutation but with electronic commutation that isn’t really an issue.

Once again, apologies for the length of this - hope it's useful!
(it's been useful to me at least as while writing it I've realised that there are a couple of things not quite right in the way simulator models the effect of load on base speed, or rather how it doesn't model the effect of load on base speed!)

MUCH LATER EDIT - The above explanation of BEMF and field weakening is a little oversimplified. It is accurate for the case where there is no current flowing in the motor but isn't a complete description when there is. When current is flowing two additional terms appear in the motor equations, a Vq term and a Vd term. The Vq term is equal to +wLdId and the Vd term is equal to -wLqId. It is the Vq term that is used to provide field weakening as it is the opposite polarity to the BEMF. If the BEMF term is equal to the Vq term (or wλ = wLdId) then the BEMF is fully cancelled and the quadrature voltage at the motor terminals will be zero allowing the motor to spin to high speeds; the current at this point is termed the critical current. It is worth noting that for some motors this critical current is within the operating current circle and in this case it is important that the field weakening current does not exceed this current (if it does the voltages will start increasing again and control of the motor could be lost). The terminal voltage of the motor is at the minimum with Id = Icrit and Iq = 0. As the currents move away from this point the terminal voltage of the motor will increase and the speed at which they increase is proportional to frequency; the higher the frequency the more important it is that the controller has Icrit correctly set.
See viewtopic.php?p=47287#p47287 for more details and a diagram.
User avatar
Bigpie
Posts: 1595
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 75 times
Been thanked: 304 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

Thank you, that's a pretty good explanation. I was enjoying reading that so much I lost track of time and was almost late collecting my kids from school :D

I'll have to re-read it a few times for it to sink in
VW Beetle 2003
Outlander front generator
Prius Gen 3 inverter (EVBMW logic board)
Outlander charger
3x Golf GTE batteries
Chademo Charging
Outlander water heater
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Bigpie wrote: Tue Sep 13, 2022 2:49 pm Thank you, that's a pretty good explanation. I was enjoying reading that so much I lost track of time and was almost late collecting my kids from school :D

I'll have to re-read it a few times for it to sink in
No problem, hope it helps (and hope it's right!)
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Wow that’s the biggest post I’ve ever seen on this forum! Back to my motors a minute, yes I believe the 2 being coupled is the reason for the wide dead and when tuning also! Despite your fears the 2 motors seem to run better together than either single motor on its own freewheeling. I have done over 300miles in various states of tune and it definitely mostly behaves fine,

Whilst I agree the best method would be to have the poles perfectly aligned unfortunately I hadn’t considered this to be a big issue when I made the internal coupling, turns out they are nearly aligned (by chance) but probably a few degrees apart and this I expect help account for the widened dead band.

With weekend I intend to do a little individual motor tuning by lowering the thortcur on one motor to a very low value and tune the other.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

Ev8 wrote: Tue Sep 13, 2022 5:26 pm Wow that’s the biggest post I’ve ever seen on this forum! Back to my motors a minute, yes I believe the 2 being coupled is the reason for the wide dead and when tuning also! Despite your fears the 2 motors seem to run better together than either single motor on its own freewheeling. I have done over 300miles in various states of tune and it definitely mostly behaves fine,

Whilst I agree the best method would be to have the poles perfectly aligned unfortunately I hadn’t considered this to be a big issue when I made the internal coupling, turns out they are nearly aligned (by chance) but probably a few degrees apart and this I expect help account for the widened dead band.

With weekend I intend to do a little individual motor tuning by lowering the thortcur on one motor to a very low value and tune the other.
Sorry about the length of the post, I started writing expecting it to be a fraction of that but had badly underestimated how much there was to cover.

Don't think the alignment is a big issue, you should be able to get it to work the way you have and once things are set up they should share torque pretty well but getting there might take some time. In what way does it run differently on just one motor compared to having both running?

One other thought, the thump you experienced, it couldn't be the coupler slipping could it?

Edit - Q - do you still have a resolver for each motor?
User avatar
SciroccoEV
Posts: 369
Joined: Thu Oct 10, 2019 1:50 pm
Location: Luton UK
Been thanked: 15 times

Re: IPM Motor Simulation and FOC Software

Post by SciroccoEV »

With two motors on a common shaft, you have the ability to drive one motor with the other.

One method of determining the resolver offset is to measure the phase voltages.
User avatar
Ev8
Posts: 801
Joined: Sat Jan 30, 2021 11:05 am
Has thanked: 41 times
Been thanked: 149 times

Re: IPM Motor Simulation and FOC Software

Post by Ev8 »

Yes each motor has its own resolver, and runs its own control board, they just share inputs. No chance of any of the couplings slipping without catastrophic failure, everything is splined, or shrink fitted and pined!

Better in that there is some noise and resonance when only one motor is powered probably because of the cogging of the non driven motor
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: IPM Motor Simulation and FOC Software

Post by Pete9008 »

SciroccoEV wrote: Tue Sep 13, 2022 6:32 pm With two motors on a common shaft, you have the ability to drive one motor with the other.

One method of determining the resolver offset is to measure the phase voltages.
Two motors on one shaft does open up some interesting possibilities, you could even use one to dyno the other?
Ev8 wrote: Tue Sep 13, 2022 8:17 pm there is some noise and resonance when only one motor is powered probably because of the cogging of the non driven motor
That would make sense.
Post Reply