View Single Post
Old 11-01-2015, 06:07 PM   #2271 (permalink)
MPaulHolmes's Avatar
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
Hi Chinuhark! I wrote the FOC code from scratch without using or even looking at any other code. I agree that debugging becomes almost impossible if you are using stuff that you don't completely understand yourself. I actually think that's why just about all modern software has to have a new critical update every single day. People are using classes that are based on classes that are based on classes.... And nobody really understands what the heck they are even using in their code.

OK, you ask great questions! Here's what I did for the rotor time constant PI loop tuning:

First, you do the loop tuning. Tune the motor at ZERO rpm. Lock the rotor, or don't lock it. It doesn't matter. Your tests will inject current for maybe 0.01 seconds at a time. That's not enough time for the rotor to start spinning. Set the rotor flux angle to ZERO. You need to be able to command current for Id AND Iq, but it turns out that the same PI constants work for commanding Id to IdReference and Iq to IqReference.

I used an autotuning process that ran each <P,I> pair through a series of tests. If <P,I> passed those tests, then it was good a good choice for the PI loop. Here's what the test on each <P,I> looked like:

IdRef = 0 amps
IqRef = 10 amps (or whatever is good enough for the current sensor you are using)
Start with P = SOME SMALL START VALUE, I = P / 100.
Then, run your test. You should only need about 50 or 100 iterations at most. Every motor I've tested converges in maybe 10-30 iterations, when each iteration is happening at 10KHz. So, convergence should only take 1-3msec. So, save the 100 values of IqFeedback, and then graph them. You want IqFeedback to converge to IqReference with no overshoot and no oscillation. If it doesn't do that, increase P a little, and then let I = P/100 again (or I = P/80 or whatever) and run the test again. Stop the testing when the convergence is as fast as possible.

Now, for finding the rotor time constant, I make sure my P & I values are all plugged in and ready to go. Now, you need to bring in that horrible algorithm for finding the rotor flux angle. Assuming there are no mistakes in that, you just go through possible rotor time constants, starting at around 0.010 seconds, and go up to maybe 0.150 seconds. That will cover a wide range of AC induction motors. Try each one, seeing which one accelerates the motor to the highest RPM in, say, 1 second. Or, you can just see which rotor time constant gives you the highest steady state RPM. I think I ended up with the same rotor time constant for both of those separate tests.

The sensorless would work barely OK as long as the inductance and resistance was known almost exactly. It's a little like balancing a ball on the head of a pin. As long as the constants are good, the ball will stay up there, but if they are a bit off, the ball will fall in a short time. A nice happy medium would be, say, at least 1 pulse per mechanical revolution used in conjunction with sensorless code. The sensorless could carry you through the revolution, and as soon as the "ball was going to fall off the pin head", you would be brought back to reality with the pulse. That would allow for a crappier estimate of the stator/rotor inductance and stator resistance.

kits and boards
  Reply With Quote
The Following 2 Users Say Thank You to MPaulHolmes For This Useful Post:
dave koller (11-01-2015), thingstodo (11-01-2015)