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
Quote:
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.
|