View Single Post
e*clipse
Permanent Apprentice

Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 297 Times in 213 Posts
Quote:
 Originally Posted by MPaulHolmes Ya, the mulss takes a couple cycles off the normal multiply. I think because there are 4 variations: mulss mulus mulsu muluu (signed signed) (unsigned signed) (signed unsigned) (unsigned unsigned) And if you know what type you are using, the compiler doesn't have to check and maybe saves a little time somehow? Now for the sensorless, Ealpha = Valpha - statorResistance*IAlpha - statorInductance*dIAlpha/dt Ebeta = Vbeta - statorResistance*Ibeta - statorInductance*dIbeta/dt (Valpha, Vbeta, Ialpha, and Ibeta are all just stuff that you get during the clarke and park transforms and inverse transforms. The steps are identical for ACIM and permanent magnet AC) EDIT: OK I had made a mistake, and you can't just get the rotor flux angle that way. There's an offset that depends on the speed of the motor. Oh well. It's sort of working now though.
Very interesting - ok - that saves some computer time.

I was wondering why they would use the resolver timing they did in conjuction with the motor's electrical timing. How 'bout this one - it seems those 'Yota engineers are pretty clever:

We have to dig into some of that trig stuff we learned many moons ago - my dad reminded me of their existance... trig identities like the double angle identities:

sin2A = 2*sinA*cosA
cos2A = 2*(cosA)^2 -1 = 1 - 2*(sinA)^2

So, if the resolver output is the right side of the equation, the left side always works out to be the rotor's electrical position. ( for Toyota hybrid motors using a 4 pole pair motor and a 2 pole resolver )

How does this tie into the motor controller stuff? For FOC, we need to convert to an orthogonal coordinate system using a Clarke and Park transform then do some control stuff (like the PI loop) then convert it back to reality using inverse Park and Inverse Clarke transforms.
Fortunately, the Clarke and inverse Clarke transforms don't require any angle information. The Park transforms do:
Park transform:
Id = Ialfa * cosA + Ibeta * sinA (I'm using A instead of theta to illustrate )
Iq = -Ialfa * sinA + Ibeta * cosA

The inverse Park transform:
Valpha = Vd * cosA - Vq * sinA
Vbeta = Vd * sinA + Vq * cosA

Now, if the resolver were directly synch'd with the motor this would be easy - just use the resolver output directly. Why the heck would they use the relationship they did? It turns out it's not too much more difficult - just use the double angle identities and go on your merry way!

- E*clipse

 The Following User Says Thank You to e*clipse For This Useful Post: MPaulHolmes (09-28-2015)