Current control of induction motors

[catphish]

Just a note on tuning. I just attempted a drive with fslipmin=1
This eliminates the vast majority of the low speed oscillation.

The only negative side-effect are these current spikes that sometimes happen when reducing to 0% throttle.

With a minimum slip, the algorithm is forced to reduce the output voltage all the way down to zero to reach zero torque. At some speeds, this seems to create a current spike as some residual energy is discarded. However, this has no impact on driving and don't seem to be large enough to damage anything.

Of course, the V/Hz firmware reduces torque to zero by reducing voltage so I have to imagine these current spikes occur there too. On a mildly related note, this is probably the same issue that makes regen unstable. It's one of those edge cases where reducing voltage *doesn't* reduce current, and my algorithm just doesn't understand that concept.

In any case, this setting is worth trying as it can certainly improve the smoothness of the drive at low speed.

Code: Select all

fslipweak=4
fslipmax=3
fslipmin=1
throtcur=6.5
curkp=1
ocurlim=900
idcmax=650

I would also reiterate, if you want to test this code, start with a rather lower value of throtcur and and work your way up.

[johu]

Probably everyone knows all this already?

I didn't know any of this. I may be good at simplifying things but at the cost of ignoring anything that is sophisticated

Just a note on tuning. I just attempted a drive with fslipmin=1
This eliminates the vast majority of the low speed oscillation.

An improvement a day keeps petrol away

[catphish]

I found myself thinking about regen again today, and I think I have an idea how to prevent the unpleasant current spikes. It's my suspicion that all along I've been trying to set the current too low. Looking at this chart, we can see that as we switch into regen and set slip negative, we get a rising current. It rises about 50% above my target current, and the algorithm panics and slashes the voltage. Doing so creates a huge current spike because the voltage suddenly drops way below the back EMF. It's clear what is happening, but I still can't quite get my head around why.

With the V/Hz method this isn't a problem. We set a voltage, and simply allow current to fall wherever it falls.

Anyway, it occurred to me that perhaps I'd have a better chance of controlling current if I set the target current much higher. If we always try to push the current up higher than it naturally wants to be, he positive voltage-current relationship should be restored. In the above chart, the current set point was only 50A, whereas looking at V/Hz control, the current is generally in excess of 200A even for light regen.

I did a quick test on the bench, setting a low regen current level (30A)

And then with a higher regen current level (50A)

And then with 50A current and a slightly reduced slip

I will try this in the car at some point and see if pushing a higher regen current has the same improvement there.

[catphish]

I did some more regen testing today, this time using higher current targets and lower slip as proposed. This does lead to a substantial improvement in stability! Regen seems to work and remains stable.

However, one problem remains. When reducing regen (ie moving from regen to zero or forward torque), a huge current spike occurs. This seems to be because we try to reduce the current, current doesn't reduce in a timely manner, and the algorithm reduces voltage to zero, causing the huge current spike (this triggered my 900A ocurlim).

It's likely that current changes lag behind the slip changes, so I will test again with reduced gain on the current PID.

EDIT: Edit: Looking more closely at the chart, it seems that I attempted to go from 100% regen to 0% regen in 30ms. This is probably must too fast to expect the current to decay. I'll look at adding some slew rate limiting, either to the throttle, the current target, or voltage output.

The test above was run with a 50A minimum (ie magnetizing) current. I'd prefer not to have to do this though as it poses a risk to anyone turning off the ignition while that 50A current is active.

[catphish]

A while back, I experimented with some code to graph the in-phase (real) and out-of-phase (reactive) current. Looking again at that data I am convinced it is useful for a couple of reasons.

Firstly, looking at the following 0-60 graph it can clearly be seen that as speed increases, the ratio between real and reactive current changes, despite the slip remaining consistent. There are two possible explanation for this. Either the measurement method is incorrect and the measurement lags as things speed up, or at higher speeds, more slip is actually needed to maintain the same torque conditions. My suspicion is the latter, but I will look at different ways to measure real and reactive current to confirm this. If this is the case, the algorithm may be able to improve performance by scaling (or even automatically adjusting) slip with speed.

