Current control of induction motors

Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Current control of induction motors

Post by Pete9008 »

catphish wrote: Wed Jan 25, 2023 9:06 pm 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.
Sorry, misunderstood your post and jumped to the wrong conclusion. Completely agree with your analysis!
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

I've now disabled regen. The current control works very well without it.
noregen-1.png
noregen-2.png
Unfortunately because of the regen instability I don't think this algorithm can represent the long term future of openinverter, but there is a good chance I will use this in my own car as I rarely use regen anyway, and this current control definitely provides better throttle response and smooth low speed operation. I will likely also use it as a base to add DC current limiting to really get the maximum performance out of my car.

I will leave the branch here for anyone else that wishes to experiment with it: https://github.com/catphish/stm32-sine/tree/amp
And here's the diff: https://github.com/catphish/stm32-sine/ ... aster..amp

If anyone does want to try it, here's a quick rundown of the new parameters:
  • throtcur - set this to the number of amps (peak) per % throttle. A value of 5 will give 500A peak AC current and is a sane starting point.
  • imag - the constant magnetizing current. this is the minimum current that should flow in the motor to keep it magnetized, start at 10A, I don't know what's correct here
  • curkp - this is the gain for the current PID. It's rather sensitive. I'm using a value of 2.0 but lower values (around 1.0) may yield smoother results. This is relative to pwm frequency, if using a slower PWM frequency, increase the value (2.0 for 17khz, 4.0 for 8.8khz, etc). I should change the code to scale this better.
  • fslipmax - maximum slip, i use 3.0 on the SDU as normal. This is the slip at 100% throttle.
  • fslipmin - the slip at 0% throttle. Start at zero. There's probably no reason to raise it.
Some other parameters to consider:
  • Always set tripmode=DcSwOn - we don't need any more inverters blowing up because of contactors opening
  • ocurlim - set this 200A above throtcur (ie if throtcur=5, set ocurlim to 700). if it trips, the current control isn't working properly, probably a bad curkp value
  • dirchrpm - I've raised this to 1000. This firmware will smoothly accelerate while rolling backwards, so switching direction at 5mph is safe and encouraged. Just don't do it with throttle applied.
  • regentravel - set this to however much throttle dead zone you want. If your throttle is calibrated properly you can set it to zero for no deadzone.
  • offthrotregen/brakeregen - set these to zero, though the firmware should ignore any attempt to request regen anyway
I will start work on a real FOC implementation my my bench and will start a new thread if I make any progress on that.
yaroslav
Posts: 176
Joined: Tue Aug 13, 2019 4:32 pm
Location: Russia, Stavropol
Has thanked: 14 times
Been thanked: 5 times

Re: Current control of induction motors

Post by yaroslav »

Hi. You can compile the source code. I want to try it in my work too.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

yaroslav wrote: Thu Jan 26, 2023 5:18 pm Hi. You can compile the source code. I want to try it in my work too.
Attached is a binary "5.25.Z-sine" and my SDU parameters. Please ensure you set the parameters as noted above (especially tripmode=DcSwOn and ocurlim).

Also be aware that you may be the first person apart from me to run this code. It works well for me and all safety features are still in place, but I can't be held responsible if it blows up your inverter or sets fire to your dog. If you are happy to try it, I will certainly be grateful for any feedback.

[ATTACHMENTS REMOVED, NEW VERSION BELOW]
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Here's a chart from a real test drive I did today. The current looks a bit noisy, this isn't something you can feel at all while driving, and this may simply be normal noise from the sensors, but I think a slightly lower value of curkp (perhaps 1.0 rather than 2.0) might be needed to prevent this being amplified.

Yellow line is slip, but also directly equals throttle input (0-300).
current-control-2.png
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

So tonight I started reading about field oriented control, and I came across the following scary looking equation:
Screenshot at 2023-01-27 00-12-23.png
Screenshot at 2023-01-27 00-12-23.png (4.62 KiB) Viewed 5172 times
With a lot of help from CollinK I now understand the basics of this. It's a means of calculating the angle of the rotor magnetic field by integrating current (specifically Iq/Id) and adding that to rotor position, which would be needed to do field oriented control.

However, more fundamentally, it says that the rate of change in the difference between rotor angle and rotor flux angle (ie slip) is proportional to torque current divided by magnetizing current. This is important!

