IPM Motor Simulation and FOC Software

User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

I could possibly handle the coding of the ESP32, but my C is probably too weak to manage to implement the logging into OI, at least in and clean way. I've been trying to get my head around uart code.

Code: Select all

Terminal::Run()
Looks to be called once per clock cycle, so maybe something in there if realtime logging enabled?
It uses 921600 baud, I'm guessing we'd need faster and use usart_send http://libopencm3.org/docs/latest/stm32 ... df9526722d
splitting the data in to 16 bit words it some defined order?

I've got a spare board so might try using https://github.com/jsphuebner/stm32-template to write out an incrementing value and see what happens in the week.

My leaf motor should be arriving next week so maybe this will not be an issue with a motor with more inductance,
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 »

Been having a think about this too, just for fun I threw a few components onto a PCB to see what might be possible:
ESP32_Top.png
ESP32_Btm.png
That's a PCB of around 0.8" by 1.3" (plus the IDC connector) with a ESP32-WROOM-32D on one side and a micro SD socket and a real time clock on the back. All looks possible, still a fair bit of work to turn it into something real though.

On the firmware Johannes terminal implementation is nicely done and uses double buffered DMA for the transfers so using uart_send might actually slow things down (especially once you allow for waiting for the Tx register to empty)! The existing PutChar function should do the job. The standard 921600baud would allow around 10bytes per run of the control loop which is not really enough. If we could double the baud rate then 10x 16-bit words would be possible. 1 or 2 would need to be used for a unique(ish) header leaving around 8x 16bit words, say i1, i2, angle, id, iq, pwm0-2? It would be nice to have a few more but that means either pushing the baud rate even higher (probably unrealistic) or only sending data every other run of the control loop. The later may be a better compromise.

Edit - PutChar won't quite work, it reserves '/n' to trigger a buffer transmit which we don't want (can't guarantee that a '/n' won't occur in the middle of the binary data) so would need a tweaked version of it that only started a new DMA when the buffer was full. And if doing that may as well optimise it for accepting binary data too.

Could do with figuring out how many people might want to use high speed logging?

Are you giving up on the Outlander motor then?
User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

I've already bought the leaf motor, the outlander motor is sufficient on 5.20, if I can stop the cut outs but not exciting. Might use the outlander motor (actually the generator when in the outlander) along with the motor and gearbox in something else, with an outlander inverter.

Should have gone for the outlander rear motor really and saved a few kg and £

Never used DMA, so only understand it on a high level but can follow putchar for the most part.
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 »

I'm still wondering if the cutouts are thermal. Had a look at my inverter and each IGBT driver looks like it is connected to a temperature sensing diode on the die. If so then it would make sense for the error signal to the logic board to do both desat and over temp. I'm going to run MG1 and MG2 in parallel just in case. Have you considered trying that, might help with the leaf motor too?

Think the leaf is a safer bet than the outlander rear in terms of power at the moment.

For me the tricky bit on the logging is the Esp code, in particular hooking into the web interface, I haven't a clue how that all works!.
The stm code is all stuff I'm familiar with (which is why I was originally thinking of using another arm core chip for the logging, the esp will be a better solution though).

Edit - would an outlander inverter work running the generator as a motor?
User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

Already using MG1+MG2, that was my first go to fix.

The outlander inverter supports torque requests for both generator and motor. There's an internal clutch that's not able to be engaged until the oil pressure builds up, around 30mph, so until then only the motor is connected to the drivehafts mechanically.

Web software is my bread and butter
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: Mon Sep 26, 2022 7:29 am Already using MG1+MG2, that was my first go to fix.
That's a bit worrying, could do with working out the reason for the cutouts. When are you pulling the motor out?
Bigpie wrote: Mon Sep 26, 2022 7:29 am Web software is my bread and butter
:D

If you would be ok looking at the esp web code then I could do the OI firmware and help with any esp C code?

Can't decide on a PCB for it, depends on the level of interest. If it's just you and me it would be quicker and cheaper to use dev boards. I'm not interested in selling boards but would be happy to share design/manufacturing data.

