Field oriented control of induction motors

[catphish]

THIS THREAD HAS BECOME ABOUT FOC OF INDUCTION MOTORS STARTING ON PAGE 2

Hello again! Today I had another thought about current control, and I thought I'd make a new thread to introduce it.

As demonstrated in my other thread, we can simplify the control of induction motors by controlling current and avoid worrying about the V/Hz curve. The algorithm did this by assuming total 3 phase current could be increased by increasing voltage, and decreased by decreasing voltage. This worked well, but two problems remained:

1) We always output a voltage sine wave, but the resulting current is not always a sine wave. It has unwanted harmonics.
2) During some transient states, and in particular during regen, this algorithm cannot maintain control because decreasing voltage does not decrease current, and sometimes even increases it.

I have a new proposal that has the potential address both of these problems. Instead of calculating the total absolute current in the system, we control current individually per phase.

The major difference here is that right now total current can only ever be positive (because it is the sum of squares of phase currents), but in reality, individual phase current can be either positive or negative. This gives us a much greater ability to correctly identify the direction of unwanted current flow and oppose it.

This would work as follows: we take the desired current magnitude and phase (ie current request and sine angle) and use this to calculate three individual target currents, one per phase (inverse Park Clarke).

Next we measure each phase current and compare it to the desired phase current, and apply a per phase correction. This could be achieved one of two ways:

1) Apply a correction to the PWM value in each PWM loop.
2) The nuclear option - run the loop at a MUCH higher speed, eliminate PWM, and switch the phases manually on every loop (similar to Direct Torque Control)

I will try this on my bench when I get a new bench power supply, as mine got a bit exploded last week.

[catphish]

I believe the biggest risk here is that such a feedback algorithm may be too slow or too inaccurate compared to the existing feed-forward approaches. If this proposed algorithm fails for that reason, it may still be useful to see the per-phase errors and consider them as part of the existing feed-forward calculations.

[johu]

Looks like you're heading towards FOC

[catphish]

Looks like you're heading towards FOC

The truth is I'm doing everything I can think of to avoid actually doing rotor flux estimation. From time to time I read papers and watch video tutorials about it, but I still don't understand it. So in the meantime I'm just trying to come up with the best "slip control" algorithm I can.

[catphish]

Help! I'm trying to implement the Park Clarke transformations on my data to get an initial two-dimensional representation of my current with respect to voltage angle.

I am using the FOC module in openinverter as it implements the necessary calculations, but the output is nonsense.

I've put together a spreadsheet to highlight what's going on. I'd be grateful if someone could have a look and tell me where I'm going wrong.

The spread sheet does the following:
* Generates 3 phase voltage outputs
* Calculates current (as if there was a simple resistive load)
* Does a Park and Clarke transformations on the result

Unfortunately, things just don't seem to add up. If I swap the ia and ib measurements, things look a little saner (see sheet 2), but I was rather expecting either id or iq to be zero.

I'd appreciate any insight into what I'm dong wrong here!

[catphish]

Update: If I feed -i1 and -i3 into the transform, instead of i1 and i2, I get the expected result (see updated spreadhseet). But why?

[Pete9008]

Using Ia and Ic into the Park transform also works (Id=0, Iq=3). Need to find a phasor diagram to see which phases are supposed to lead and which lag to see which it should be.

Edit - U2 should lead U1, you have it the other way round (U2 lags) so using U1 and U3 corrects this.

Edit2 - sorry, you have U2 leading. Not completely sure what the problem is but it's something to do with the relative phase of the two phases going into the Park transform.

Edit3 - see https://www.mathworks.com/solutions/ele ... forms.html for a graphical representation. The voltage sequence for maximums should be U1, U2, U3, you have U1, U3, U2. Swap U2 and U3 and everything works.

[catphish]

Edit3 - see https://www.mathworks.com/solutions/ele ... forms.html for a graphical representation. The voltage sequence for maximums should be U1, U2, U3, you have U1, U3, U2. Swap U2 and U3 and everything works.

Thank you. This makes a lot of sense. The V/Hz firmware calculates the voltage outputs like this:

Code: Select all

    sine[0] = SineLookup(angle);
    sine[1] = SineLookup((angle + PHASE_SHIFT120) & 0xFFFF);
    sine[2] = SineLookup((angle + PHASE_SHIFT240) & 0xFFFF);

Now that I think about it, I realize this produces the reverse of the expected phase order. It's pushing phase 2 ahead of phase 1 rather than lagging it behind.

[catphish]

If I reverse the phase order (so that i1 leads), everything now adds up, except that the final result is negative. I'll check the link provided.

Edit: If I offset everything by 90 degrees I get the results I'd actually expect. So changing the voltage output like this should un-confuse things:

Code: Select all

    sine[0] = SineLookup(angle + PHASE_SHIFT90);
    sine[1] = SineLookup(angle + PHASE_SHIFT90 - PHASE_SHIFT120);
    sine[2] = SineLookup(angle + PHASE_SHIFT90 - PHASE_SHIFT240);

[catphish]

This is now working. By applying Park and Clarke to the measured current using the angle of the voltage as the reference angle, we can obtain some new data. I believe the id and iq values in this case represent inphase, and reactive current respectively. Here's a excerpt from a basic bench test showing forward acceleration, followed by two reversals of the torque direction (and as a result rotor direction).

The inphase current (brown) shows a positive value during acceleration and a short negative period (regen braking) during the direction change. The direction of the reactive current (neither positive or negative, since it's at a tangent to voltage) depends on the rotor direction.

I'm not sure if this is useful, and it's a slightly different direction from what I was planning, but it's interesting to have another view of the data.
It seems I now have three possible directions I can go in to attack current control:

1) Calculate per-phase targets as planned. My main worry here is that there will be no feed-forward with this approach. Individual phase currents change much faster than any other metric, so I'd need a much tighter control loop.
2) Translate the measured phase currents into amplitude and angle rather than just amplitude. This gives me two corrections that can be made rather than just one.
3) Use the id and iq data (inphase and reactive current), and attempt to make corrections to those. This is essentially a variation of the amplitude-angle model, but probably an easier one to work with mathematically.

The part I need to get my head around is what targets to set, and what corrections to make to reach those targets.

[catphish]

I loaded the inphase and reactive current logging firmware into my car today and went for a drive. Here are some results.
Hard acceleration 0-60

Steady driving 50% current

Very low speed creeping

Regen (selected by changing slip direction with selector while rolling)

Some of this data makes a lot of sense to me. Some of it less so

[Pete9008]

Interesting results but I must admit I'm struggling to see where you are going with this (which is why I haven't commented previously).

As far as I can tell you have invented a new and novel way of measuring the real and imaginary power going into a 3-phase motor??

The transforms look like they are working well now.

[catphish]

Interesting results but I must admit I'm struggling to see where you are going with this (which is why I haven't commented previously).

You are correct that I have no idea where I'm going with this, but I'll try to explain how I got here!

At the moment, we generate three phase voltages at a desired frequency, and I wanted to work out how I might get from that starting point, to instead directly controlling current.

The first question I had was how the phase currents differed from the phase voltages. It seemed that the best way to represent this was with two-dimensional plots. Then, rather than having to plot two-dimensional voltage, and two-dimensional current separately, and try to compare them, I decided to rotate the current measurement by the voltage angle to create a two dimensional plot that directly represents the two-dimensional difference between commanded voltage, and measured current.

On the topic of current control, when it's time to make my three sine waves into current targets rather than voltage outputs, I hoped this data might give me clues about how best to modify the voltage and frequency outputs to achieve a desired current. The obvious approach to current control is still to measure each current, then output a voltage correction on each phase accordingly, but I wondered if this might offer ways to make the same corrections but in a rotating reference frame with much less gain.

However, while this isn't really what this thread was supposed to be about, but I got super interested in this real/imaginary power plot, for a couple of reasons, most notably because if there is an optimal balance between real and imaginary power, I thought I might be able to adjust slip automatically to achieve it, giving optimal results at any speed without the need for manually configured slip limits.

Ultimately, I feel like the more ways I find to examine the data, the more I will understand the operation of the motor.

As far as I can tell you have invented a new and novel way of measuring the real and imaginary power going into a 3-phase motor??

Yes, this is probably an unnecessarily obscure way to measure this, rather than just multiplying the voltage and current on each phase. It's just where I ended up when I started trying to look at current in the rotating reference frame.

I found a couple of papers on controlling induction motors on the basis of real and reactive power:

https://digitalcommons.lsu.edu/cgi/view ... ool_theses

https://www.researchgate.net/profile/Re ... ion_detail

Ultimately, these seems to be a correlation between slip, and the ratio of these currents, so understanding how they behave may be beneficial. I don't believe this necessarily helps with the problems I was trying to solve though. Just an interesting tangent!

[Pete9008]

On the topic of current control, when it's time to make my three sine waves into current targets rather than voltage outputs, I hoped this data might give me clues about how best to modify the voltage and frequency outputs to achieve a desired current. The obvious approach to current control is still to measure each current, then output a voltage correction on each phase accordingly, but I wondered if this might offer ways to make the same corrections but in a rotating reference frame with much less gain.

I can't help but think that this is the way you will end up doing it. Which reference frame it is best/easiest to do it in is a very good question (and I haven't a clue)!

However, while this isn't really what this thread was supposed to be about, but I got super interested in this real/imaginary power plot, for a couple of reasons, most notably because if there is an optimal balance between real and imaginary power, I thought I might be able to adjust slip automatically to achieve it, giving optimal results at any speed without the need for manually configured slip limits.

