Current control of induction motors

[Pete9008]

The bit about powering itself for 250ms.

If you do the FOC I think it is worth trying to break it up a bit (getting the whole thing running from scratch is a very tall order). Actually running the motor using another tried and tested controller but with the measurement part of the FOC algorithms running in the background. It should be possible get to a point where half the implementation is working and tested without needing it to have controlled a motor at all. The same measurement part may also shed useful insights into how the controller (the one actually running the motor) is working and how it could be improved.

[catphish]

The bit about powering itself for 250ms.

I just means that despite having zero (or near zero) no voltage applied, the motor continues to push current through the inverter. It occurs to me though that if I completely shut down the inverter, no current will flow, and the field will soon collapse, so this might be a good way to switch directions. I don't know how I'd know when it was safe though.

It seems like I have a couple more ideas to try anyway, to see if this algorithm can be saved. It's annoying because it works so well (at least I believe it does) in non-regen mode.

If you do the FOC I think it is worth trying to break it up a bit (getting the whole thing running from scratch is a very tall order). Actually running the motor using another tried and tested controller but with the measurement part of the FOC algorithms running in the background. It should be possible get to a point where half the implementation is working and tested without needing it to have controlled a motor at all. The same measurement part may also shed useful insights into how the controller (the one actually running the motor) is working and how it could be improved.

This is a great idea. It would even be safe to run such code in the car while driving then analyze it all later.

[Pete9008]

if I completely shut down the inverter, no current will flow

Wouldn't it just go through the IGBT diodes and still be circulating in the motor?

It would even be safe to run such code in the car while driving then analyze it all later.

Exactly, I see it as a way of derisking the FOC approach while also increasing understanding about your current approach.

I don't know enough to comment on the viability of your current approach but do feel you need a better understanding of what the rotor flux is doing to progress. The FOC 'instrumentation' may provide that?

[catphish]

Wouldn't it just go through the IGBT diodes and still be circulating in the motor?

Yes. A few things will happen here. First, as soon as the IGBTs are switched off, any remaining current in the stator windings will continue to flow through the body diodes and into the battery. I'm assuming it won't take long for the battery voltage to exceed the voltage in the windings and the current to stop. After that, with no current flow, I assume the flux in the rotor will also soon dissipate. I'm not sure of the timescales for either of these things though, nor what happens if the motor is running at above battery voltage.

Exactly, I see it as a way of derisking the FOC approach while also increasing understanding about your current approach.

I don't know enough to comment on the viability of your current approach but do feel you need a better understanding of what the rotor flux is doing to progress. The FOC 'instrumentation' may provide that?

Yes, I'm reading a bit more about it now. Fingers crossed.

[johu]

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!

What I like about your current algorithm is that it does not care which exact currents are measured and not even the correct direction -> easier setup. I hope you can get it to work.

As you know FOC has also been a major struggle to get to work so it might be worthwhile to hang in there.

[johnspark]

Do you need to add phase angle of current only during regeneration, i.e. stage 1 stage 2 type controller?

Are you making the calculations as fast and accurate as possible?

[catphish]

Well... I seem to have found a way to work around the problem! I compared the data for the V/Hz and the current control modes, and the obvious difference was that the V/Hz code uses fslipmin at all times, where my code adjusts slip according to torque request and previously did not even have a concept of fslipmin.

So with fslipmax=3 and offthrotregen=-20% I was running 0.6Hz of negative slip. In theory, this is the right amount, but in reality this seems to be the cause of the instability.

I tested with fslipmin=2, fslipmax=3 and the problem was significantly reduced, at fslipmin=3 the problem went away almost completely.

Once I started using fslipmin, I was able to notice a second (and more expected) issue that causes the same effect, very sudden changes between positive and negative torque request. With the higher slip, it became much more noticeable that high throttle slew rates between driving and regen still upset it a little. It's worth noting that because of fslipmin, the *slip* transition is still instant, no matter how slow the throttle moves, but the current request tapers down to zero before coming back up. Looking at the charts, the defining factor that seems to solve the problem is that current much reach zero before starting back the other way.

I will implement a few more code changes now so that I can experiment more:
* Configurable slip slew rate limit
* Configurable current slew rate limit
* Individually configurable fslipmin and fslipmax for forward and regen modes.

One big success here is that I'm seemingly able to control regen all the way down to a stop

NB. this is only tested in axle stands for now.