It means that for every Hz of slip, we should increase or decrease the torque current proportionally, but keep the magnetizing current the same!

Example:
Torque current (Q) = 20A
Magnetizing current(D) = 2A
Rotor constant = 0.5
Slip = 0.5 x 20A / 2A = 5Hz
Total current = 22A (or maybe it's 20.1A because of the triangle formed by the 2 vectors, it's not really important for today)

My algorithm assumes that slip and current should be proportional, but this isn't quite true. Most importantly, this falls apart them we reach zero torque:
Torque current (Q) = 0A
Magnetizing current(D) = 2A
Slip = 0.5 x 0A / 2A = 0Hz
Total current: 2A (!)

Regardless of the exact numbers, it seems clear that a major problem with my algorithm is that at zero torque request, I am trying to pull the current down to zero, which is:
1) Unnecessary, hopefully the energy cost is negligible, but really at this point i'm more interested in making it respond properly
2) Slow, the rotor doesn't want to instantly demagnetize, so we see lags in current changes, which are much more noticeable at very low slip values when al current is going into the rotor
3) Unpleasant, by forcing voltage below the back EMF, we are causing unexpected current spikes.

In summary, I now think current should be calculated as:
Current = Magnetizing current + Torque current
Current = Id + Iq
Current = [new parameter] + throtcur * slip

and NOT just: Current = throtcur * slip

By maintaining this ratio better, I should be able to obtain even better control at low speed and *maybe* solve the regen problem. That is if I've actually understood correctly...
johu wrote: Sat Jan 21, 2023 10:00 pm 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.
It turns out Johannes already mentioned this but I didn't understand the implications at the time!

This all also explains how field weakening works in the induction motor. Once we run out of voltage, we can increase slip. This increases the ratio of torque current and decreases the ratio of magnetizing current, which I assume in turn reduces back EMF and allows us more speed.

A couple of things to add to this that I need to confirm, which may mean this isn't as simple as I'm hoping:
1) At zero Hz slip, the rotor in fact can't be magnetized because there's nothing to induce current in it. This makes me a little more confused about what's happening here. Perhaps it's not the rotor that we're magnetizing at all but just the space around it.
2) Am I sure the current in the rotor doesn't reverse direction when we enter regen. This question is closely related to (1) and I'm really not sure of the answer.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Small update on tuning: curkp is definitely better at 1.0

There is a problem with DC current estimation. This code is supposed to estimate DC current, but it grossly overestimates it:

Code: Select all

      // Multiply AC current by DC voltage fraction to get DC current
      s32fp idc = ilmax * SineCore::GetAmp() / SineCore::MAXAMP;
      // Divide by sqrt(2) to convert to RMS
      // Multiply by sqrt(3) to convert to single phase
      idc = FP_MUL(idc, FP_FROMFLT(1.2247));
      Param::SetFixed(Param::idc, idc);
This is causing the idcmax limit configured for 650A to actually kick in at only 390A. I'm not sure if:
1) There is something wrong with my calculation
2) The current sensors are wrong
3) The power factor really is that bad right now
MattsAwesomeStuff
Posts: 871
Joined: Fri Apr 26, 2019 5:40 pm
Has thanked: 278 times
Been thanked: 165 times

Re: Current control of induction motors

Post by MattsAwesomeStuff »

Have nothing to contribute, just wanted to cheerlead and thank you for your algorithmic sorcery. I had no idea that this wasn't a settled, polished matter (sine, not FOC). It takes people like you tackling hard problems and sticking with them in deep detail to make progress. I'm even understanding 1/3 of what you're saying and learning little bits and pieces.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

MattsAwesomeStuff wrote: Fri Jan 27, 2023 12:33 pm Have nothing to contribute, just wanted to cheerlead and thank you for your algorithmic sorcery. I had no idea that this wasn't a settled, polished matter (sine, not FOC). It takes people like you tackling hard problems and sticking with them in deep detail to make progress. I'm even understanding 1/3 of what you're saying and learning little bits and pieces.
Thank you very much. Don't assume everything I say is correct! I'm also learning as I go and sometimes just making assumptions and testing them practically :D
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

The car runs very well now, but there are a couple of things still to address:

I've just pushed up idcmax to 950 which will actually limit at around 570A. I'm not really clear what's wrong here, but I wonder if the power factor on these motors is indeed just very low. Not something to worry about right now, except to note that the value needs to be increased above the actual current limit (in my case by a factor of about +66%).

Lowering fslipmax from 3.0 to 2.5 provides a decent amount of extra torque, at the expense of top speed (torque falls off much sooner). Really I need to look at field weakening soon to get the best of both. This is really just a simple matter of increasing slip dynamically when voltage runs out. For now, it's easy to try both and see which you like.

Attached is a SavvyCAN JSON log and graph definition in case anyone is interested in looking at the results from a real drive. This shows short drives including 0-60 acceleration with slip values of 2.5 and 3.0 (charts attached).

I think the thing I'm happiest about here is the throttle response. There is absolutely zero lag between input and response.
Attachments
accel-30.png
accel-25.png
jan27-savvycan.tar.gz
(1.65 MiB) Downloaded 63 times
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Attached new firmware "5.25.Z-sine" and SDU config after today's testing. This now includes a constant magnetizing current imag. I'm not sure what this should be set to, but for now it seems happy running at 10A. It probably needs to be higher, but that's a matter for tuning later.

Amusingly (but correctly) it will magnetize the motor at 10A DC when the rotor speed and torque request are both zero. I will remove the firmware and configs from previous posts to avoid confusion. This one will behave the same as the previous one if imag=0.
Attachments
sdu-27-jan-imag.json
(14.3 KiB) Downloaded 41 times
stm32_sine.bin
(47.25 KiB) Downloaded 47 times
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

So there are now 3 outstanding issues to address:
* Regen - this is officially not happening for now, but I do wonder if the addition of imag mean it's worth trying again at some point.
* Field weakening - we need to be able to add more slip at high speed
* Jerkiness at *very* low speed (see below)

It's come to my attention that when the car is stationary, or very very nearly stationary, individual pulses from the rotary encoder have a substantial impact on the output frequency and hence torque.

To put this into numbers. The SDU encoder is "36PPR". That means we actually get 144 pulses per rotation, or 72 pulses per sine wave (because 4 pole motor). For every 72 pulses we get per second, we increase the output frequency by 1Hz.

We actually sample every 10ms. So dividing by 100 this means for every 0.72 pulses, we increase the output frequency by 1Hz, or more realistically, for every 1 pulse, we increase the output frequency by 1.39Hz.

And I think this is a problem. When holding on a hill (but not 100% stationary), or otherwise driving extremely slowly, the 1.39Hz frequency changes dwarf the commanded slip, and in 10ms increments, this is quite noticeable.

I suspect the solution here is going to be a different type of filtering on the encoder. I see two options:
1) Measure pulses on every PWM loop, with the addition of some type of FIR filter so that an individual pulse from the encoder is considered over a specific period (but longer than 10ms).
2) At low speeds, measure not the number of pulses, but the time between pulses. Switch to counting pulses when the rate becomes too fast to measure.

After writing this out, I remember that Pete and I actually had this conversation last year.
Pete9008 wrote: Sun Apr 17, 2022 6:34 pm Probably be missing something here but you may be able to get better resolution on frequency.

It sounds like at the moment you are counting encoder edges (rising, falling or both?) to work out speed. Instead I would have a hardware timer running in the background and latch the timer value each time there is an encoder edge. A timer interrupt would then use time difference between the last two edges to give a high resolution measure of the speed during the last period accurate down to very low rates. The range of speeds covered is limited at the high end by timer clocking speed and at low speeds by the timer depth but I can't see a 32bit timer not covering the full range. The effectiveness is limited by the accuracy of the encoder (essentially the error on the consecutive edge positions), and it would be worth checking it, but my guess is it would easily be good enough to give a pretty precise speed readings. The other benefit of this approach is that you can work out the exact current position by extrapolating from the last measured edge using the current timer value eiter the last delta or an IIR/FIR filtered version of the historical deltas.

I'd suggest just using rising edges or just using falling edges as I have a feeling that the encoder output won't be precisely 50% duty cycle. If you want better resolution you could use two timers, one for rising edges and one for falling edges and then combine the results.