Probably worth a separate thread for it?
User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

Agreed on a separate thread and dev boards and hot snot works for now. I'm happy to tackle the ESP code
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 »

I'll leave the pcb for now the (only started it as was bored but brain wasn't working well enough to do any coding!)

Probably be a couple of days before I have anything to post on it. If you have anything to post before then please start a thread for it :)
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 »

Could it possibly be the case that with mg1&2 paralleled before the phase current sensors that at full load you may be maxing out the range of the sensor?
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 »

Desaturation detection is done at the gate driver level by measuring the on voltage of the power semiconductor (IGBT or MOSFET).
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: Mon Sep 26, 2022 9:46 am Could it possibly be the case that with mg1&2 paralleled before the phase current sensors that at full load you may be maxing out the range of the sensor?
It's possible but there is still the question of why the firmware isn't catching it before it gets that high?
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: Mon Sep 26, 2022 9:46 am Could it possibly be the case that with mg1&2 paralleled before the phase current sensors that at full load you may be maxing out the range of the sensor?
One real possibility is that here is a problem with one phase of the MG2 outputs and the lone IGBT on the MG1 is trying to do it all by itself and going into overload?
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 »

It's quite possible that the rise and turn-on times are different for the two power stages, so one could be hitting desat.
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 »

From pictures they look very similar, they have the same drivers and the oak ridge report shows the same die dimensions and it would make sense to keep them the same from a procurement point of view, but yes if they are different devices they may well not share well. Could do with paralleling them after the current sensor and then checking in code to see how they share (except that there aren't the spare adc channels to do that :()
User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

While that might be a factor, I was getting cutouts before paralleling, as too was Tom.
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: Mon Sep 26, 2022 11:32 am While that might be a factor, I was getting cutouts before paralleling, as too was Tom.
Did paralleling make much of a difference?
User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

Hard to tell definitively, I think I can get higher phase currents.
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
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 »

Even if the power stages were identical, getting seperate gate drives to track is almost impossible. The Gen 2 prius power stage uses the same dies, but a different number of parallel dies for MG1 and MG2.

I'll state it again, desaturation is nearly always done at the gate driver level. Sometimes with a seperate desat detect circuit. This has nothing to do with the Hall effect sensors.

Desat circuits are designed to deal with shoot through currents, shorted phases, magnetic saturation, etc. They have to be fast, which Hall sensors generally aren't.

In some applications, you set the gate drive to automatically turn off the power device (often more slowly than usual to avoid voltage transients) and assert the desat logic output. Some applications may just assert the desat logic and leave it to the microcontroller to decide on action. For instance, ignore any single desat event, but back off or shut down if you see more than a certain number of consecutive desat events.

Paralleling the power stages will get you more current handling once the devices are on, but may not get you any extra capacity during turn-on.

If the faster power stage trips desat as it turns on, the the slower one will trip too as the first one turns off.
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 »

Bear in mind that most drivers have a desat blanking time on turn on of a few us. IGBTs are also pretty slow devices.

Agree that paralleling isn't going to be perfect but very much doubt that it will be worse than not doing it.
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 »

Pete9008 wrote: Mon Sep 26, 2022 12:16 pm Agree that paralleling isn't going to be perfect but very much doubt that it will be worse than not doing it.
But is unlikely to be any better.
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 »

Interested in hearing more if you are willing to share?

I need to decide whether to stay with a Prius inverter with paralleled output stages or move to a higher rated inverter so all information is welcome.
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 »

Blanking time, even more so than rise and turn-on times will vary. If one stage trips before the other, there's no advantage to the second stage.

Parallellng the stages is thermally advantageous, but if the problem is a motor with very low inductance and therefore very fast rise of current, then tripping may be a problem.

This may not be the cause of the trips, I'm just trying to explain why paralleling the satges may not be of any help.
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: Mon Sep 26, 2022 1:19 pm Blanking time, even more so than rise and turn-on times will vary. If one stage trips before the other, there's no advantage to the second stage.

Parallellng the stages is thermally advantageous, but if the problem is a motor with very low inductance and therefore very fast rise of current, then tripping may be a problem.

This may not be the cause of the trips, I'm just trying to explain why paralleling the satges may not be of any help.
Thanks for explaining, I think I understand what you're getting at now.

The desat blanking time will be a little variable but it has to be good enough to prevent false trips on the slowest 'normal' IGBT, and fast enough to protect the device, otherwise there would be numerous nuisance trips.

Consider the case of two IGBTs with separate drive and desat detect circuits that are paralleled and are trying to drive a load that each individual device is not capable of driving by itself. One is slower than the other but both are fast enough to complete the switch before the end of the desat blanking time. What will happen is that the faster device will attempt to turn on but go into desat but since it is still within the blanking window the driver will not trip. The slower IGBT will then complete its turn on pulling the voltage across both IGBTs down below the desat threshold (still before before the end of the desat window). The end result is that the desat won't trip but the first device will have been operating unsaturated for a few micro-seconds and so will have dissipated more power than the other. Essentially it will be running with much higher switching losses and so will be running hotter.

Effects like the above are why I was particularly interested to see that there are individual temperature sensing diodes on each IGBT die and that each driver appears to have only a single error output opto. I think it is quite possible that the inverter is tripping out on over temperature on a single IGBT.

Regarding low motor inductance what would a low inductance value be, would 600uH be reasonable (I don't have a good feel for this yet)? If so then the current rise during an entire 113us pwm switching period would only be 66A (at 350V), the current rise during the IGBT switching time will be a tiny fraction of this.

Edit - this link has quite a good section on desat and blanking windows https://www.ti.com/lit/eb/slyy169/slyy169.pdf (pages 29 and 30)

Edit2 - just did a quick sum, say the faster device is running unsaturated for 2us on each turn on, at 350A, dropping 100V at a pwm freq of 8800. That gives an increase in power dissipation of 600W. Say an inverter is 95% efficient at 100kW (is that reasonable?) so in normal operation each switch in the bridge will be dissipating a sixth of the loss, say 1% or 1kW. So the increased switching losses could mean that device dissipating around 60% more power than it's neighbours.

Edit3 - I don't believe the 2us example above is realistic. 1us or even 500ns would probably be more representative of typical behaviour on something like the Prius inverter.

Edit4 - The only way I can think of getting very high rates of change of currents is shoot through, @Bigpie, what deadtime are you using?
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: Mon Sep 26, 2022 12:00 pm In some applications, you set the gate drive to automatically turn off the power device (often more slowly than usual to avoid voltage transients) and assert the desat logic output. Some applications may just assert the desat logic and leave it to the microcontroller to decide on action. For instance, ignore any single desat event, but back off or shut down if you see more than a certain number of consecutive desat events.
Good point!

I have been wondering for a while whether shuting down the inverter completely for a single error is the right approach? It's definitely the safest approach below base freq, above base it's a little questionable due to the unwanted regen that will occur on shutdown. Wondering whether a better approach would be to immediately derate the output on the first event and then shutdown if it continues?

Edit - The approach probably needs to be tailored to the inverter. The prius is pretty good at protecting itself so the derating approach would probably be best. For an inverter based on discrete components the immediate shutdown is most sensible.
User avatar
Bigpie
Posts: 1586
Joined: Wed Apr 10, 2019 8:11 pm
Location: South Yorkshire, UK
Has thanked: 74 times
Been thanked: 299 times

Re: IPM Motor Simulation and FOC Software

Post by Bigpie »

I'm using dead time of 130. No idea what the inductance of the motor is, I tried to follow a guide to use a signal generator and scope but couldn't get anything reasonable.
VW Beetle 2003
Outlander front generator
Prius Gen 3 inverter (EVBMW logic board)
Outlander charger
3x Golf GTE batteries
Chademo Charging
Outlander water heater
Post Reply