Ultimately, I feel like the more ways I find to examine the data, the more I will understand the operation of the motor.

Doing something just because it might help understand the system is an excellent reason in my book

I found a couple of papers on controlling induction motors on the basis of real and reactive power:

https://digitalcommons.lsu.edu/cgi/view ... ool_theses

https://www.researchgate.net/profile/Re ... ion_detail

Ultimately, these seems to be a correlation between slip, and the ratio of these currents, so understanding how they behave may be beneficial. I don't believe this necessarily helps with the problems I was trying to solve though. Just an interesting tangent!

With zero (unachievable) slip the Iq and Id you calculate are actually correct for the rotor field. As the slip increases the vector rotates and more current appears to be transferred from d to q. So, as you say, the ratio could be thought of as a way of measuring slip.

Very interested to see where this ends up going.

EDIT - just twigged what the ripple on the Iq and Id plots is, it's the 5th harmonic distortion isn't it! That would mean that if you use Iq and Id in the control loops it should still eliminate the harmonic content (and avoid the three individual phase current controllers from fighting each other which is something that's been bothering me). I think you may be on the right track here

[catphish]

Here's my initial attempt at realtime per-phase current control: https://github.com/catphish/stm32-sine/ ... #L86..L118

Here's what the result looks like on the bench at low frequency:

And high frequency:

And here doing a sudden direction switch (peak target current set to 50A):

High frequency oscillations can be seen when operating at low frequency. Clearly some more work is needed, but it's looking promising so far.

Edit: Just to clarify, waveforms aside, the motor appears to run perfectly / smoothy but with no load, this is only a very rudimentary test.
Edit2: It's worth noting that I've increased the frequency the calculation runs from 4.4kHz to the full 17.6kHz. I wonder if it would be worth doing the same on my main current control branch.

[catphish]

I think tomorrow I will re-run this test with an oscilloscope attached to the current sensors so that I can see what the waveform really looks like (ie better than 1ksps resolution). I will also look at plotting the voltage output for comparison.

It seems my gain is probably a bit too high, hence the oscillation, but I suspect this may actually be improving high speed performance as the overshoot becomes "predictive" at higher slew rates.

[Pete9008]

Looking good!

One other thought I had yesterday, triggered by your comment on real/imaginary ratio and slip - would it be possible to use the ratio instead of slip? Essentially calculate a total current Is from the torque demand, calculate the real/imaginary ratio the way you currently calculate target slip and then use the two to calculate target Id and Iq. Accel/regen controls the polarity of whichever component it was that changes sign in the above plots (edit - reactive or Iq).

The rest of the code can then be virtually the standard openinverter permanent magnet FOC implementation! (measured current through Park/Clarke, compare to target Iq/Id with error output controlling uq and ud, inverse transform and output to pwm) That by itself should help with low speed harmonics but it should also be straightforward to add the AFC algorithm you found to fix it at high freq too.

[catphish]

Looking good!

One other thought I had yesterday, triggered by your comment on real/imaginary ratio and slip - would it be possible to use the ratio instead of slip? Essentially calculate a total current Is from the torque demand, calculate the real/imaginary ratio the way you currently calculate target slip and then use the two to calculate target Id and Iq. Accel/regen controls the polarity of whichever component it was that changes sign in the above plots (edit - reactive or Iq).

The rest of the code can then be virtually the standard openinverter permanent magnet FOC implementation! (measured current through Park/Clarke, compare to target Iq/Id with error output controlling uq and ud, inverse transform and output to pwm) That by itself should help with low speed harmonics but it should also be straightforward to add the AFC algorithm you found to fix it at high freq too.

I believe what you're describing is essentially classic induction motor field oriented control. The elephant in the room though is that you still need an estimated rotor field angle as the basis for all the calculations.

I did try this before, assuming the field angle to be the rotor position, plus the integral of Iq/Id, and then controlling the two components individually using the existing openinverter FOC code.

It didn't work, but I think now that I've spent more time understanding the calculations (and realising that the current sensors of my Prius inverter don't match the order of the phases as I thought they did), I think it has a chance of doing so.

Perhaps I'll have another stab it it as follows:
* Calculate Is based on torque demand
* Calculate Iq and Id in appropriate ratios to achieve Is - there's still a lot of guesswork here, ideally one will be reasonably constant while the other commands torque
* Calculate slip based on Iq and Id, then estimate rotor field position as: rotor position + [arbitrary constant] * integral (Iq / Id)
* Feed angle, Iq and Id into FOC implementation to control uq, ud, and ua,ub,uc
* Pray

This method of estimating field position is very rudimentary, based on on assumption that you touched on, that slip is proportional to the ratio of Iq and Id , so it will remain to be seen whether it's good enough.

Please let me know if this isn't what you were thinking.

[Pete9008]

Not quite what I was thinking although your approach has benefits too, particularly as a way of rotor current estimation.

On re-reading the above not sure I explained my idea too well. I'm not proposing to change any of the bits that currently calculate the motor angle so that bit would still use the encoder speed and target slip to work out the angle at the start of each loop (I'm assuming that this is how it works, afraid I haven't been through the sin code in any detail). You then use this angle and the measured phase currents to do the Park/Clarke transform to get Iq and Id (or Ii and Ir?) as you did in the above examples. It's the voltage control side that then changes. Instead of using the magnitude of the total current error to drive voltage amplitude you calculate target Ii and Ir based on the above post and then use the error between these and the transform output (plus possibly the AFC error terms) to get Uq and Ud (or Ui and Ur). These then go through the inverse transform to get the pwm values that are output.

The above does assume that the ratio varies in a nice way with slip (linearly would be nice to make the maths easy!) and I've no idea whether this is actually the case but your plots did suggest that it might be.

Edit - corrected typos.

Edit2 - No idea if the above will work or not, just thought it an interesting possibility!

Edit3 - I do like your idea for rotor field estimation! Not sure whether the integral is needed and an inverse tan to get the angle might work better than the ratio?

[catphish]

As far as I can tell you have invented a new and novel way of measuring the real and imaginary power going into a 3-phase motor??

Thinking about this again, I worry that if I am taking *very* complicated road to a very simple solution. Instead of all of the above, the exact same result could likely be achieved much more simply as follows:

1) Multiply phase currents by phase voltages to calculate real power (P) and reactive power (Q). Doing it this way gets us an exact value with way less calculations.
2) Run a PID on P and Q.
3) Tie the pid outputs to sine frequency and sine amplitude