This does assume relatively slowly changing motor speed but then even rapid changes in motor speed are relatively slow as measured by encoder edges. Also this approach is likely to need floating point division to give good resolution but I'm sure the processor can cope as the interrupt will be fairly low rate.
Now I actually have some hardware I can go back and look at this.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

We actually sample every 10ms. So dividing by 100 this means for every 0.72 pulses, we increase the output frequency by 1Hz, or more realistically, for every 1 pulse, we increase the output frequency by 1.39Hz.
I don't know where I got the above from. This is totally wrong, In fact we sample every every PWM cycle. When we receive a pulse, we instantaneously advance the sine wave by 5 degrees. There is no 10ms averaging. The solutions are the same, but maybe we can make the FIR faster than I realised.

The current code:

Code: Select all

   uint16_t rotorAngle = Encoder::GetRotorAngle();
   slipAngle += slipIncr;
   angle = polePairRatio * rotorAngle + slipAngle;
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Concept for a rotor angle filter. This spreads rotor movements across 256 cycles (15ms) rather than making them instantly. I don't know if this will work. It may be that 15ms isn't long enough period to smooth out the jitter. Conversely, it may be that 15ms is enough delay to harm performance.

Code: Select all

void PwmGeneration::CalcNextAngleAsync()
{
   // Create a sliding window of rotor position values
   static int32_t rotorWindow[256];
   static uint8_t rotorWindowIndex = 0;

   // Calculate the difference between the current rotor position and the oldest
   int32_t currentRotor = timer_get_counter(REV_CNT_TIMER);
   int32_t rotorWindowDiff = (144*256 + currentRotor - rotorWindow[rotorWindowIndex]) % (144*256);
   if (rotorWindowDiff > 72*256-1) { rotorWindowDiff -= 144*256; };
   rotorWindow[rotorWindowIndex++] = currentRotor;

   // Reintegrate into a filtered rotor position. Here a complete revolution is 144*256
   static int32_t rotorPosition = 0;
   rotorPosition += rotorWindowDiff;
   rotorPosition %= (144*256);

   // Scale rotor position to (0..65535) taking into account the 256x oversampling
   uint32_t scaledRotorPosition = rotorPosition * 256;
   scaledRotorPosition /= 144;

   // Integrate slip position
   static uint16_t slipPosition = 0;
   slipPosition += slipIncr;

   // Add rotor and slip position to get the final angle (uint16_t)
   angle = scaledRotorPosition + slipPosition;
}
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

I drove about 25 miles on the new firmware today. All seems good apart from one thing, oscillating at (very) low speed. Initially I'd blamed this on the encoder input, and I think that might still be a factor, but there seems to be a much more serious problem - the weird shaped AC waveforms. I dug deeper into this and have now confirmed that this is *not* a result of my algorithm compensating for errors in the current measurement as I had previously concluded. Here is a chart of current (at about 0.1875Hz frequency), with the amplitude locked and a peak current of 50A. The graph looks almost correct at the start, but that is because the PID is trying to correct it. As soon as I lock the output amplitude, we can see the error clearly.
current-waveform-wrong.png
There are two things wrong here. Firstly, and this doesn't really matter, the commanded slip of 0.1875Hz should result in a wave period of 5.33s. In fact the period is 7.5 seconds. Similarly, a commanded slip of 1Hz gives an output period of 1.06 seconds. This is probably not a problem, but worthy of note.

However, more importantly, the incorrect shape is still present. This causes a substantial oscillation in my total current calculation.
User avatar
johu
Site Admin
Posts: 5683
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: Current control of induction motors

Post by johu »

It looks like the double-humped output voltage of svpwm. Weird. Can you disable svpwm just for checking?
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

johu wrote: Sat Jan 28, 2023 5:00 pm It looks like the double-humped output voltage of svpwm. Weird. Can you disable svpwm just for checking?
Working theory: because the voltage is so low (1100 of 37813) the SVM shift might be interacting poorly with the hardware PWM resolution.

I will add an option to disable it and see it it resolves the problem. Since it serves no purpose at low ampitude, perhaps I can just have it dynamically enable when required.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Current control of induction motors

Post by Pete9008 »

Interesting, maybe it is what I posted about before???

If you disable the space vector stuff do you get clean sine waves?
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Pete9008 wrote: Sat Jan 28, 2023 5:45 pm Interesting, maybe it is what I posted about before???

