stefanst

iTrader: (1)

I have too much information. This confuses and infuriates me. Background: running MS3X, fw 1.4 release.

The question: how are the PID terms programmed.

I.E.: With classic PID, as I learned about 30 years ago, we do the following:

We define a target (i.e. target boost), and subtract the actual/current value from the target. The result is the "error: e(t). So if actual boost is less than target boost, we have a positive error value. If actual boost is higher than target boost, we get a negative error value.
The goal is to have an error of 0.

We have three actors P,I and D, reacting to this problem. Their outputs get added up and fed into whatever we can use to influence our control (i.E. the boost valve)

The terms have the following definitions:
- P is proportional gain. Kp is the term. The error e(t) is multiplied with Kp. There is no memory of what happened before. P reacts to differences immediately, but will not get the value to 100% of target

- I is integral gain. Ki is the term. The controller keeps a memory of what the I-term is and adds to it, or subtracts from it. This is what get's you to target in the long run.

- D is derivative gain. If there is a sudden change in e(t), D reacts. If e(t) stays the same, D has a 0 output.

At least the I-term seems to behave the way I would expect it to on all MS3 PID implementations.

Now here's my confusion:
The D and P seem to act differently to what I would expect. The documentation I found is not conclusive.

D: traditionally, a positive Kd value should increase overshoot. It appears that in the code the programmers added a minus somewhere to the Kd in order to use a positive Kd to dampen initial response. This appears the same across all implementations. Is my reading of this correct?

P: again, traditionally a larger Kp would mean more overshoot and faster response. However, I read multiple times that boost control Kp needs to be increased if we overshoot too much. If you don't get overshoot you need to decrease Kp. I also found a reference that this only applies to certain firmware versions, but I can't find when it was changed. This seems to contradict classic PID implementation.

When I was tuning EGO, the P-term seemed really screwy. Using P and I, the PID controller seemed to go the wrong way in some cases. Meaning that if the current AFR was below target, it would INCREASE fuel instead of decreasing it. I resorted to just using I-term and now we get to where we're going, albeit slowly.

Also the I-term seems to get reset with some control inputs. This is especially true for EGO. I'm idling and the I-term corrects the amount of fuel given. Then I blip the throttle and the I goes back to 0, even though the error is still present. What gives? Again, with traditional PID, the I-term is cumulative and keeps a memory at all times.

Sorry about the long, rambling post. Any insight as to code implementation would be helpful.

18psi

iTrader: (76)

This part, is hands down, the biggest downside of MS these days. They change the way PID is set up many times over, and no one gives a crap about letting anyone know what was changed. So we all just wing it. Wish I could help moar.

Braineack

iTrader: (62)

super simple unhelpful post:

Boost: tune P first, add I to maintain target long term.

Idle and EGO: Tune I first, add P to increase reaction speed.

add d when/where needed.

stefanst

iTrader: (1)

Frustration with the documentation led me to download the source code.
If I read it right, boost uses the "generic_ideal_pid_routine".

And in that routine all the terms seem to follow classic interpretation, as I have described above.

And I thought about it some more and understand now how more "D" would actually decrease the overshoot- the first time the code runs, new_error - old_error will be positive and help keep the WG shut. But each time after that it should be negative and actually decrease whatever the P- and I- terms put in. Until we reach target, which is where things get interesting. Let's say after running the code for a few cycles we reach target. Error = 0. But since our turbo/WG combo reacts slowly, we now overshoot. Which means that the error is now NEGATIVE. Now new_error - old_error is still negative and the D-term will keep assisting in opening the WG to reduce boost. In addition, our P will now have negative output and P and D together will decrease whatever our I-term is now.

The duty bias table is presumably a "seed" for the I-term when the code starts. I don't think it has any impact after that once we have entered the boost control algorithm. This is helpful when you're in a region of the map, where we can actually reach target, but may actually be detrimental if we're outside those areas- typically at low rpm.

Now I have a headache....

aidandj

iTrader: (5)

<p>This only relates to boost control but it was changed in 1.4</p><p>Read the threads in the MS3 development board. I had a couple learning how to tune it. And I'm not fully happy with it.</p><p>The way it works in 1.4 is a PID equation with a bias table.</p><p>That means you create a table that tells the ECU what you think the valve should do, and then PID adjusts from there.</p><p>Each time the ECU recalculates what DC the boost output should be it takes into account the bias table by a certain amount.</p><p>I have had issues so far with the bias table being too strong. Its effectiveness was reduced in one of the betas but I'm still not perfectly happy with it.</p>

stefanst

iTrader: (1)

The code seems to confirm that: Every time the routing runs it adds "start duty" to the PID value. And start_duty appears to be a lookup value from a table. So either you have that table perfect or it may screw you up, or you just set it to the same value across the board. For example my setup creates 180kpa at a boost duty of 60 at 5000rpm. That is the highest boost my setup achieves with duty set at 60. So if I put all cells at 60, then at least I won't overboost and once the PID fires up, the bias value gets ignored.

I may try that strategy first...

aidandj

iTrader: (5)

<p>No thats the old code.</p><p>The new code uses the bias value all the time.</p>

aidandj

iTrader: (5)

<br />
<br /><br />
<br />Did you download the 1.3.2 source or the 1.4 (not sure if its even out yet)

Braineack

iTrader: (62)

1.4.0 is latest.

PID tuning method: slide senesitivity slider until it works well. :P

DNMakinson

iTrader: (3)

<p>Ancilliary question regarding EGO. There is both PID and how many Events to pause between activations of the PID.&nbsp;It seems like a&nbsp;kind of method of slowing down the response (but making it a step kind of action) at low RPM.</p><p>Why is that, and what is generally viewed as a good setting for this Events timing?</p><p>Is it to prevent fighing between the idle valve PID and the EGO?</p>

Braineack

iTrader: (62)

I never had success using EGO at idle.

if i tuned it to work well at idle, it worked poorly at load.
if I tuned it to work well at load, it worked poorly at idle.

Turn on the EGO gauges when tuning, and change the events, you can watch the reactions.

stefanst

iTrader: (1)

That's what I've been trying to say. Maybe I should have been clearer. It looks like the code goes to a lookup table for the bias, each time it runs- every 20ms or so. It adds the lookup table value to the PID value. So bias is always a major part of the duty cycle.

Well, I'm back to my trusty old open loop settings for now- headed for the drag-strip tomorrow and don't want to have boost-cut killing me, because the CL was overly aggressive.

aidandj

iTrader: (5)

Copy your open loop table into the bias table. Set the closed loop to basic mode with the slider on zero.
<br />Do drag strip pass. Boost should follow table.
<br />Up the slider a bit.
<br />Do dragstrip pass. See what boost did.
<br />Repeat.