An increase in frequency has the same effect as an increase in votage perpendicular to the voltage vector.
An increase in voltage has the same effect as an increase in voltage parallel to the voltage vector (obviously).

Unless, I'm mistaken, this should achieve the same thing, but with no transformations. It will also keep itself synchronized and potentially avoid having to calculate slip at all, and it could be scaled dynamically. If it worked well enough, I don't even see why we'd need to measure rotor speed, but I might be getting ahead of myself there.

The only thing I need to think about is whether the *direction* of the reactive current can be calculated this way, and whether it matters. But I've already proven that the FOC code can calculate this, so it's conceivable that I use the FOC code to calculate the P and Q currents, then use frequency and voltage to correct them.

[Pete9008]

I think we are thinking pretty much the same thing but from slightly different viewpoints and using slightly different language

It always surprises me how many different ways there are of viewing/explaining the same solution/problem/implementation, it's all about finding a description that the user is comfortable/familiar with. I prefer the Park/Clarke view but that's probably just due to my familiarity with it. It would also be nice to have the sin and FOC implementation converging rather than diverging!

Edit - the need for a slip angle in the calculation is confusing me. Last night I was thinking it could be lost in the real/imaginary bit, as you are describing now, this morning I convinced myself that it was still needed. Right now my brain has given up for the day and I don't have a clue!

[Pete9008]

But I've already proven that the FOC code can calculate this, so it's conceivable that I use the FOC code to calculate the P and Q currents, then use frequency and voltage to correct them.

This 'feels' right to me but can't quite explain why.

[catphish]

I just found the best explanation yet of how to do this properly!

Basically, this whole page, but the good stuff specifically:
https://imperix.com/doc/implementation/ ... ux-control
and
https://imperix.com/doc/implementation/ ... rientation

For the first time, the maths actually makes sense to me, I guess the page explains it using nice small words! Perhaps I should stop beating about the bush and just implement FOC properly. Each piece of the puzzle I understand is gradually leading me to it.

For anyone reading along, and to Pete especially, sorry for the rambling nature of this venture, but hopefully it's going somewhere useful.

[Pete9008]

Absolutely nothing to be sorry about, just interested to follow along! I've learnt more about induction motors from following your threads than from trying to read papers.

Speaking from the IPM motor side, for ages I found it incomprehensible and then suddenly it all clicked and from that point on the FOC approach seemed both elegantly simple and very powerful. Unfortunately the induction motors add another layer of complexity on top but I'm sure you will find the same will happen and it will all click. I have no doubt at all that you will end up producing a fully working algorithm.

That paper does look a lot less impenetrable than all the others, good find!

[catphish]

Absolutely nothing to be sorry about, just interested to follow along! I've learnt more about induction motors from following your threads than from trying to read papers.

That paper does look a lot less impenetrable than all the others, good find!

Thanks! I'm going through it properly now. One thing I don't seem to be able to comprehend is how one gets from equation (9) to (26).

(9) makes perfect sense to me, and converges as expected to (11). However I don't understand where "s" same from in (26), and why it seems nothing like (11).

Pointers appreciated if you're better then me at decoding such things.