[Pedxing]

I don't know about the idle or EGO parts of your post. I tried enabling EGO once and I got some horrible results with tons of oscillating, didn't know what I was doing wrong and turned it off. I'm not sure I understand how to verify the closed loop idle part.

Normally you can start with the P term and leave the others at 0. P is proportional...the more the error the more the output. In this algorithm, start low like 1 or 2. Increase until you start to get oscillation. Back it off a little. Add some I to bring it to target more quickly. Add very little for this platform. Often you can leave D at zero. This dampens the signal and slows things down. You can add D or reduce P, often it is similar results. For many platforms on cars I can leave D at 0.

[PSIG]

Agreed. The issue is not only process and hardware variable effects, but that different algorithms may be used for PID, so the tuning from one system or function to another is also different. I use a similar process of adding P until oscillation, a tiny bit of I only enough to stop oscillation, and repeat. At some point, P and I will combine to cause unacceptable overshoot of the target, so add some D. You may end-up with a ratio anywhere from PID 1-0-0 to 10-1-5, or numbers towards 100. Too many factors of software and hardware plus process to predict with a simple or universal estimate, that I have found anyway. Tune it methodically.

As a generality, P is the process and primary driver, while I is a sensitive accelerator similar to power-steering, while D is a damper that tries to predict and suppress deviation. How your system responds in both reaction (process time) and and over-reaction will guide tuning. For example a quick-reaction system such as fuel pressure regulation (little or no "springy" overshoot reaction) is nearly instant in response, so you may have little or no D component. A PI system. Other systems respond well to P, needing little or no I, and lots of D.

How these work in different systems is most easily found by thoughtful and incremental hands-on testing. Experience makes it quicker. Copy your tune with a new name for experiments. Save improvements as your updated original tune, or reload your original tune to go back to where you were at any time. Have fun!

[Pedxing]

Out of curiosity a had a look at the PID code in 202103 firmware. I pulled out the Compute code and put it into a little unit test form I made. It performed the same as in the car but with some manual settings. With no I term, it got "stuck" at the lowest value of the IAC duty cycle. Usually a PID with some P but 0 I and 0 D will do something, but this does not. The min/max of my duty cycle seems to be the factor that causes this. If I change the min to be higher than fully closed on the IAC then this might fix it. (Fully closed is like 29 on my valve, if I change this to say 35 then it should cause the RPMs to rise with no I.

With a bit more I it will start moving towards target but it's not super awesome at this -- if the input fluctuates a bit naturally (not due to the output being commanded alone) then it has problems. Since RPM will vary due to user input or load factors, this is a bit of a problem. I mean you can get it to work but it's more problematic than other systems I've played with. As a research project I may try a new algorithm.

PID.PNG (9.07 KiB) Viewed 1835 times