Attached charts showing acceleration and regen cycles. Note that in one example I came off the throttle excessively fast, and the current did not reach zero before the regen began, causing a small overshoot on the regen current.

[catphish]

Here are closeup examples of good and bad transitions (same graph scale to make clear the slew difference), note in the second example, stator current never reaches zero and hence causes the overshoot as it rises again.

Edit: I wonder if increasing the strength of my PID would fix the second example, as a faster drop in voltage would probably cause a faster drop in current. I haven't done much tuning on it beyond the major fslipmin experiment.

Edit 2: Looking again, maybe the best solution is to set the negative slip (which seems to pull the current down hard) and wait for it to reach zero before allowing the current request to rise again.

[catphish]

One more chart, this is letting the regen run all the way down to a stop (regenrampstr is set to 2Hz to prevent oscillation when stationary). This is an area where I hope this algorithm will improve real driving.

[catphish]

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.

It's quite unusual that a PID controls something where the output is directly proportional to the input. Usually a PID controls a rate of change. For example, a cruise control PID would set throttle position, but throttle position isn't proportional to speed, rather it causes a change in speed over time.

I'm now quite happy that because voltage is basically directly proportional to current, a direct P term is not useful. Instead, I believe it's much more useful that the P term requests a *change* in voltage. The PID output will therefore cause a change to its input over time.

[catphish]

After another day of collecting data and successful tests at higher slip values, I believe I've reached a simple conclusion - the current spikes are caused (after a short delay) by a combination of too much voltage and too little slip.

Going into regen, we were always starting with an excessively high voltage left over in the integrator from when we were accelerating. At first this doesn't seem like a problem, but 100ms later, there is a current spike. When regen starts with the voltage integrator at zero, it's much more stable. I believe this problem can be fixed by forcing the voltage integrator to zero at the zero crossing when slip and current are also zero.

Secondly, it seems clear that regen is more stable when less current is applied, or more slip is used. I previously noted that running it at lower current levels was much more stable (but weak), and today (see charts a couple of posts up) I demonstrated that running it at much higher slip is also more stable, so I suspect that the ratio was wrong. If I'm right, the fix for this is allowing a different Hz/A slip ratio to be configured for regen.

I've written a patch to address both things, and will test again tomorrow. It also allows a minimum slip to be configured. I hope that won't be necessary, but it's useful to have more knobs to test. New code with both potential fixes: https://github.com/catphish/stm32-sine/ ... ne.cpp#L39

Notably:

Code: Select all

      static int torqueDirection = 0;
      if (torque > 0 && torqueDirection != 1)
      {
         torqueDirection = 1;
         amp = 0;
      }
      else if (torque < 0 && torqueDirection != -1)
      {
         torqueDirection = -1;
         amp = 0;
      }

and

Code: Select all

      if (torqueDirection == rotorDirection)
      {
         fslipmax = Param::Get(Param::mfslipmax);
         fslipmin = Param::Get(Param::mfslipmin);
      }
      // If torque direction does not match direction of rotation, use "r" parameters
      else
      {
         fslipmax = Param::Get(Param::rfslipmax);
         fslipmin = Param::Get(Param::rfslipmin);
      }

[catphish]

It's worth mentioning that if you compare my current control to a similar plot of V/Hz control, the V/Hz is also extremely accurate and stable. It's remarkable how well it works. So I just wanted to revisit why I'm doing this. Essentially I want to address the following areas where the current algorithm seems to struggle.

1) When vehicle is rolling backwards and the driver attempts to accelerate forwards. This very low speed regen scenario seems to cause uncontrolled current spikes that lead to sudden ans unpleasant braking.

2) Regen at low speeds. It seems necessary to use regenrampstr to reduce regen at low speeds to prevent excessive regen torque. With the correct value this can be balanced fairly well but it's difficult to achieve consistent braking torque down to near a stop.

3) Implementing limits like temperature and DC current. Because this algorithm can smoothly roll the delivered voltage down when it's above a set current limit, it's my hope that it can be extended to limit in exactly the same way on DC current and potentially also other derates like temperature limits. One big thing I hope to achieve is to be able to run my SDU at its full AC current limit (600A+) from 0RPM right up until the DC current limit becomes the overriding factor.

4) Efficiency. It is my belief that my varying slip continuously with current, we can keep the motor in a more efficient zone at all times, particularly at low torque levels.