Secondly, I have been troubled for weeks with the problem of how to handle the situation where current is above target, but reducing voltage actually *increases* current. This only ever happens during regen, but it's been a pain to detect and compensate. Looking at the situation from a real / reactive perspective gives a nice new view on this. When current rises unexpectedly, it's not voltage from the inverter causing it, and as a consequence, it's also not measured as real positive current, so this may give more opportunity to compensate correctly. This graph isn't nearly as tidy as the first, things go bad fast during reen.

I will integrate this logging into my latest firmware and run it for a few long drives to collect plenty of data while i think about how to use it.

Finally, to speculate... there may be two things I can do here:
1) Adjust slip at different speeds to see if this evens out the ratio. Frankly I'm not convinced this is necessary, but it's a useful tool for squeezing out those last few % of torque / efficiency.
2) Find a way to scale voltage during regen using the separate inphase / reactive currents. In particular, don't reduce voltage when it's obvious voltage isn't what's creating the current (because voltage is way out of phase with the current). In this case we may need to reduce slip, increase voltage, or possibly just hold voltage steady and let the situation settle on its own.

I'll update once I have more data and more of a clue

[catphish]

Big success. I now have stable regen. I didn't achieve this by any particularly clever code, just by limiting various slew rates.

Specifically:
1) I introduced separate gains for positive current correction vs negative current correction. This allows me to tune the negative gain to prevent hitting 0v during the transition out of regen, but keep an aggressive positive slew, which is harmless.
2) I reduced regenrampstr to 2. It therefore takes about 500ms to go from zero torque to full regen. This feels slow.
3) I reduced throtramp to 10. Therefore takes 200ms to go from full regen to full throttle, this doesn't feel slow.

I suspect with more tuning these could be brought in a bit tighter, depending on how much regen is actually required. I've been testing with 200A AC current and 0.5Hz of slip, which gives up to 100A into the battery at higher speeds.

With these settings I can get pretty consistent regen down to 2Hz. This is basically good enough for single pedal driving. I didn't try setting this any lower, but I see no reason it shouldn't work down to less than 1Hz.

Plenty more tweaking to do, but it certainly demonstrates that this approach can do regen if some compromises are made on the extreme throttle slew rates that I've been enjoying previously.

Looking at this next chart, it seems that these changes keep the current above 100A during rapid transitions in and out of regen.

It's my strong suspicion that somewhere around 100A is the correct magnetizing current for this motor, and that by holding the current above 100A at all times, we could be more aggressive with the gains / slew rates. However, in order to do this, I would need to make sure this only happens when the vehicle is in motion otherwise inevitably inverters will get blown up by being switches off while stationary and in drive.

Sorry for all the charts; I know it's boring but it's the best way I have to demonstrate progress unless anyone wants to come and sit in my car

[johu]

superb!

I wonder if we eventually let this supersede V/Hz control or have a mode selector should you prefer V/Hz for any reason. At least rather than having another firmware flavour.

[catphish]

So, after lots of tuning (and only minor code changes) I would like to release what will hopefully be the final version for now. This version enables regen! It's still not as polished as I'd like, but it seems to work.

Attachments:
stm32-sine.bin - Version 5.26.X
tesla-sdu-performance-slipmin.json - this is the recommended configuration that I use in my car, high performance, fast throttle response, no regen
tesla-sdu-performance.json - my previous configuration, not as smooth as the version with slipmin
tesla-sdu-regen.json - less aggressive throttle slew, regen enabled

If you are testing this, be sure to apply the new parameters. I can't predict how it may behave with your existing parameters.

NOTE: The performance configuration is limited to 500A of DC current (idcmax=650) to protect my hybrid battery pack. If your batteries can take more, just increase idcmax. If they can take 700A+ then you probably don't need to use idcmax at all, and you will get a lot more out of the drive unit.

