Current control of induction motors
-
- Posts: 264
- Joined: Fri Apr 12, 2019 10:42 pm
- Location: Adelaide, South Australia
- Has thanked: 59 times
- Been thanked: 48 times
Re: Current control of induction motors
I like what you are doing heaps catphish. Thank you for showing me your code. I could not find quickly something on regeneration for IMs. Thank you for exploring IM current control, very interesting...
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
I updated the code to calculate real power and use its sign to change the direction of the PID. This failed and even worse the inverter seemed to have crashed entirely. I will go back over everything later and try to work out what went wrong here. Hopefully I didn't damage anything.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
Now that's disappointing
When you say crashed do you mean hardware or software? In that plot it does looks like it comes to a stop awfully quickly, or is that just an artefact of a firmware crash?
One random thought, do the two builds you have both run OK in reverse (starting with a negative torque command) and then fail in the same way when transitioning to forward torque too?
Could this be an issue with losing control of the induced rotor current, do you have any plots showing what slip is doing during the transition?
Edit - could it have been a divide by zero error on the power calculation?
When you say crashed do you mean hardware or software? In that plot it does looks like it comes to a stop awfully quickly, or is that just an artefact of a firmware crash?
One random thought, do the two builds you have both run OK in reverse (starting with a negative torque command) and then fail in the same way when transitioning to forward torque too?
Could this be an issue with losing control of the induced rotor current, do you have any plots showing what slip is doing during the transition?
Edit - could it have been a divide by zero error on the power calculation?
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
I've gone over everything this evening. These are the conclusions:Pete9008 wrote: ↑Sat Jan 21, 2023 4:31 pm Now that's disappointing
When you say crashed do you mean hardware or software? In that plot it does looks like it comes to a stop awfully quickly, or is that just an artefact of a firmware crash?
One random thought, do the two builds you have both run OK in reverse (starting with a negative torque command) and then fail in the same way when transitioning to forward torque too?
Could this be an issue with losing control of the induced rotor current, do you have any plots showing what slip is doing during the transition?
Edit - could it have been a divide by zero error on the power calculation?
1) The crash wasn't actually a crash. It was just an overcurrent fault. I hadn't anticipated that lots of calculations just don't run when the inverter's not in run mode, so a bunch of values appeared stuck, but they were actually being transmitted. No harm done, just unnecessary panic.
2) Johannes is right. I can't explain it, but under steady state, my original control scheme works fine in both acceleration and regen. More voltage gives more current, regardless of direction. Using real power seems to have been a damp squib, despite the fact that it seemed obvious it would work! I suspect the reason this doesn't behave the way I assumed is because current isn't exactly in phase or exactly out of phase, it's at some other angle that makes the control less intuitive, but nevertheless, in the general case, my PID works.
3) So the question now is why there is usually a current spike shortly after changing slip direction. It happens in most cases when slip changes direction, regardless of what the rotor is doing. It feels like a large flux is building up in the rotor and then i'm unable to control it, pretty much exactly as you say. If the process gets past the initial hump, the regen is well controlled.
Here's a graph of the whole process working perfectly, achieved by using a gradual move from acceleration to regen, and with the wheels off the ground. But here's what *usually* happens: The problem usually happens after a throttle direction switch, but can also oscillate during continuous regen. There are periods where the regen is well controlled, though it appears to begin to oscillate.
This graph actually suggests that voltage has very little impact on current sometimes. Instead the current seems to be beyond my control, but the voltage is controlling the power delivered back to the battery. Very confusing at the moment.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
This sentence just made me realise that when slip changes direction of the induced currents in the rotor will change polarity and that is why your original code works, The PI control direction doesn't need to change because the flux in the rotor has!
Had assumed it was all on your test rig, hadn't realised you were testing this on the car,
I thin Johannes is right about something else too, your control loop tuning may be the issue. Looking at the plots, in light of knowing that it should work, makes me think that what's happening is the torque demand drops so the voltage drops but it drops too fast. When you do things gradually you can see it start to go but the loop catches it and brings it back up again. When it fails it doesn't catch it and it then looks like it may go into saturation (where amp is locked at zero), it then recovers but is just barely stable and eventually loses it again. Johannes suggestion about bringing your loop parameters out to make them easily adjustable would make a lot of sense.catphish wrote: ↑Sat Jan 21, 2023 7:02 pm The problem usually happens after a throttle direction switch, but can also oscillate during continuous regen. There are periods where the regen is well controlled, though it appears to begin to oscillate.
This graph actually suggests that voltage has very little impact on current sometimes. Instead the current seems to be beyond my control, but the voltage is controlling the power delivered back to the battery. Very confusing at the moment.
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
Here's a better closeup of the process. A strange aspect of this is that I see sizable currents when the voltage is at (or very near) zero.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
I think that would make sense. If the loop is saturated then the voltage is being held at zero when it shouldn't be. There will still be remanent flux in the rotor that will be fighting the zero voltage being applied and so causing the current spikes?
Edit - it almost looks like the loop doesn't stabilise again until the flux has subsided?
Edit - it almost looks like the loop doesn't stabilise again until the flux has subsided?
- johu
- Site Admin
- Posts: 6198
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 225 times
- Been thanked: 1259 times
- Contact:
Re: Current control of induction motors
I was going to write just that.
The controller needs more tuning. Like said, I'd use the existing PiController and in addition add a configurable IIRFILTER before feeding ilmax to the PI reg. Then you have some controls.
The controller needs more tuning. Like said, I'd use the existing PiController and in addition add a configurable IIRFILTER before feeding ilmax to the PI reg. Then you have some controls.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
I'll admit, I don't think I understand the physics of the fields and the induced voltages well enough to understand this at the moment.
I did a lot of testing on the bench first, but ultimately, it worked, and I since have no way to test regen with any real load on then bench, I decided it was time to load it into the car. It works very well, even with normal driving, but obviously falls over if I enable regen.
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
Yes. I definitely think this is flux in the rotor fighting the zero voltage until it dissipates, and then the loop stabilizes. Looking at the charts though, it seems to me that there is a problem with the code. Here voltage (green) is being held at zero despite the current (blue) mostly being below the target (black): And here, current is clearly well below the target for an extended period, but voltage is very slow to rise: I will look closer at my PID code and see whether it's broken, or just configured with too little gain.Pete9008 wrote: ↑Sat Jan 21, 2023 7:43 pm I think that would make sense. If the loop is saturated then the voltage is being held at zero when it shouldn't be. There will still be remanent flux in the rotor that will be fighting the zero voltage being applied and so causing the current spikes?
Edit - it almost looks like the loop doesn't stabilise again until the flux has subsided?
It's worth noting that these are only 100Hz snapshots of an algorithm that actually runs at 17kHz.
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
Thanks! I looked at the existing PI controller, but I had some trouble matching it up with what I wanted to achieve. Right now I am just using a pure P controller (it adjusts voltage output by the current error multiplied by curkp).
My current feeling is that it definitely needs more tuning to handle these transient situations. I'm reluctant to add new things (like an integral, or a filter) until I understand how they might help though.
Edit: I think I will reread the code now, and perhaps make curkp less sensitive (right now I'm running it at a value of 2, which doesn't give much scope for adjustment). Then tomorrow, I can try some actual PID tuning.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
Wouldn't say I understand it. The big problem I'm having with this is I keep getting stuck in a rut of thinking about it like a PM motor, the magnets on PM motors don't change polarity though!
Saturation in control loops is a pain, especially on the I term. Even after everything looks OK it still may be unwinding a large accumulated error on the I term. Not sure whether you are using the same PI controller as in the FOC code but it used to have a bug where it could lock up in a state with a large I error term which could cause this type of effect.
Edit - just seen your last post, comment on the FOC PI controller and integral windup is not relevant.
Edit2 - I can recommend Johannes latest PI controller if you need one.
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
I started looking at how my PID operates in other places, and found this. This is an example of normal forward acceleration.
We can see here that when the rotor is already spinning, and throttle is applied, current immediately jumps up to follow the throttle, but voltage (and power, as demonstrated by the battery current) lags behind. It's as if my slip control is what's providing the majorty of the current control here, and the voltage proportional gain is much too low to keep up!-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
This is where my knowledge runs out. Does a 3Hz slip mean that there is a 3Hz current circulating in the rotor? If so is there a limit to how quickly it is realistic to expect that 3Hz current to change in response to a change in slip and voltage or is it instantaneous?
I'm interested in knowing the answer, just not interested enough to go and do a load of research
I'm interested in knowing the answer, just not interested enough to go and do a load of research
- johu
- Site Admin
- Posts: 6198
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 225 times
- Been thanked: 1259 times
- Contact:
Re: Current control of induction motors
Indeed the rotor current is circulating at 3 Hz and therefor it takes some time for the field to build up. That's why some FOC implementations keep id (=current circulating in the rotor) at a constant value to speed up transient response. That is at the expense of loosing efficiency to rotor heating. I'd think in EV applications id is always dynamic much like the feed-forward "V/Hz" variant.Pete9008 wrote: ↑Sat Jan 21, 2023 8:49 pm This is where my knowledge runs out. Does a 3Hz slip mean that there is a 3Hz current circulating in the rotor? If so is there a limit to how quickly it is realistic to expect that 3Hz current to change in response to a change in slip and voltage or is it instantaneous?
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
Next step: since the V/Hz firmware doesn't suffer this problem, I think the best course of action is to improve my logging (fslipspnt, ampnom, amp, fstat, ilmax), and then compare like for like between the two versions. This should make it a lot clearer what aspect of my output is incorrect.
I will also aim to tune curkp, but I think a side by side comparison on the same hardware will shed a lot of light on differences.
I will also aim to tune curkp, but I think a side by side comparison on the same hardware will shed a lot of light on differences.
- johu
- Site Admin
- Posts: 6198
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 225 times
- Been thanked: 1259 times
- Contact:
Re: Current control of induction motors
Just wanted to comment on your code about this.
Code: Select all
static int32_t amp = 0;
Code: Select all
s32fp correction = FP_MUL(error, curkp);
Code: Select all
amp += correction;
Code: Select all
SineCore::SetAmp(amp >> 9)
Since the P-component never finds entry into you amp calculation only the kindof unusually calculated I component you're running a pure I-controller.
You can achieve that with that Pi class with something along the lines of
Code: Select all
PiController currentController;
//in PWMInit or so
currentController.SetCallingFrequency(pwmfrq);
currentController.SetMinMaxY(0, 37813); //Integrator limits
//Somewhere in a setter function or on each PWM run
currentController.SetGains(curkp, curki); //curkp=0 would yield you current setup
//In ISR
currentController.SetRef(ilmaxtarget); //set control target
amp = currentController.Run(ilmax); //runs the controller
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
Thank you for the explanation. This makes a lot of sense. It never occurred to me that I might set the voltage *directly* from the PID. but this seems like a good idea. I have just one question. In my version, I am using an I term of 0.06 * curkp, and I am using a curkp value of 2. If I want to use your PID code I assume I would need to scale down the values. Would the best thing be just just use a much larger value of MaxY, and then shift the output into amp at the end?
For example:
Code: Select all
currentController.SetMinMaxY(0, 19360256); //Integrator limits
amp = currentController.Run(ilmax) >> 9
In FOC mode, the limits are set by dController.SetMinMaxY(-maxVd, maxVd);
But maxVd seems to have a really small value: 2/sqrt(3) - 200 - 1000
Whereas the default value for curki is 20000!
- johu
- Site Admin
- Posts: 6198
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 225 times
- Been thanked: 1259 times
- Contact:
Re: Current control of induction motors
Yes shifting seems a good idea as it gives you more headroom for small controller gains. That said a controller gain of 1 is actually 1/32 because of the FP_TOINT used in Run().
maxVd when spelled out is around 35000 because 2/sqrt(3) is with 15 fraction digits from FOC module.
maxVd when spelled out is around 35000 because 2/sqrt(3) is with 15 fraction digits from FOC module.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
I tried a few things today. I added a P term to the PID. This showed me two things:
* I can't really get the P term to actually be useful. As soon as it corrects and error, the error disappears and hence so does the P term. There may be a correct way to use this, but I haven't found it yet.
* However, one thing I did note is that with no "I" term, the problem of current spikes goes away.
I also experimented with different values of "I" term, and noted that with a very low values, the problem of very large current spikes is reduced, but all this is really doing is causing the algorithm to ignore the problem rather than panic and push the voltage down to zero.
A couple of other things that seem to reduce the problem:
* Higher slip values.
* Lower current values
With all that in mind, my overriding thought at the moment is that I'm overfluxing something. I may be doing this in a couple of different ways:
* Allowing voltage to hang when torque request is zero.
* Using very low values of slip when low torque is required.
It's worth noting that it's clear reducing voltage does not always reduce the current immediately.
The one substantial difference between the output of this implementation and the V/Hz version is that in the V/Hz operation, voltage is always reduced to zero *before* slip is reversed, while mine allows voltage to hang. This is something that could potentially be worked around but for now I'm going to read on how flux is created. I believe I need to find a way to make sure it always gets used up as fast as it's added. This may simply be a matter of using more slip.
I've added a setting to output CAN data at 1ms intervals which seems to work well, so attached is a dump of charts.
The latest code can always be found at: https://github.com/catphish/stm32-sine/tree/amp
Not much has changed there apart from the addition of a P value to the custom PI controller. Perhaps I will find a way to use the P value at some point.
PS. I really appreciate the assistance so far, but don't feel you have to help. I'll keep posting my findings here anyway
* I can't really get the P term to actually be useful. As soon as it corrects and error, the error disappears and hence so does the P term. There may be a correct way to use this, but I haven't found it yet.
* However, one thing I did note is that with no "I" term, the problem of current spikes goes away.
I also experimented with different values of "I" term, and noted that with a very low values, the problem of very large current spikes is reduced, but all this is really doing is causing the algorithm to ignore the problem rather than panic and push the voltage down to zero.
A couple of other things that seem to reduce the problem:
* Higher slip values.
* Lower current values
With all that in mind, my overriding thought at the moment is that I'm overfluxing something. I may be doing this in a couple of different ways:
* Allowing voltage to hang when torque request is zero.
* Using very low values of slip when low torque is required.
It's worth noting that it's clear reducing voltage does not always reduce the current immediately.
The one substantial difference between the output of this implementation and the V/Hz version is that in the V/Hz operation, voltage is always reduced to zero *before* slip is reversed, while mine allows voltage to hang. This is something that could potentially be worked around but for now I'm going to read on how flux is created. I believe I need to find a way to make sure it always gets used up as fast as it's added. This may simply be a matter of using more slip.
I've added a setting to output CAN data at 1ms intervals which seems to work well, so attached is a dump of charts.
The latest code can always be found at: https://github.com/catphish/stm32-sine/tree/amp
Not much has changed there apart from the addition of a P value to the custom PI controller. Perhaps I will find a way to use the P value at some point.
PS. I really appreciate the assistance so far, but don't feel you have to help. I'll keep posting my findings here anyway
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
Just wondering, is the problem that when the slip changes the rotor flux is still in the old direction (because as discussed above it takes time to change)? The rotor current then starts to drop. When it gets to zero there is no back emf to fight the voltage, the current shoots up and the control loop loses it.
Forcing voltage to drop to zero while the rotor flux is changing direction might be the way to fix it?
Forcing voltage to drop to zero while the rotor flux is changing direction might be the way to fix it?
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
I *think* that's how the V/Hz implementation fixes it. Since throttle controls voltage directly, it's always forced to zero at the exact moment slip flips direction. I still need to look into the voltage spikes that happen during what should be "steady state" too. I assume they're a symptom of a very similar problem. I think in all cases, I'm building up flux in the rotor and not realizing until it's too much.Pete9008 wrote: ↑Sun Jan 22, 2023 5:40 pm Just wondering, is the problem that when the slip changes the rotor flux is still in the old direction (because as discussed above it takes time to change)? The rotor current then starts to drop. When it gets to zero there is no back emf to fight the voltage, the current shoots up and the control loop loses it.
Forcing voltage to drop to zero while the rotor flux is changing direction might be the way to fix it?
Here's probably the best example / simplification of whatever it is I'm doing wrong.
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
As far as I can tell, in regen states there seems to be a 100ms delay between changing voltage and seeing the expected change in current. This doesn't occur in normal motor states. I assume this is related to the motor's ability to provide its own rotor magnetizing current. With that delay, effective control is extremely difficult, so my goal probably needs to be to eliminate it, most likely by forcing the motor into a less efficient state during regen. I'm not certain though.
PS. I'm not certain that I should be testing regen with a below-freezing battery
One thing to note is this particularly interesting segment, where the motor seems to power itself for 250ms while the inverter oscillates between open circuit (which is activated at 0v) and 1 step above 0V.
PS. I'm not certain that I should be testing regen with a below-freezing battery
One thing to note is this particularly interesting segment, where the motor seems to power itself for 250ms while the inverter oscillates between open circuit (which is activated at 0v) and 1 step above 0V.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 349 times
Re: Current control of induction motors
Not too sure I see what you mean there?
If you are serious about trying FOC control then I'd be tempted to try and add the rotor current measurement bits of the FOC implementation to this, just to 'instrument' the rotor. It would be interesting to see if you can actually measure it and if so the results could be enlightening about what is actually happening inside the motor.
If you are serious about trying FOC control then I'd be tempted to try and add the rotor current measurement bits of the FOC implementation to this, just to 'instrument' the rotor. It would be interesting to see if you can actually measure it and if so the results could be enlightening about what is actually happening inside the motor.
- catphish
- Posts: 957
- Joined: Fri Oct 08, 2021 11:02 pm
- Location: Dorset, UK
- Has thanked: 96 times
- Been thanked: 186 times
Re: Current control of induction motors
Which thing specifically? I rambled a lot!
At this point I'm starting to think that my current control approach completely falls down when the motor is also putting energy in. The V/Hz algorithm clearly works though. Just setting slip to 2Hz and changing the sine wave amplitude controls it, so I don't know why i'm having so much trouble in comparison.Pete9008 wrote: ↑Sun Jan 22, 2023 6:24 pm If you are serious about trying FOC control then I'd be tempted to try and add the rotor current measurement bits of the FOC implementation to this, just to 'instrument' the rotor. It would be interesting to see if you can actually measure it and if so the results could be enlightening about what is actually happening inside the motor.
I am tempted to write a real FOC implementation, though I tried and failed to do this once before. I feel like I'm invested in this now though!