Whether I achieve all this remains to be seen, but hopefully i the algorithm works, it will improve some of them. It's certainly the case that (1) is much nicer with this algorithm.

[catphish]

I tested this above code this morning, and it doesn't solve the problem. It's absolutely clear now that some energy remains in the rotor while we switch direction, caused by the really excessive voltage that we apply immediately before the switch.

Compare that to what happens when we force a large minimum slip, which forces the current to be controlled by voltage, and hence the voltage falls, prior to the switch, eliminating the problem.

However, I don't want to keep slip high all the time. I need to find a way to pull down the voltage so that it's not set to *any* value that achieves the desired current, but specifically the minimum value that achieves it.

[catphish]

Just did a short road test with the minimum slip enabled. Regen transition is smooth but the high slip is not good for efficiency, i get only small regen even at reasonably high currents. The high slip also causes some jerkiness at low speed. This certainly isn't how I want to run the controller, but it does work and correctly controls current during both acceleration and regen.

[catphish]

Another day of studying graphs, and I think I'm better starting to understand what's happening here, but essentially I believe Pete9008 is right about this being all about rotor current. The following is speculation, but seems to match what I observe:

Starting with the situation where the rotor is spinning, and no current is flowing in the rotor:
1) We raise the stator voltage until we see the desired current flowing. At this point, the motor is drawing power from the battery.
2) The combines stator current and slip causes a current to start flowing in the rotor.
3) The rotor, now having current, starts to cause a back EMF and changes the phase of the stator current.
4) After a short while, the net flow of energy switches to being motor -> inverter -> battery.
5) The back EMF slightly exceeds the inverter voltage and current rises.
6) The algorithm attempts to reduce the current by reducing the AC voltage
7) This only further increases current until the output voltage reaches zero, essentially a short circuit across the motor which pulls a huge current until the fields collapse or the inverter shuts down

Here's a close up example of this happening repeatedly, at consistent slip. The high frequency oscillations are caused by the output voltage oscillating between 1 (basically a short circuit) and 0 (which shuts down the inverter):

One puzzling question is why the current is proportional to the inverter output voltage in V/Hz mode, when seemingly the opposite should be true. My suspicion here is that the slip used is high enough to weaken the rotor field, and ensure that the back EMF never exceeds the inverter voltage, and hence the inverter is the one controlling the current flow. This explains why my algorithm becomes stable if I increase negative slip well above the point of maximum efficiency. Of course the main reason that V/Hz is stable here is that it doesn't reduce voltage when there is a small increase in current.

The question is how to fix this. For now, I see two immediate solutions:
1) Run higher slip during regen. I'm experimenting with this.
2) Run V/Hz during regen. This is irritating but seems like it would abruptly solve the problem, and might be a lot more stable until we have "proper" FOC.

[johnspark]

Thank you catphish, this is a very interesting subject

[catphish]

So here's another interesting thing that's come up today. Even if one has a consistent positive slip (forget regen), reducing voltage does not necessarily reduce current linearly and immediately. This probably isn't hugely surprising, but what *is* surprising is that current actually rises momentarily when inverter voltage falls below back EMF. Not a huge problem, just another interesting and annoying factor.

Sometimes this effect can be more pronounced.

I've decided that for now I'm going to run things with current control, but using the fslipmin and fslipmax from the V/Hz algorithm. This means in theory I should be able to just control voltage the same way V/Hz does. It actually works quite well, but the relationship between voltage and current can be a little slow and weird at times. Doing this work the right limits on slew will hopefully work.

At around 500ms (0-100% throttle) the algorithm seems pretty effective.

At 150ms things get a bit messy particularly when trying to reduce regen and go back into positive torque.

I now need to work out whether to simply limit the slew, or whether I can work around it more effectively.

[catphish]

I feel like I've got this to the point where is just about works, but I'm not happy with it. The implementation now works, but I don't believe it's safe to use on the road on its current form, at least not with regen enabled.

The reason for this is that the algorithm was built on the fundamental assumption that current could be controller by adjusting voltage. While this assumption clearly works well enough for the current "feed forward" approach, it is not sufficiently true to keep my algorithm stable during regen conditions.

Therefore, I will be doing two things:

Firstly, I will be putting this algorithm aside. However I will be taking away what worked well, and that is the fact that we can use an integrator to smoothly limit current under acceleration. This algorithm will work perfectly well to adjust "throtmax" up and down in small increments when an AC or DC current limit are reached. I believe this "I only" approach will be much smoother than the current "P only" approach in the existing limiters, and can be used with minimal changes to the V/Hz code.

