Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[thingstodo]

Originally Posted by MPaulHolmes

Yes! Well, what I have been doing is, when there is a gross violation of the clamping (VdClamped - Vd) > 100, knock down the commanded Id by 100. As if giving it another chance, allow the "commanded" current crawl back very slowly to the ACTUAL commanded current. If there's another violation of Vd or Vq, tar whoop them again!

The process needs to be cleaned up, but that has worked best. Another way is, I think I need to find the relationship between Id, Iq and RPM and load for all possible values (for a given AC voltage). Because that wouls be difficult, I'm trying to be content with only using Vd, Vq, Id, and Iq, since I have those.

Did you get the code posted to the WIKI?

Please excuse my thinking-while-typing style. I don't think that this method is any better than what you have already, except maybe using a variable instead of a constant 100 for subtracting from Id?

- would it make sense to clamp by limiting the PI output? I dislike having variables calculated in more than one location, but that's all I could think of.

Note really a quote, but I wanted it indented

ShouldBeClamped = Kp*error + Ki*sumOfErrors;
if (ShouldBeClamped)>VdClamped /* this is too high, limit
{
sumOfErrors=(Vbus-(Kp*error))/Ki; /* calculate sumOfErrors
Id = Id - IdLimit; /* change Id so it can ramp up again
/* next time around
}

newVd = Kp*error + Ki*sumOfErrors.

How I think it works:

knocking down Id by 100 limits sumOfErrors
so the calculated Vd is lower
that's how you reset the I term of th PI loop, allowing it to ramp up again

But it's still bouncing off the high limit, and it still affects Vq. Unless your VdClamped leaves some headroom for Vq so the vector sum does not affect Vq very much.

I just added a variable instead of subtracting 100 from Id. Does this do the same thing you are doing already?

[MPaulHolmes]

I think that was the same thing.

A change I just made that actually worked really well was to only update the new PWM when Vd and Vq clamp difference is zero. I mean, why change the 3 pwms if you know they will change Id and Iq in a discontinuous way in the wrong direction? it didnt work to use zero when updating PWMs regardless of clamping value. I was able to go as low as -25 instead of -100 after each violation. much below 25 caused overcurrent trips.

Your 'let the motor run' and see how fast it goes or change direction thing worked perfectly for finding what must be the rotor time constant. there is a global maximum for rpm at the rotor time constant when you allow possible time constants to vary across the range.

So, what we can do is,, in a test mode, lock the rotor, tune the PI loops for Id and Iq (ebrake on), and then in neutral, let it run through all rotor time constants for a sec each or so and the highest rpm candidate wins. the time can be so short that the rpms are very small. like less than 100. Then we have every characteristic we need. easy peasy! save those values, and you are done.

[freebeard]

Note really a quote, but I wanted it indented

vBulletin supports CODE, it just doesn't have a button for it:

ShouldBeClamped = Kp*error + Ki*sumOfErrors;
if (ShouldBeClamped)>VdClamped /* this is too high, limit 
{
sumOfErrors=(Vbus-(Kp*error))/Ki; /* calculate sumOfErrors
Id = Id - IdLimit; /* change Id so it can ramp up again
/* next time around
}

newVd = Kp*error + Ki*sumOfErrors.

If lines aren't wrapped you get a horizontal scroll bar.

[e*clipse]

I'm trying to step back from the problem; perhaps by looking at it another way, a solution might appear. First qualification: I don't understand how induction motor slip plays into all of this; I'm only thinking of a generic control scenario.

My "Art of Electronics" bible for electronic stuff has an excellent explanation of how a transistor works - perhaps the concept can be extended here. The authors imagined "transistor man" - a guy who's given the command to allow some current to flow through the transistor. It's given in the form of a guage that displays a lower current, and he has to adjust stuff (whatever - we don't really know the technical details) to match the output current to the commanded current. Of course there are some hard realities involved with the process - there is a limit to how much current "transistor man" can let through the transistor without breaking something and there's also a limit to how much current can flow due to external circuit details.

OK. Now, imagine you have two "motor men" who can adjust stuff ( in this case the amount of voltage and it's timing ) to match the motor's output to the commanded value.

The first reasonable question is "what is the commanded value?" What does the potentiometer's 0-5v input mean? Is it torque? Is it speed? In an IC car, the throttle represents torque, not speed. This is a pretty important distinction,because the car will perform much differently with the same throttle position depending on whether the car is on a hill or not.

It's much easier for a control system to match a torque request than a speed request. The main problem is that measuring torque is more difficult than measuring speed. So, you may be thinking of the potentiometer as a speed request, and how well the motor matches this speed as a measurement of the control system's success. This is all fine as long as there is plenty of resources to draw from (voltage and current) as well as few things to cause problems (like extra drag, inertia, or back-EMF).

Requesting a speed could run into two issues - too much physical drag (car on a hill or with a big head wind) or the motor's back-EMF fighting the supplied voltage. When the problems start to overwhelm the resources, then the "motor men" start fighting to grab all the resources they can. This appears to be the root of your Id Iq problem.

However, one option (that might seem like a cop-out) for controlling a EV is to say "hey, I have another controller in this loop - the driver of the car." Maybe the driver can do something to deal with the speed control issue, and let the "motor men" deal with stuff like torque control so they can stop bickering... We're all used to this - the hill gets steeper, we push on the "go pedal" more. If we're aware of the issues involved, we may watch our resources - how hot is the motor getting?. In this case, it might be better to compromise and go slower rather than burn up our motor.

So, it's possible to make a control system that will match a requested speed, but generally it will require a lot more information to deal with the dynamic variables involved with it's implementation.

-E*clipse

Originally Posted by MPaulHolmes

yes. you sure can write it that way. i hadn't thought about it. i had always just thought of it as multiplying the rps by 16 for more resolution. so, about 2400 RPM.

high rpm and field weakening have been a challenge, with some surprises. The PI loops were tuned very fast, which means huge voltage swings to get the current to match the desired current. The problem is, at 72vdc on that motor, at around 390 Rev/ (16sec), if you are commanding the torque and field components to be some fixed value, you run out of voltage. If you still insist on holding them constant, the PI loop blasts the Vd and Vq voltages to kingdom come. They of course have to be clamped, and transformed back to the 3 phase voltages, and theres the problem. unfortunately you can't clamp Vd and Vq separately. you have to clamp the distance of 《Vd,Vq》to the origin. So, when Vd goes stupidly big (like a jump from 800 to 6000), Vq wants to be left alone, holding the torque component constant at, say, 800. but now we have to clamp the distance 《6000, 800》to a radius of 1729 (that happens to be the radius). that means the new value of 《Vd,Vq》 is something like 《1700,220》. well, through no fault of his own, the torque component was cut way down. But the torque component PI loop is still trying to force Iq back to what was commanded (say, 800). So, you get angry fighting between the torque and field, trying to hog all available voltage so their respective current can be the commanded value. so the field is all over the place, and so is the torque component. this does not make for a very smoothly sounding motor when that happens!

So, I was trying various things so hitting the rpm ceiling doesn't cause a problem. Now this is like 50VAC on a 480VAC motor, so of course it would have an issue of running out of voltage. But it would be nice to deal with the high rpm case all the same. Here is what I have tried:
reduce Id linearly from rpm1 to rpm2. That works OK, but needs to depend on Iq too.
Each time a clamp is about to happen, reduce the clamped variable's current commanded value. That works really well, but it needs to be fine tuned.

[Astro]

Originally Posted by MPaulHolmes

Yes! Well, what I have been doing is, when there is a gross violation of the clamping (VdClamped - Vd) > 100, knock down the commanded Id by 100. As if giving it another chance, allow the "commanded" current crawl back very slowly to the ACTUAL commanded current. If there's another violation of Vd or Vq, tar whoop them again!

The process needs to be cleaned up, but that has worked best. Another way is, I think I need to find the relationship between Id, Iq and RPM and load for all possible values (for a given AC voltage). Because that wouls be difficult, I'm trying to be content with only using Vd, Vq, Id, and Iq, since I have those.

If you had all possible values Id, Iq and RPM would it be able to be represented by a best fit formula?

What if the knockdown value was simply linked to the RPM.
knockdown = RPM / 100
So that at higher RPMs the knockdown was more aggressive.
Actually this might result in negative values for the commanded Id.
Maybe work out the percentage the current RPM is of the motors maximum RPM.
Then knock down the commanded Id by the same percentage.

[thingstodo]

Originally Posted by e*clipse

However, one option (that might seem like a cop-out) for controlling a EV is to say "hey, I have another controller in this loop - the driver of the car." Maybe the driver can do something to deal with the speed control issue, and let the "motor men" deal with stuff like torque control so they can stop bickering... We're all used to this - the hill gets steeper, we push on the "go pedal" more. If we're aware of the issues involved, we may watch our resources - how hot is the motor getting?. In this case, it might be better to compromise and go slower rather than burn up our motor.

As I understand it, that's what is being done already.

The setpoint is a torque request, which is translated into Id and Iq. Vd and Vq are set based on what current you want. And current is proportional to torque (I know that's a simplification for the AC case ... but I think it helps the explanation)

Or perhaps I'm off base here. In order to set the current, I thought you had to keep increasing the speed until the output torque (current) is where the setpoint (accelerator pedal) asked it to be?

[thingstodo]

Originally Posted by MPaulHolmes

A change I just made that actually worked really well was to only update the new PWM when Vd and Vq clamp difference is zero. I mean, why change the 3 pwms if you know they will change Id and Iq in a discontinuous way in the wrong direction? it didnt work to use zero when updating PWMs regardless of clamping value.

Cool. Don't update the output if it doesn't make sense ... who'd have thought?

I was able to go as low as -25 instead of -100 after each violation. much below 25 caused overcurrent trips.

Will the constant have something to do with the processor speed? I'm not comfortable with hard-coding constants since a brief problem with video games on the original PC (8088 @ 4.77 Mhz) ... made my games run too fast to play on a clone (8088-2 @ 8 Mhz) ... but perhaps I'm paranoid!

So, what we can do is,, in a test mode, lock the rotor, tune the PI loops for Id and Iq (ebrake on), and then in neutral, let it run through all rotor time constants for a sec each or so and the highest rpm candidate wins. the time can be so short that the rpms are very small. like less than 100. Then we have every characteristic we need. easy peasy! save those values, and you are done.

Sounds like an easy calibration procedure. With the motors that people are likely to drive with this large controller, a limited amount of power sounds like a good idea. The test would be messed up if the motor over-powers the brakes, right? How many amps (perhaps a percentage of rated current?) would you need for the locked rotor test?

[e*clipse]

Originally Posted by thingstodo

As I understand it, that's what is being done already.

The setpoint is a torque request, which is translated into Id and Iq. Vd and Vq are set based on what current you want. And current is proportional to torque (I know that's a simplification for the AC case ... but I think it helps the explanation)

Or perhaps I'm off base here. In order to set the current, I thought you had to keep increasing the speed until the output torque (current) is where the setpoint (accelerator pedal) asked it to be?

Ok, you're right. - It is the current that is being measured and compared to the request value. I was looking at the photobucket graph of convergence and screwed up.

Again, I think part of my misunderstanding is directly related to the induction motor. In an induction motor, the rotor's current is proportional to the slip - right? So more slip, then more rotor current, which produces the rotor's field, which interacts with the rotating stator's field to finally produce some torque . . . right?

A analogy may be how an unloaded ac induction motor responds when it is first plugged into a 60hz wall socket. Initially the rotor is at zero rpm and the field is rotating at full speed. The current (and torque) is at a maximum because the slip is at a maximum. As the motor speeds up, the slip decreases and the torque decreases. Eventually the motor gets close to the field speed, but will never match it because there always needs to be enough slip to keep the rotor spinning and overcoming the drag in bearings, the fan, etc. The torque curve starts with HUGE spike (limited by winding resistance, inductuance, etc.), then settles to near zero, while the speed curve gently approaches a value close the the field speed. All this happens relatively slowly, as it generally takes a couple of seconds for an induction motor to come up to speed.

So, in a way, the torque is somewhat speed related - I'm trying to clarify - I'm NOT saying that speed is the control request. The problem Paul is running into is that at high speeds, control gets more difficult and rough. I'm guessing here, but physically what may be happening is that as the motor spins faster, it generates more back-EMF. So maybe the stator field has to spin proportionally faster than the rotor to compensate and produce the desired torque. The difference between the bus voltage and the back-EMF probably doesn't reduce in a nice, linear fasion.

With both IC motors and electric motors, the torque reduces as the speed increases. Electric motors are cool because up to a certain speed, the torque is constant. However, after that point, all motors see their torque drop in a decaying exponential. So, Vd and Vq can be approached from a linear perspective as long as the torque output can be constant.

Thus, for an induction motor, the changes in Vd and Vq need to be proportionally larger when operating at a speed where back-EMF becomes significant. In other words, this is a very non-linear problem, and attempting to solve a non-linear problem with a constant value solution will be nearly impossible. It does seem that it might help to give the "motor men" some parameters to work from depending on operating conditions may help the situation where one or the other attempts to grab all the resources...

One thing I am pretty sure about is that shooting for a really fast convergence is a nice, interesting challenge, BUT it can lead to it's own problems. I think Paul was able to get the motor to converge in about 1ms with a 5amp step. While it's cool that the control system can get the motor to converge that fast, it's probably not necessary. There is soooo much inertia in an automobile that requiring a 1ms convergence to a step input would require HUGE amounts of torque. F=ma.

It would probably help a lot to figure out some reasonable ballpark numbers for mass and desired accelleration (not just of the car, but how the motor/drivetrain responds with inertia) This would help produce some reasonable specifications for the control loops (like convergence time) to shoot for. Perhaps this could be broken down with different specifications over the speed range, depending on the motor's torque output curves.

[thingstodo]

Originally Posted by e*clipse

Again, I think part of my misunderstanding is directly related to the induction motor. In an induction motor, the rotor's current is proportional to the slip - right? So more slip, then more rotor current, which produces the rotor's field, which interacts with the rotating stator's field to finally produce some torque . . . right?

Current is produced by slip. There must be a difference between the stator rotating field and the rotor speed to generate current in the rotor. The current in the rotor is needed to generate torque.

I'll see if I can find a link to 'howstuffworks.com' ... it does a *MUCH* better job of explaining than I ever could.

As it turns out, explainthatstuff had a better description, in my opinion, and here it is.

http://www.explainthatstuff.com/induction-motors.html

[Cyruscosmo]

Originally Posted by freebeard

http://www.dmlp.org/legal-guide/washington/washington-recording-law

You are correct freebeard, and I made sure he knew, although he did not believe what I told him until it came back and bit him.

That law actually appears to be one designed to protect inherently deceitful people. “IE” Those who will lie to your face and deny it, or deliberately rearrange what was said to favor themselves. Lawyers come to my mind...

Anyway I told him during lunch in front of other guys we work with, that I was going to start recording his “instructions” so that “I” would be sure and get it right next time. And he answered with, that would be a very good idea since mistakes are costly, which I also recorded.

The first time I played back his “instructions” he had made a very big screw up in telling me to order 1000 feet total of three quarter hose with standard “air” fittings on each 100 foot section. So I ordered ten, one hundred foot sections of three quarter air hose with CP fittings on each end. When the new air hose arrived he insisted that he told me “water hose” and also told the owner of the company that I had misunderstood him. So I played back what he actually said, the owner about died laughing.