Quote:
Originally Posted by MPaulHolmes
Code:
batteryCurrentLong = __builtin_mulss(Ia,pdc1) + __builtin_mulss(Ib,pdc2) + __builtin_mulss(-Ia-Ib,pdc3); // batteryCurrent is in [-4096*sqrt(3)/2, 4096*sqrt(3)/2] = [-3547, 3547].
if (batteryCurrentNormalized < -maxBatteryCurrentNormalizedRegen) { // maxRegenCurrent is negative. Computed in "InitializeThrottleAndCurrentVariables()".
// averageDuty = (pdc1+pdc2+pdc3)/3. But division is slow. So, do this instead:
// averageDuty = 65536 * ((pdc1+pdc2+pdc3)/3) / 65536
// averageDuty = 21845 * (pdc1+pdc2+pdc3) / 65536
// averageDuty = (21845 * (pdc1+pdc2+pdc3)) >> 16
averageDuty = __builtin_mulss(21845, pdc1+pdc2+pdc3) >> 16; // avoiding divide by 3. HAHA.
EDIT: Without voltage monitoring (which is super easy to include, and actually was included on the revision board that got stolen that was on my laptop, but I'm not angry at all. nope), I think the controller could precisely command constant current into the batteries, somehow using the motor windings for an inductor, but it wouldn't know when to stop, unless it was told somehow. I haven't seen the link you guys are talking about, but I know it could be done. I just feel it way down deep. |
Just wondering - after looking at the 3rd drawing in that patent again. The positive goes into one phase (lower right in the drawing) and then returns through the other two. Perhaps it would be possible to modulate the other two so that there would be zero torque?? It would require good knowledge of motor position when parked, and the goal would be opposite of FOC's goal. That would make a converter that uses a BLDC motor for the inductor possible. Also - the inductance of my motor is very low - about 1.4mH.
On another note, I've been trying to understand the sensorless code. To start, it looks like a LOT of the code is induction motor specific. It seems just dealing with the slip issue requires about 15pages of code. - PLEASE NOTE - I'm not criticising here - I'm sure you've made it as clean as possible; and I certainly dont have the patience to make a clunky version of it.
Maybe at some point, it would help to make two versions of the code - one for asynchronous motors and one for synchronous motors?
Also, it looks like only one place needs angle information - the Park and inverse Park transforms. Both of those use both sin and cos, which are supplied by the resolver. The problem I'm trying to work around is the resolver's 90* shifted cosine and the fact that there are two motor electrical revolution per resolver revolution. I think some cleverness with trig identities may help.
Also - what does this do? - the "bultin_mulss" part??
(_builtin_mulss(Vd, sin_theta_times32768)
- E*clipse