Secondly, now that I have 1ms CAN logging, I can start *really* looking at the voltages and currents in the inverter (see attached). This will allow me to gather the data necessary to consider building a more complete FOC implementation.

Hopefully I can use what I now know to continue to make improvements to the V/Hz implementation while I study the motor in more detail.

[Pete9008]

That's a shame, it was looking promising

As long as you have come out of it with increased knowledge/understanding it's still progress though. Plus the 1ms logging should be very useful!

Edit - I'm curious, what kind of efficiency gains are you hoping for?

[catphish]

Edit - I'm curious, what kind of efficiency gains are you hoping for?

I'm not certain. I don't think we're talking about substantial miles per kwh improvements, it's more about power factor and performance. During my V/Hz tuning, it became clear to me that just because you're running 500A through the motor and inverter, heating them up, doesn't mean you're actually pushing 500A worth of useful energy. By correctly tuning Amps per Hz of slip, I believe we can make the best possible use of the maximum current capacity of the hardware, and at the same time, waste less energy heating up the components.

I was able to substantially improve my V/Hz 0-60 times (within the same AC and DC current budgets) by adjusting slip. I didn't look much at adjusting it for low speed efficiency, but I imagine some small gains can be made there too. With "real" FOC, this wouldn't be an issue, as slip would always be 90 degrees, rather than having to guess a frequency based on current.

[catphish]

I'm looking more closely at these voltage-current charts, and something is amiss! This is not a happy shape for a current sine wave!

Not sure if I've messed something up with my changes.

Edit:
Looks like a small offset in the current sensors is causing the total calculated current and hence the output voltage to oscillate so this is a "me" problem

It goes away once the current is significant.

[Pete9008]

Think that is just the space vector modulation (gets an extra 15% amplitude by shifting the zero point around). Or do you mean the bit around the zero crossing? If so then that possibly be a little oscillation in the slip calculation.

Edit - ignore me, it shouldn't be there in the current waveform too! No idea what that is

Edit2 - Wondering if it's due to the way the space vector bit is done. It doesn't add a true third harmonic, instead it shifts the waveform. Wondering if the small errors introduced get amplified somehow by the motor impedance?

[johu]

With "real" FOC, this wouldn't be an issue, as slip would always be 90 degrees, rather than having to guess a frequency based on current.

FOC by itself doesn't optimize there. If you feed an induction motor pure q-current it will not move at all as you need d-current to magnetize the rotor. So similar to MTPA for PM motors you need an algorithm on top of FOC that decides on a wise d/q split and a slip calculator that derives slip from d/q and some motor parameters. Way back in the tumanako project they had worked out some basics, like here: https://github.com/tumanako/tumanako-in ... lipAngle.c

[catphish]

Think that is just the space vector modulation (gets an extra 15% amplitude by shifting the zero point around). Or do you mean the bit around the zero crossing? If so then that possibly be a little oscillation in the slip calculation.

Edit - ignore me, it shouldn't be there in the current waveform too! No idea what that is

Edit2 - Wondering if it's due to the way the space vector bit is done. It doesn't add a true third harmonic, instead it shifts the waveform. Wondering if the small errors introduced get amplified somehow by the motor impedance?

I'm pretty sure the problem here is that a very small offset in one of the current sensors causes my calculation of RMS current to oscillate a little. The current control algorithm tries to correct it, causing an oscillation that matches the frequency. It's really only noticeable at very low frequency and amplitude.

I was originally concerned it might have been a problem with the SVPWM output, but that's so simple there's really nothing to go wrong, so I found the problem elsewhere. It only exists in my new code, so nothing to worry about.

[catphish]

FOC by itself doesn't optimize there. If you feed an induction motor pure q-current it will not move at all as you need d-current to magnetize the rotor. So similar to MTPA for PM motors you need an algorithm on top of FOC that decides on a wise d/q split and a slip calculator that derives slip from d/q and some motor parameters. Way back in the tumanako project they had worked out some basics, like here: https://github.com/tumanako/tumanako-in ... lipAngle.c

i believe you're correct. My understanding is that the D current can just be a constant amount to correctly magnetize the rotor, and then Q can be controlled directly according to desired torque. The (VERY) hard part is estimating the angle of the rotor field though. Once you know that, everything else falls into place.