I am hoping that I can reduce the hunting by making adjustments to configuration parameters:
PWM_CHANGE_RATE = 100mS (Look to change PWM value 10 time a second)
PWM_V_SENSITIVITY = 75mV (For every 75mV we are off, adjust the PWM 1)
So, here is an expanded graph segment during the hunting:
And here is the detail data which drove the graph. Data was sampled every 10th time through the adjust_PWM() code. At 100mS/cycle, this gives us data on approx 1 second boundaries.
Columns:
mS = Timestamp of when data was sampled. (in mS)
Alt-State = 12 means we are in Acceptance Mode.
PWM = Current PWM value being sent to Alternator Field
VBat = Latest measured battery voltage from INA-220's
Amps = Latest measured Alternator current from INA-220's
Watts = Product of Volts * Amps - Used to decide RPMs needed.
Ve: = Internal calcuation of Voltage Error while looking to adjust PWM
Ae = Internal calcuation of Amps Error while looking to adjust PWM
This is just a small portion of the data captured in Debug mode, I clipped out what seems the most relevant.
Temperature compensated target voltage was 14.802v until time stamp: 1,372,860mS when the target decreases to 14.785v due to battery temperate change.
Focusing only on the Voltage for now, what is happening is we are checking the Voltage every 100mS and deciding how far off from the target we are, The PWM is adjust up or down by dividing the error voltage by PWM_V_SENSITIVITY.
The "= " column is the resulting PWM adjustment value for THAT cycle. Remember, I only captured data every 10 cycles, so adjustments in the other 9 cycles can only be seen by looking at the current absolute PWM value. Notes of " >>i = " is where the system decided to adjust the throttle, and the goal RPM follows. Anytime the system decides to adjust the RPMS, a ">>i= " is displayed, so you can see the throttle was not moved too much. Most the RPM changes I think were due to load changes in the engine.
And here is a code snippet:
//------------------------------------------------------------------------------------------------------
//
// Manage the Alternator.
// This function will check and change the Alternator state as well as make adjustments to the PWM Field Value
// -- Consider Ramping
// -- Consider how far from target we are, further away = hit change it harder.
// -- And if overvoltage, drop it down even faster!
//
//
//------------------------------------------------------------------------------------------------------
void manage_ALT() {
int PWMErrorV; // Volts delta (Battery limited)
// Calculated PWM correction factors
<< SNIP Vales for Amps, Watts, etc.. >> // + --> Drive the PWM harder
// - --> Back off the PWM some.
int PWMError; // Holds final PWM modification value.
if (!ian220AMPWaiting || !ian220EGTWaiting || // If Volts/Amps measurements are not ready, -- OR --
((long)millis() - (long)(lastPWMChanged + PWM_CHANGE_RATE) <= 0L))
// it is too soon to make a change
return; // just skip doing anything this time around.
PWMErrorV = ((targetBatVolts - measuredBatVolts) / PWM_V_SENSITIVITY);
<< SNIP >>
// If someone wants to pull things down, let them have 1st say!
// If someone critial is spot on, don't let anyone else talk him into 'just a little more?'
PWMError = 0; // Note this is in priority order, with overvolts having 1st spot.
if (PWMErrorV <= PWMError) PWMError = PWMErrorV;
// Over Volts, adjust down due to overvoltage.
<< SNIP >>
else PWMError = PWMErrorV+PWMErrorW+PWMErrorA;
// Else, we are Under Voltage, AMPs, Watts and temps. . .
// . . so we can adjust base on Volts.
// And add in the Watts and Amps delta as well!
if (PWMError > PWM_CHANGE_CAP) PWMError = PWM_CHANGE_CAP;
// Are we trying to make too big of a change UP this cycle?
// (note that going down can be as large as it needs to be)
<< SNIP Code that deals with mode transitions. and PWM out-of-bound limits >>>>
analogWrite(FIELD_PWM_PORT,fieldPWMvalue); // Update the PWM each cycle
lastPWMChanged = millis(); // And we just refreshed the PWM port.
}
To see the whole thing, look for " void manage_ALT()" in the source code.
I am thinking this is really a case of:
- Hey, We are Over Voltage, lets decrease PWM.
- Hey, We are Over Voltage, lets decrease PWM.
- Hey, We are Over Voltage, lets decrease PWM.
- Hey, We are Over Voltage, lets decrease PWM.
- Hey, We are Over Voltage, lets decrease PWM.
- <<< This happens several times until the alternator is able to bring voltage below the threshold Then >>
- Hey, We are Under Voltage, lets Increase PWM.
- Hey, We are Under Voltage, lets Increase PWM.
- Hey, We are Under Voltage, lets Increase PWM.
- Hey, We are Under Voltage, lets Increase PWM.
- Hey, We are Under Voltage, lets Increase PWM.
- Hey, We are Under Voltage, lets Increase PWM.
Given I only look at error voltage in the moment, with no ability to take into account current trending, about the only thing I can do is adjust the two variables for timing and sensitivity. Perhaps increasing time from 100mS to 250mS will help. I will also try adjusting PWM_Sensitivity as well - the data shows that in MY system one change in PWM seems to make about a 2-20mV or so change in battery voltage.
If anyone has some ideas, would be happy to hear them. Will say, this osculating is just the situation noted in process control and why the PID approach was developed The idea is: Hey, we are undervoltage, but the trend is changing, and we DID make a change a while ago.. Perhaps lets see where this Trend will take u before we make another change... (the 3rd leg of PID is to look at not only the trending, but also the speed of change and make adjustments for that as well.)
No comments:
Post a Comment