Quote:
Originally Posted by MPaulHolmes
For the permanent magnet motor, with the encoder I twisted the motor post until it just passed "index", meaning it started over. Then, I ran the motor with Id = some nonzero command
Iq = 0.
Then, let the motor turn until it stopped, and noted the angle from the encoder. Then, I saved that offset for all history for that encoder/motor pair, and then just run the FOC code with Id = 0, Iq = torque command.
The code is all in C, but there's quite a bit of optimizations done, which doesn't make it terribly readable.
A single
long int / long int takes like 25uS or something, so I have to do a bunch of sneaky stuff. I'll send it over to you to see though. The sensorless is ALMOST REALLY REALLY REALLY ALMOST ready to test. so I could send you that one. Just ignore the "sensorless" function. It is out of control. haha.
|
I got it - awesome, Paul!
So far, the math stuff I'm doing is really simple. KISS, then I can understand it.
In SVM, he did a few clever things like >>6 to divide by 64. Most of what I've figured out so far is how to calculate the sector based on boolean logic, not math.
The resolver in the MGR is adjustable; I'm assuming it's clocked to match a zero point of the stator. If not, I'll make it so.
Regarding sensorless, I've seen good possibilities with it. It seems the only hangup is getting correct numbers at startup, right?
Also - you're basically getting some sinusoidally varying current data, right? If so, how are you dealing with them for the FOC? Perhaps a similar thing could be done to use the more predicable data ( less noise, amplitude variation) coming from a resolver?
Thanks again for the e-mail; I'll pour over it tonight and see if I can understand it.
- E*clipse