Parameters:
throtcur - set this to the number of amps (peak) per % throttle. SDU tested up to 8.0
rcurrent - set this to the number of amps (peak) per % regen. SDU uses 2.0
curkp - This is the gain for current correction in the positive direction. Default is 128 (note this value is scaled differently from the previous version)
ncurkp - This is the gain for current correction in the negative direction. Default is 128. Needs to be somewhat lower when regen is used enabled.
fslipmax - slip at 100% throttle. SDU uses 3.0
fslipmin - the slip at 0% throttle. Start at zero. There's probably no reason to raise it.
fslipweak - maximum value of slip for automatic field weakening SDU uses 4.0
rslipmin - slip at 0% regen, this should almost certainly not be changed from zero.
rslipmax - slip at 100% regen, this should be much lower than forward slip. SDU uses 0.5
regenrampstr - below this frequency, regen is reduced down. This has been tested all the way down to 1.0Hz but regen feels rather harsh at low speed, so higher values may be more pleasant.

Source code at https://github.com/catphish/stm32-sine/tree/amp

Hopefully somebody other than me will be able to test this soon and comment on how it compares with the existing V/Hz firmware.

For anybody wanting to test, here are my recommended CAN exports for logging:

Code: Select all

can tx ilmax 1 0 32 32
can tx ilmaxtarget 1 32 32 32

can tx speed 2 0 32 32
can tx idc 2 32 32 32

can tx fslipspnt 3 0 32 32
can tx amp 3 32 32 32

can tx tmphs 20 0 32 32
can tx tmpm 20 32 32 32

I have attached a SavvyCAN graph definition for convenience (this assumes you have an ISA shunt for DC current).

[yaroslav]

You can compile the firmware in hex format. I still haven't figure out how to download the firmware in bin format

[catphish]

[OLD VERSION REMOVED]

[catphish]

Just a small update on this.

The non-regen version continues to work well in my car. I have now tested throtcur up to 8.0 on my SDU, giving a full throttle current of 565A RMS (800A peak) and pushing my car to 60mph in 4.5 seconds

I also increased fslipweak to 5.0 which gives strong acceleration to 70mph+. The remaining settings seem good.

In my case, everything is limited by my 300V 500A battery pack and the idcmax setting does a good job of limiting the DC current to 500A.

[catphish]

Following on from the above, there are now two changes I'm now considering making to this firmware:

1) Get rid of regen. I don't plan to use it, I'm still worried about its stability, and I don't want to maintain / support it. This will dramatically reduce the number of parameters.

2) Remove the dynamic field weakening and replace a pair of parameters (fslipconstmax, fconst). We can then linearly scale the maximum slip from fslipmax at 0rpm up to fslipconstmax at fconst. My suspicion is that this will make things more responsive at high speed as we won't need to wait for dynamic field weakening to happen. It will also allow me to try lower slip values at low speed which I suspect will further improve torque.

[catphish]

I have made the two changes above to the firmware. Removal of regen makes me more comfortable releasing this and encouraging others to try it, and the new field weakening configuration works well. A little more configuration is required, but the result is instant throttle response in the field weakening region as hoped.

Here's a chart of testing a full throttle test run today. I've annotated it to explain a little about how this firmware is configured.

A: From a stationary start, when throttle goes to 100% the target current and measured current rise almost instantly to 560A RMS (configured by throtcur). Slip is set to slipmax (in this case 3.0Hz).
B: As speed increases DC current nears its configured limit of 500A (idcmax), the AC target current is gradually reduced in order to keep DC current within the limit. This is all calaulcted dynamically. Measured AC current closely follows the target.
C: At 200Hz AC voltage reaches full battery voltage (300V). This is not something that has to be configured, this limit is reached naturally.
C: At the same time, slip begins to increase to allow us to maintain the same current with no more voltage available. The frequency where this happens must be manually configured to the same frequency where voltage is observed to reach its maximum (fweakmin). For my configuration this is 200Hz. This point was previously known as fweak.
D: Slip frequency will rise to eventually reach fslipweak at a manually set frequency (fweakmax). In my case, this is 5.0Hz slip at 300Hz frequency.

