Uhg, I guess I'll have to check them out.
Latest issues:
Code: Select all
//shift over values in error array each loop, a "time step". Z += 1
ztrans_idle_error_array[2] = ztrans_idle_error_array[1];
ztrans_idle_error_array[1] = ztrans_idle_error_array[0];
ztrans_idle_error_array[0] = (targ_rpm - outpc.rpm);// / 20; // Error is target - actual, removed typecasting, scale so K-gains have less effect
//output of the form: OUTPUT += Alpha * Error[0] - Beta * Error[1] + Gamma * Error[2]
//Note subtraction of the beta term prevents kP term from summing to infinity
//Note the IACmotor_Pos is large relative to the Alpha, Beta, Gamma terms since they are multiplied by the divided down error term
tmp1 = ((40 * (long)IACmotor_pos) // This is "+=" from Z-transform math
+ (z_alpha * ztrans_idle_error_array[0]) //this is the "now" part
- (z_beta * ztrans_idle_error_array[1]) //this is the "last time" part
+ (z_gamma * ztrans_idle_error_array[2])) //this is contribution from 2 loops ago
/ 40; //This is to scale the gain's contribution
IACmotor_pos = tmp1; //Set output (valve pos) to calculated value
P = 10
I = D = 0
So, when I'm positive (above the target), the idle valve moves to full open, then ticks closed slowly with increasing RPM.
When I'm below the target, everything seems cool, valve sits at 0 for a (variable) number of RPM, then will tick slowly more open as RPM drop. It seems there's some initialization taking place, so that depending on which RPM you were at when it noticed you cross the target, that's where it tries to center on. Though it doesn't flip to positive until you really are positive (i.e. over the set point).
It's weird, so I'm going to read through the code, but I thought I'd share. I don't remember this happening with my old version of the code. Perhaps there's some weird stuff with the typecasting, so maybe I'll try my old, working V 7 again.