If you disable the space vector stuff do you get clean sine waves?
I'll test tomorrow without the space vector offset. I'm also wondering if the space vector is a red herring and we jump it because it happens to have a similar shape. Another potential cause is deadtime.

As far as I know, shifting all three waveforms by the same amount is the (or at least one of several) correct ways to do SVPWM, however I wonder if rather than doing it all the time, we'd be better off outputting plain sine waves until we actually run out of voltage, and only shift the waveforms at that point. This would have the benefit of using more of the DC bus voltage, hence giving better PWM resolution, and less impact of deadtime.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Current control of induction motors

Post by Pete9008 »

catphish wrote: Sat Jan 28, 2023 5:54 pm I'll test tomorrow without the space vector offset. I'm also wondering if the space vector is a red herring and we jump it because it happens to have a similar shape. Another potential cause is deadtime.
Agree, disabling it is just a fairly easy test which could rule it out as a possibility.
catphish wrote: Sat Jan 28, 2023 5:54 pm As far as I know, shifting all three waveforms by the same amount is the (or at least one of several) correct ways to do SVPWM, however I wonder if rather than doing it all the time, we'd be better off outputting plain sine waves until we actually run out of voltage, and only shift the waveforms at that point. This would have the benefit of using more of the DC bus voltage, hence giving better PWM resolution, and less impact of deadtime.
It is a very valid way of doing it but it doesn't give perfect waveforms, however, given it's simplicity it's very hard to beat and I very much doubt it's worth doing anything more complicated (I still remember going looking for the SV code and discounting the offset code because I couldn't believing it could be that simple!).

Can't see it doing any harm disabling it till needed, you'd need to be careful with the scaling to make sure you don't introduce a discontinuity when switching though?
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Pete9008 wrote: Sat Jan 28, 2023 6:04 pm Can't see it doing any harm disabling it till needed, you'd need to be careful with the scaling to make sure you don't introduce a discontinuity when switching though?
The way I thought I might do this is simply as follows:

Code: Select all

if(MAX(u1,u2,u3) > AMPMAX) {
error = MAX(u1,u2,u3) - AMPMAX
u1 -= error; u2 -= error; u3 -= error
}
if(MIN(u1,u2,u3) < AMPMIN) {
error = AMPMIN - MIN(u1,u2,u3)
u1 += error; u2 += error; u3 += error
}
This should introduce the offset gradually and only as much as is required.

Another option of course is just to replace the sine wave table with a SVPWM table. I'm not sure why it wasn't done that way originally, but I suspect using a plain sine wave will produce better results at low amplitudes anyway.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Current control of induction motors

Post by Pete9008 »

I was thinking you would need to alter modmax (or whatever the sin equivalent is) but of course you don't, you just run with the full range all the time and just do the shifting when you need to!

A SVPWM wouldn't work for the FOC build as it creates the values directly from Ud and Uq via the inverse transforms.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Pete9008 wrote: Sat Jan 28, 2023 6:48 pm A SVPWM wouldn't work for the FOC build as it creates the values directly from Ud and Uq via the inverse transforms.
I don't think that's a problem. The SVPWM is the absolute last stage before the 3 voltages are output to the PWM timer (after the transformations are complete). They're always modified by the same amount, so it has no impact on the phase-to-phase voltages. As long as FOC uses 3 x PWM, i can't think why it wouldn't work.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Current control of induction motors

Post by Pete9008 »

Have you got a link for that technique, don't think I've seen it?
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Current control of induction motors

Post by catphish »

Pete9008 wrote: Sat Jan 28, 2023 7:24 pm Have you got a link for that technique, don't think I've seen it?
I believe it's called min/max injection. The idea is simply that you can move all three output voltages up or down by the same amount, allowing you a little more modulation within the same DC bus, with no impact on the phase to phase voltages. It's discussed in this paper: https://ww1.microchip.com/downloads/aem ... _guide.pdf
This is what openinverter's sine module uses. Perhaps FOC has a different way to achieve the same thing? I've never looked at that code.

Essentially it doesn't matter how much you move the phase voltages up or down by, as long as it's the same for all 3 phases. From what I've seen, the term SVPWM can mean several different techniques, but they all look the same to the motor.
Post Reply