Full release and documentation of this firmware will follow shortly.

[catphish]

Release time! No regen! I've been running this code in my car for several weeks now without regen so I decided it was best to release it without for now. This puts me in a better position to confidently support it.

Attachments

stm32-sine.bin - Version 5.26.Y
stm32-sine.hex - Version 5.26.Y
tesla-sdu-catphish.json - the configuration that I use in my car, high performance but limited to 500A DC.

Parameters

throtcur - set this to the number of amps (peak) per % throttle. SDU tested at 8.0 (800A peak, 560A RMS).
ocurlim - overcurrent shutdown. Set this about 150A higher than throtcur x 100. SDU tested at 950A.
curkp - This is the gain for current correction. SDU tested at 256.
fslipmin - the slip at 0% throttle. SDU tested at 1.0
fslipmax - slip at 100% throttle up to fweakmin. SDU tested at 3.0
fslipweak - the maximum slip for field weakinging. SDU tested at 5.0 (previously known as fslipconstmax)
fweakmin - the frequency to begin field weakening. SDU tested at 200. This is correct for a 300V battery, scale linearly for other voltages. (previously known as fweak)
fweakmax - the frequency to end field weakening. SDU tested at 300. This is correct for a 300V battery, scale linearly for other voltages. (previously known as fconst)
idcmax - DC current limit. The current is rather overestimated. My configuration uses a value of 650 for an actual DC current limit of 500A. If your battery can handle 700A+ and you aren't worried about DC current just keep increasing this until is has no impact.
tripmode - set this to DcSwOn unless you want your inverter exploded.

As always, source code available at https://github.com/catphish/stm32-sine/tree/amp

At this point, I'm looking forward to feedback from anyone else brave enough to test this firmware on an SDU (or maybe LDU). I would advise starting with the supplied parameters as-is, but initially with a substantial reduction in throtcur and ocurlim.

[MattsAwesomeStuff]

I think I'd rather regen than better current control, but, all things in due time.

I'm a long ways away from testing firmware, but hopefully in a few months I'll be rolling (he says, 4 years into a "summer project"), and I'd be happy to give it a whirl then if it's still relevant.

[mario]

Last night I've updated my Prius Gen3 with latest code from https://github.com/catphish/stm32-sine/tree/amp branch - v5.26.X
I did change few of the parameters and will post later in the project thread...
But, with this firmware it was easy for me to find limit and avoid inverter shutdowns by just altering throtcur parameter.
With value 5 there are no restarts and car pulls great, easily catching 6k rpm in second gear on short straight.

Thanks @catphish, great work.

[catphish]

Last night I've updated my Prius Gen3
I did change few of the parameters and will post later in the project thread...
But, with this firmware it was easy for me to find limit and avoid inverter shutdowns by just altering throtcur parameter.
With value 5 there are no restarts and car pulls great, easily catching 6k rpm in second gear on short straight.

Thank you very much for testing! Great to hear this works on the Prius and you're getting smooth results! I look forward to seeing more details.

latest code from https://github.com/catphish/stm32-sine/tree/amp branch - v5.26.X

It's not very important but the version you built is actually v5.26.Y, I just forgot to push the new version number to the repo. Fixed now.

[mario]

Thank you very much for testing! Great to hear this works on the Prius and you're getting smooth results! I look forward to seeing more details.

Thank you.
There will be no test for some time, as I plan to put car on the stands again and finish everthying that's left.

It's not very important but the version you built is actually v5.26.Y, I just forgot to push the new version number to the repo. Fixed now.

Yeah, it doesn't matter, it was the latest code.