##### ## #### ## #####
_____ ( _ ) | ( ) | | | | | | (('\| (___\_)
_ _ | | | | | | | | | |/\| | \ /\ / \/ \/
### ## ## ## #### ## ## ####
____ | _ \ | |_) | | _ < | |_) | |____/
IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now. Visit Preferences to set your user name Summary of change: New Boostcontrol strategy allows '''even easier configuration''' since firmware 1.2.9 '''Overview''' * '''reference DC can be configured in a 2 dimension table: as a function of RPM, boosttarget''' * with this "target based reference PWM duty", PID boost is easier to tune for very quick reaction and small overshoot ** if the hardware actuator is good PID can be configured to switch to PD when boost is way too low, or to PI when boost is too high * actually, '''configurable thresholds for different strategies (operation ranges)''', as MAP grows: * '''boost off''' * '''max-DC''' (to help spoolup) * '''ref-DC''' * '''ref-DC + PD''' * '''ref-DC + PID''' * '''ref-DC + PI''' One can of course configure an extremely large window for the PID range * even to use PID strategy all over the place, and not use any other strategy at all. * the strategy is selected based on the configured thresholds wether it's optimal for the actual system or not ---- '''Mattias Sandgren was kind to contribute''' some documentation embryo - will be moved to [http://vems.hu/vt/help/v3/v3_boost_control_pid.html VT help] at "birth-time" Begin by setting the "Boostcontrol PID integral limit" to 0 and adjust the "refDC Table vs boost target" so that you get a good starting point for enabling the PID regulated boost controller. Apply max DC until To shorten turbo spool time you can apply the maximum dutycycle allowed. This can only be done up to a certain limit below the boost target, set this limit here. This must be kept low enough to avoid an initial boost target overshoot that the PID regulation will not be able to stop. PD control (far from target) PI control (close to target) PID overlap range Boost P, I, D Boost control PID integral limit Set how large the integral is allowed to build up. This value is what is added/subtracted to the reference dutycycle in order to reach boost target. In effect setting this to 0 will disable the boost control PID regulation completely and you will just send reference dutycycle to the boost control valve. (needs some explanation of how much x of max is, like what is normal limit, etc) * Why should 0 I not allow any P to be calculated? Seems like an error in the code based on regular PID control loops if that is so. - Gunni Boost PWM maximum value Limit the maximum dutycycle the boost control valve receives. Boost PWM minimum value Limit the minimum dutycycle the boost control valve receives. ---- Copied from IRC discussions : Overlap is PID mode, where its far enough from target to still might need the D term PD is for not winding the integral up when too far from target PI is close to target (its now control range) when close to target, PI only is used, as D wouldnt make any big difference anyway so it can be used with higher settings from far away, still not messing with close to target control What is the buildup range and control range? Buildup integral is frozen and control derivate is disabled. It means "too far from target, probably not physically possible to reach, don't build up a integral error" and disabling D term "close enough to target, error for P is small, so no D needed". Overlap is PID P is not active between max dc and buildup Buildup = I frozen outside this range buildup enables PD control is PI between buildup and maxduty there is referece only Future ? the buildup range might go, just enabling PD from maxduty its easier to find the optimal P if its scaled in kpa / % * it's possible to configure that way, of course so that PD starts as early as the buildup --- (may2013 FPhil)This is what I get from above, I hope that is correct ||DOMAIN || zero to maxDC||maxDC to BuildUp||BuildUp to Cntrl||Cntrl to Target||Target to ? (Overlap)|| ||STRATEGY||DC|| ?? || PD || PI || PID|| ||PARAMS|| ||PWMmin & max||id & I limit||id & I limit|| id & I limit || What happen if for some reasons boost enter the Cntrl to Target domain at fast increase? one can then expect a large overshoot. * he needs to tune better then. The Boost-buildup depends on the settings, eg maxDC and the ref-PWM table values. ** The good strategy is to tune from low-boost (and low values in REF-DC table), only climbing as the control is tuned and confirmed to be consistent. ** or you mean "what if some tube comes off, resulting in unexpected boost sky-rise" ? Yes, that is a concern.. even worse, in many cases the control could hardly do anything about it (or it would be very time-consuming to tune the parameters/thresholds to notice that some tubes came-off and limit boost some other way, eg. with intentional misfire - maybe feasible for 1 million engines but possibly more risk for a few engines than it saves) --- My way is start tune with quite large PID values and low boost with slope RefDc table where bottom row is W-gate minimal pressure and top row - aprox 30Kpa above my maximum boost expectations. Bottom line filled with 0...10, top line - 60...100 - spring dependant, Interpolation inbetween. With PID enabled it is easy to fill Ref DC table with correct values just by reading the log file. Wise way is match row boot value with current target - then actual BoostDC represent DC values for table. Overshoot or slow buildup can be achieved by table increase or decrease respectively. What is good in new strategy - it allows much larger Integral values. First WOT run with boost valve off [minimal pressure] is helpful for further tuning. GintsK. ---- '''VemsTune''' Since vemstune knows the runtime integral, it can display the contribution of I term by multiplying with configured pid_ki value (and a constant): * boost_integral_effect= config.boost_pid_ki * (runtime.boost_integral-128) / 32 * boost_P_effect = (MAP - boost_target_raw*16) * config.boost_pid_kp / 8 ** The boost_P_effect doesn´t seem to math out to what happens in the ecu. I can see it work like so , KPA_ERROR * kp / 100 / 32 , when Error is 10kpa, kp is 100 , then output P is 0.3125%, The above would be for example. ((190-200)*16) * 100 / 8 = -2000. Please explain further. I can also not see where the amount of error influences the output of the integral output. Similarly for IAC: * iac_integral_effect= config.iac_pid_ki * (runtime.iac_integral-128) / 16 * iac_P_effect= config.iac_pid_kp * (RPM - target_rpm) / 16 Since the actuator is known (eg. boost_DC and iac_duty ) contribution of D term follows : output = reference + P + I + D (although D term is "transient" by nature, so I compensates in the long run). ---- Gunni - I´m writing a complete boost control guide for VEMS´s new setup, but have found the following: "I" value influences the Integral limit and thus the total possible DC% that the I value is able to give. * (A+l) * I == AI + L has completely same effect if L = l*I so it's just a configuration question ** if sufficiently high integral limit is configured, then integral will be limited (to provide integral windup) as the min_duty or max_duty is reached so integral limit should not have a big significance (maybe it should be removed and not be configurable ?) *** The Integral limit should be a totally independent value from the ki value. I.e If I want to have aggressive ki yet limit the integral to 10% winding then I should be able to set the limit so, then when I adjust the ki it will have no effect on the limit just changes the amount of correction per amount of error, the limit still remaining 10%. This is how it should be, but is not currently. I don´t have a bench ecu anymore to test with so can´t create a log for you. I see no reason for why the ki can influence the amount if integral limit. I have detailed so far the operation of getting to a final boost target in a flow chart and then getting to a final BoostDC% but need more information about the PID values So far I can see P value: Approximate P_DC% = 0.314 * P * ErrorKpa/100 - Disregard I can now see it works like so P_DC% = KpaError*kp/32/100 , I tested this on the bench. '''I value:''' * the update rate is as configured (eg. 40 Hz is 40/ second that is 25 msec) * See boost_integral_effect above for how the contribution effect can be calculated from 128 based boost_integral value ** Where is the rate configured? Is the ki the rate? And the ecu applies a fixed increment per update perhaps? '''D value contribution:''' * pid_kd * feedback_change / 4096 * feedback is 1/8 kPa for the MAPtarget (boostcontrol), 1 RPM for iac * update rate is as configured PID 0-255 scaling: Ideally would be removed and engineering scaling implemented instead even if it´s a drop down menu with 255 pre selected values or Vemstune automatically rounds down or up to the nearest allowed value like is seen in many places already. Boost PID output is logged (boost_DC and iac_duty). * feedback is logged (MAP, or RPM for iac) * Integral (the only internal "memory"/state that does not follow from actual ). **it´s no help logging 0-255 values that don´t represent the applied duty cycle. More questions * PD strategy in the '''configured window''' (can be disabled by a very narrow window) normally when MAP is below the target * PI strategy in the '''configured window''' (can be disabled by a very narrow window) normally when MAP is above the target PD control: If PD control is set to 20kpa and PI control to 10kpa, at what point does the D control disable? PI Control: If PI Control is set to 10kpa and PID overlap range is set to 6kpa at what point does D disable ? Note : if PI Control is higher then PD control then PI control is disabled until PD control is within range seemingly allowing PID control from that point until some unknow point. PID overlap range: What does "forever" mean. Does 6kpa mean that PID is enabled when TargetError is within 6kpa of target? Percentages / Engineering values : 0-255 values don´t represent any engineering values and are not much help when calibrating. Neither do 0-255 input values. This is why calibration inputs and outputs should be real world engineering values always. I.e P_DC%/100KPA_Error = 40% = Kp (Then at 20kpa error you get 0.8% ) I_DC%/100KPA_Error/sec = 20% = Ip (Then at 40Hz, this is 0.5% for 100 KPA_Error per update event or 0.1% for 20kpa error or 4%/sec). D_DC%/1000KPA_Error_change/sec = 50% (If KPA_Error is changing at a 1000kpa/sec then reduce DC% by 50%) I_DC%_LIMIT = 10% (Ip is capped at -10% or 10% output) So when calibrating you have P_DC% + I_DC% + D_DC% + DCRef% = BoostDC% And when reviewing logs you can actually see if your D_DC% is overracting or underreacting very clearly. As well as you can determine if the required BoostDC% is mostly based on P or I in real comparable terms. Optional: Add document to category: Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.