Let's say when we spin the Leaf motor externally at 3000 RPM, it outputs a 200 Hz (for 4 pole pairs) 280V phase-to-phase back-emf (I don't actually know what voltage it outputs, I'm using random values). That means 280V*sqrt(2) ~= 400V DC-link is what we need for operating up to 3000 RPM until the weakening starts. So let's assume we've set udcnom to 400, and fweak to 200.
So the software knows the base RPM point where the weakening should start. But that's under the assumption of DC-link being supplied where the inverter is able to provide with motors nominal phase to phase voltage. If we're supplying the DC-link with a voltage below than the nominal voltage i.e. udcnom, the software already shifts the fweak point back or forth, so the weakening start point is shifted accordingly.
So instead of detecting we've run out of voltage, can't we simply start decreasing IdRef right after fweak, as the name already suggests? For the speeds under the weakening point, a fixed IdRef could be given. Above that point, a declining IdRef curve (with a lookup table maybe) based on motor speed, could be used. Since Leaf is an IPM, a smarter algorithm for IdRef can be implemented in the future.
After we run the field weakening logic and find the required IdRef, then run the PI control for IdRef->VdRef, we now have the Vd vector. Then we run the IqRef->VqRef PI controller, but now we should saturate the upper/lower points of Vq so that vectorial sum of new Vd/Vq vectors doesn't exceed the maximum voltage radius.
--
Below is a snippet from the Microchip's PMSM FOC example (link http://ww1.microchip.com/downloads/en/A ... _MCHV3.zip, pmsm.c:491). Above this snippet Clarke and Park are done. VdRef is defined by the need for field weakening, and VqRef is defined by the torque control knob/speed regulator. Then here it prioritizes VdRef and dynamically limits VqRef so that sqrt(VdRef^2+VqRef^2)<=1.
Code: Select all
/* Flux weakening control - the actual speed is replaced
with the reference speed for stability
reference for d current component
adapt the estimator parameters in concordance with the speed */
ctrlParm.qVdRef=FieldWeakening(_Q15abs(ctrlParm.qVelRef));
/* PI control for D */
piInputId.inMeasure = idq.d;
piInputId.inReference = ctrlParm.qVdRef;
MC_ControllerPIUpdate_Assembly(piInputId.inReference,
piInputId.inMeasure,
&piInputId.piState,
&piOutputId.out);
vdq.d = piOutputId.out;
/* Dynamic d-q adjustment
with d component priority
vq=sqrt (vs^2 - vd^2)
limit vq maximum to the one resulting from the calculation above */
temp_qref_pow_q15 = (int16_t)(__builtin_mulss(piOutputId.out ,
piOutputId.out) >> 15);
temp_qref_pow_q15 = Q15(MAX_VOLTAGE_VECTOR) - temp_qref_pow_q15;
piInputIq.piState.outMax = Q15SQRT (temp_qref_pow_q15);
/* PI control for Q */
piInputIq.inMeasure = idq.q;
piInputIq.inReference = ctrlParm.qVqRef;
MC_ControllerPIUpdate_Assembly(piInputIq.inReference,
piInputIq.inMeasure,
&piInputIq.piState,
&piOutputIq.out);
vdq.q = piOutputIq.out;
So if it works nicely when there's no movement, maybe you need to "unswap" the resolver sin/cos?