LAUNCHXL-F280049C: SDK speed Pi dynamic update

Some oddness in the speed PI call code area setting Min/Max allows hard saturation to occur.

obj->outMin = outMin;
obj->outMax = outMax; 

//
// Maximum voltage output
//
userParams.maxVsMag_V = userParams.maxVsMag_pu * adcData.dcBus_V;
PI_setMinMax(piHandle_Id,
(-userParams.maxVsMag_V), userParams.maxVsMag_V);

It also seems to omit mixing Speed controller Min/Max for an Iq output, needed for inputs of Id/Iq blocks. PI speed control mixed Id/Iq on the fly for Iq output shown Fig.5-1?

Then estimator stores highest Iq value as Idq_ref_A[1]=0.0 + Idq_offset_A[n]=0.0 and never gets Idq_ref_A[1] from estimator. The typedef MATH_vec2 has [2]array storage for estimator update of Id/Iq and generating PI speed control Iq Min/Max values for Id/Iq block use. But only the last Iq calculation is sent to estimator for storage?

If the block diagrams Fig.5-1 Fig.64 are not drawn as to depict SDK C+ code structure, most anyone is at complete loss how to fix it.

Genatco said:

Then estimator stores highest Iq value as Idq_ref_A[1]=0.0 + Idq_offset_A[n]=0.0

And there is little minimum current for RsOnlineRrecalibration <3Hz slow speed hot/cold wire Rs impedance update after reducing (user_motor_current_a  < 6.5A). Hence there was no audible frequency during the update, recalibration was less than accurate.

Yet the IDmag_A  scale factor was set for lower Rs calibration frequency current, roughly 1.5A via patches.

 /* set RsOnline current 30% <Est_Current_A */
motorVars.RsOnLineCurrent_A = (USER_MOTOR_RES_EST_CURRENT_A * 0.2); 

/* Inline to SVM_run: sets level of current to be generated in Id reference */
EST_setRsOnLineId_mag_A(estHandle, motorVars.RsOnLineCurrent_A); 

The idq_refA[1] seems to produce audible and accurate startup current with RsOnlineRecalibration after adding patch below. Oddly the 3Hz audible wire sound was not heard with lower max motor current = 5.5A. Sound is back mag_A injecting 1.5A and RsOnLineRecalibration is more accurate ohms values into estimator update cycles.

Recall Vdq_out_V[0] was maximum -5v and Vdq_out_V[1] >30v upon saturated max current level 5.5A.

Existing snip:

/* Upper PI block Vdq_out[1] makes >30Vdq  */
PI_run_series(piHandle_Iq,
Idq_ref_A.value[1] + Idq_offset_A.value[1],
Idq_in_A.value[1],
0.0,
&(Vdq_out_V.value[1]));

Added magic snip fixes RsOnlineRecalibration ~_mag_A injection current:

/* Set minimum saturation Idq_ref_A current value */
Idq_ref_A.value[1] = Idq_ref_A.value[1] - Idq_ref_A.value[0];

 However inline SVM_run update Kp_spd or Ki_spd values does not work. So startup time drags out >30 seconds. Ideally use imaginary defaults Ki/Kp (labs.h) to rapidly saturate P/I then back off rotor inertia with the real Kp_spd, Ki_spd values >3Hz or so. VESC project code also checks Rs impedance before starting motor.  https://github.com/vedderb/bldc/blob/22dc2ce33c64593beb1e01a3b062d8c1df73beec/mcpwm_foc.c#L1837    

Watching a few Axium project partner videos, the same Rs calibration sound is heard prior to motor startup, then faster speed integrator follows. There is no stall delay time between RS impedance check and rotor 360° full circle times. 

Axium: https://hackaday.io/project/164932-axiom-100kw-motor-controller

Axium: https://hackaday.io/project/164932-axiom-100kw-motor-controller

 Hey guys since E=mc^2 why waste magnetic potential energy as kinetic heat losses? The idea is to reduce the Co2 foot print - not increase it by expending energy as wasted heat loss on to AC power grid. Several auto companies have electric motors produce extreme losses heat rather than being 98% efficient. The former is a false narrative driven by huge $$ invested in the wrong technology people! 

A 10,000 RPM rotors are NASCAR race car speeds not US or any other motor car highway speed. And avionics prop thrust reduces as air speed increase and generally gear box down engine speeds. In this case less is more - not more is more given Co2 is the reason to produce greater efficient magnet motors, not see how much energy can be expent as even more Earth trapped heat.

Engineers have lost perspective so much $$ pored into bad technology. Perhaps C2000 FAST estimator may aid to recover lost battery energy when software tuned to do so. It only requires will to find better more efficient energy solutions 

Still questing as to why PI control block can not update kp_spd/ki_spd values once FAST angle generation is online?

The PI speed control is seemingly dynamic (PID) in other control systems to control current saturation point. Agree It really shouldn't be necessary to change kp_spd or ki_spd so there is obviously a bug in the SDK v2.01 PI speed control code. 

Not being able to update kp_spd/ki_sp after SVGEN_run() is enabled makes no sense, since PI values appear to directly influence slow speed estimator.

The slow speed estimator hunts many time for magnetic Nth pole rocking rotor ± few degrees, when kgm^2 is not default labs.h values. That is by no means correct startup current controller behavior, holding low speed estimator (Idq_ref_A[0]=0v) does help but not by much.