Hi Adam, Just to close this off i spent a lot of time trying everything to catch the stall - as i said the gain and anti stall did zip from max to min values. It really needed a dashpot style fall to idle - which when ethrottle is setup the hold table is removed. I managed to create a vitual dashpot using a virtual auxillary triggering a timer and that timer controlling a slowed return to idle using the 3D idle table. Works very well and might be something others could use if they have a similar problem. My engine has a very light flywheel and two charger bypasses and 550cc under runner injectors, big cam, remote ethrottle body, head flowed to hell and back etc etc etc all on a 1565cc engine so the combination is probably hard to tune but this made it very well behaved. Have attached the tune in case anyone else has a similar problem. Thanks again Adam and please pass on thanks to the engineers, support etc as the g4+ really is excellent. BR
Renault R8 with v-dashpot.pclr
The main purpose of the update rate table is to account for "transport delay", this is the time it takes for the lambda sensor to sense a change in the fuel mixture and reach a stable value. To test this you can log injector PW or fuel table number and lambda, hold the engine at a constant RPM and apply a step change of say 10% to the whole fuel table, the transport delay is how long it takes after you have changed the fuel table until the measured lambda reaches the new value corresponding to the change in fuel input (~10%). The more gas that is moving through the exhaust system, then the faster this delay will be. So you can update at a faster at higher RPM because more gas is moving through the system so the delay to reach and saturate the sensor is shorter. Your update rate can be close to the transport delay time.
If your update rate is too fast then you have to use much less gain to prevent oscillation.
The gain is basically how "big of a bite" the CLL system will take at correcting the lambda error. To tune this I just log CLL trim, Lambda error, lambda target & lambda 1 and watch response while making step changes to the whole fuel table (just multiply the whole table by say 10% or -10% as well as smaller and larger changes). Then play around with gain to achieve the fastest correction possible without significant overshoot/undershoot or oscillation. Especially the 3 cells at the left hand end of the gain table are the ones that make the biggest difference. You can do a pretty good job of this just free revving, holding at constant RPM, you dont really need to be on a dyno or anything.
look up the wikipedia article for PID tuning. There is a gif on the page about half way down that changes to show the effect of increasing P, I and D values. Very roughly, P is how quickly it reacts (how quickly it applies motor current), I is the aggressiveness (how much current it applies), and D is like a smoothing filter. None of these descriptions is technically correct but it can be a lot easier to understand to this way than fully understanding the maths behind it.
I had noticed that your TPS response was a bit slow in general compared to your AP - about 200-250ms, which has got to be noticeable when driving. Here's the process i've used to tweak ethrottle PID's in the past (in case the 1uz settings dont give you the feel you want, or you just want to understand "why" a bit better):
without the engine running, set "run mode when stalled" to "run throttle"
set your ethrottle target table so AP0% = TPS20%, then interpolate up to AP100% = TPS80%. ie your TPS will only span between 20% and 80% open with full accel pedal travel.
probably store the ECU config at this point. It gives you a safe point to return to if you have to cut power a abort testing later on.
go to the logging window in pclink, start a log, and make APS main and TPS main the only 2 parameters visible (or at least the only 2 in one of the groups)
press the accel pedal slowly a few times then quickly a few times, then quickly but only to 1/2 or 1/4 pedal travel and notice how much delay you see between the AP line and the TP line.
now go to the ethrottle PID numbers and bump up P by 1 and repeat the tests. What you are looking for is minimal delay between the AP line moving and the TP line starting to follow it. At this stage dont worry about overshoot too much, just bump it up towards 8 or 9 until you stop seeing much improvement. dont go past 9 though.
Make some notes as you go about what numbers you are testing. If you get the throttle to the point its just oscillating and wont stop after a second or 2, turn the ignition off, start again at slightly less aggressive numbers.
Now you basically play D off against I. D you increase or decrease by 1 or 2 points at a time. I by 0.02 or so. If the TP response looks "lazy" - ie its heading towards the AP line but starts to taper off before catching up to it (so TP gets to within 1-2% of AP and the takes a second to get the last bit), lower D until that tapering off point is really close to the AP line. If you see the TP line overshoot the AP line and oscilate a few times before settling down or if it doesnt stop oscillating at all, increase D until you only have no overshoot or maybe a single small overshoot then it stablises at the AP line.
To evaluate I, looks at whether the angle of the TP line matches that of the AP line when you press the pedal. If TP isnt a sharp enough angle, ie its heading in the right direction but not steeply enough, increase I (by a tiny bit). If TP likes to overshoot the target/AP by more than a couple percentage points, then lower I a bit. Note: this is why you tweaked the throttle target table to between 20 and 80 - you cant normally see overshoot below 0 or above 100.
You'll likely see overshoot worst when making large quick changes, and you'll see lazy response worse when making small slow changes.
When you have numbers you are happy with, put the throttle target table back to its normal values and save everything.
Regarding the APS and TPS calibration failures, you can do this manually by hooking up all 4x sensors but leaving your existing voltage values in place, setting ethtrottle to "quiet mode" mode, and pull off your intake pipe so you can manually move the throttle blade. start a log, then press the pedal all the way down, hold it for a couple seconds, then release for a couple seconds. repeat 2 or 3 times. Now push the throttl blade all the way open and hold it, then all the way shut (you need to press it shut, they like to sit at 3-4% when left alone), repeat a couple times. Now add parameters to your log view for AN 1, 5, 6, 7 - these are the raw voltages from the APS and TPS sensors. have a look at the min and max values for each sensor and enter these manually into the APS and TPS calibration screens. Also note if either of the SUB sensors doesnt have a full range of travel (ie it flatlines above 70% or something), you need to enter the main% value when the sub% stops increasing if this happens too.
You should now be able to switch to "run when stalled" throttle mode and run another log, but this time look at APS main, sub, TPS main, sub, and you should see all 4 tracking between 0 and 100% together (subject to a littel bit of latency in the TP numbers depending on how well your PID's are tuned).
Regarding Lambda control error correction table. I spend alot of time to tune these. The base map is adjusted the wrong way around. Because the error correction tables is a % corretion of actual error, you want big corrections like 15% on small errors (0.03 lambda error) and small correction (like 5%) at the biggest error on the table. This is because a fuel film built up first in the ports when big correction are applied. This means it needs several burn cycles to get the whole change applied and measured. This means lambda control applies big changes two or three times for big corrections which leads to Lambda oscillation. On small changes fuel film built up is much less. Lambda change is done and measured much faster and within same burn cycle. This means the Lambda correction can be set much higher, because the change in AFR is measured instant.
I have attached a tuned example.
Yes, I'v been watching this thread, I have the same issue of cycling VTC on and off as rpm floats around VTC On/off point during cold start.
Inj 5 pin (JDM Spec R), can't do 3rd condition, Link software only allows me max 2 conditions.
Poncams on stock unopened engine, doesn't idle well if I switch VTC on below idle, I haven't tried to play with tune yet to smooth it with VTC on at idle..
Stock ECU conditions for VTC ON are neutral switch off, TPS voltage high enough for idle 'switch' off and 1050-5700rpm
immy21 got a reaction from Carl mc in s15 VCT set up
