JasonC SBB

Shouldn't be an insurmountable problem. An aggressive 'D' should help.

Unless there's something wrong with how the 'D' was implemented...

Braineack

iTrader: (62)

I don't let the code go all nutso.



this log shows 1 minute of idling. about 30 seconds of it is with a/c. was targeting 950rpm here. This was 5/30/15, before the new code.

JasonC SBB

You don't have an s/c with a large throttled volume.

Greg G

Damn. That's how I want the idle valve to be driven, instantaneous jump! But that's the feedforward thing of MS3, not closed loop... I do believe that kind of response can be implemented in MS2/Extra using only 1 input-- a hardware input from the AC will make the ECU jump up by a set adder %. Not exactly feedforward, but better than reactive.

Greg G

Nyarr. I need a hookup for the dual throttle body mod! Already have a spare throttle body here...

Braineack

iTrader: (62)

yeah, but what has worked well for me is manipulation of the PID code where it's not constantly trying to make adjustments. MS3 doesn't have the deadzone yet like you said you had, I would like that. I think that would help, I'd be happy with 50-75rpm window within the target, really with the way the PWM% duty jumps (at my freq it makes 0.6% jumps IIRC) you're never going to be able to hold it exactly, so the code will keep jumping back and forth and accomplish nothing.

The way mine is set makes it able to reach my target with stereo at full blast, a/c running and headlights on. Like I said before, starting at 0/0/0 I like to turn on everything, then find the lowest I value that can reach my target. Then I start bumping up P and at the same time start causing the idle to get upset (blips, a/c cycling, etc) and see how it reacts and tracts. If I start adding too much P even with a **** ton of D, it reacts too quickly and starts a cycle of oscillation.

I got new firmware yesterday with the mario enhancements written into the MS3 PID code, so I had to retune. I ended up at 5/17/40.

I was talking to Ken about it and he said he typically ends up with more P than I, but anytime I try it it overreacts and can't idle steady. One thing he suggested to me was enlarging the min-max rpm zone to cut down the sensetivity of the code, but that only allowed 2 more points of P. It could be our slow idle frequency or something, but I've been happy with how it's running my car.

I could try to turn of the a/c idle up code and see what happens when my a/c turns on. I had it that way when I first installed MS3, as the a/c code wasn't implemented yet. I had a little dip, the CL code brought the idle back up and all was well again. For my setup, P still reacts fast enough, even set so low, and the high D keeps it in check.

Also notice in my log I posted that since the idle valve holds steady, the AFRs now have the most effect on the idle speed.

Greg G

Thanks! What are your Min/max rpm settings? I remember reducing the max, and the valve just stopped responding

Next time you talk to ken, remind him to port the "idle duty adder on hardware trigger" code from ms3. He did tell me it's doable...

Braineack

iTrader: (62)

Yeah but I want him to do my stuff first


I have it set to 700-1500RPM, was 775-1300RPM.

richyvrlimited

iTrader: (1)

Possibly, seeing as Ken states you should never need any 'D'....

JasonC SBB

Perhaps he never tried to do idle on an s/c setup with an intercooler.

I will repeat.

P and D work together. D allows big P. Together they make the loop react quickly.

I have been doing control systems for over 20 years in my day job. Properly implemented, D allows a large P; together they allow fast response with little or no overshoot.

Look what 'D' did for my AEM boost control. They didn't have any 'D' in it so I built a circuit just to add it in. I used to get as much as 5 psi of overshoot - without my D circuit, I had to make boost control very slow in order to prevent overshoot. Now I get 0-0.5 psi of overshoot.


See logs below. This is with a 5 psi (133 kPa) wastegate can. The D circuit modifies the duty cycle going to the solenoid, so you won't see its action in the duty cycle trace.

Top red trace is MAP. Left: no 'D'. Right: with 'D'.

Braineack

iTrader: (62)

See I tune EBC PID different. I start with a high P and lower until when I spool I reach my target. Then I add I to keep the target held to redline. I add D term to reduce any oscillation/overshoot and tweek the other values as need. My boost curve is baller status.

this was my last dyno pull:

JasonC SBB

The MS boost control PID algorithm is also a bit oddball.
Do you have boost control logs at full boost at say 5500 RPM, WOT, then you lift completely, and get back on immediately, just like the upper right hand trace I show above? That used to be where I would get the most violent overshoot.

Braineack

iTrader: (62)

No, but I could later. I do have logs of throttle maniuplation while in boost and it handles it perfectly.

Braineack

iTrader: (62)

just took a log, if anything it just proved I have too much D. no overshoot whatsoever, map log looks exactly like yours.

JasonC SBB

Might be fun to reduce D by 30-50% and see effect on WOT-lift-WOT.

Braineack

iTrader: (62)

I know I added the D to remove a bit of oscillation I had, but I need to retune it completly, they changed the code a little and I'm not quite hitting my boost target anymore.

Greg G

Been a bit busy these past 2 days. Trying to get a semblance of feedforward, I did 3 things:

1. plumbed in the EGR solenoid for added air
2. added a time delay relay to the ground signal to the AC relay (1J). EGR solenoid and AC fan are not delayed.
3. wired the AC out signal (1J) to PE1 to enable table switching. Table 3 is the same except for a higher spark advance at idle. Previously, I had used idle advance, which was still reactive and had a 700 ms delay from AC on to spark advance, and occasionally dropped out during oscillations. Now spark advance is instantaneous and unaffected by oscillations.

Spark tables:


Results:



The car is much more sedate in reacting, smoother if you will. There's still a dip and oscillation. The air solenoid is good for 100-150 rpm. Maybe I should also delay the AC fan? It seems to be blunting the effect of the air solenoid. On the other hand, separating it from the AC compressor "softens the big blow".

Was too tired to dial in the closed loop settings. Also need to figure out the correct delay interval for the AC clutch. Too much delay and the closed loop wrestles the idle back down. I'm assuming I should time it in such a way that the AC clutch engages at the peak of the RPM 'hill" from the added air. Will study the logs first. And rest the brain

Braineack

iTrader: (62)

I decided I now agree with Jason with too much I and not enough P.

I completely retuned mine and was getting closer to 10.2 | 5.8 | 3.2. But it still needs fine tuning.

With so little P, you really take the spring away from the code to react to the rpm change and get to the I point. Since I do have the feedforward code, I didn't need as much because the only other time I'd need to react to something, is headlights going up. This has worked well for me, only because I never needed more.

I started tuning my code without feedforward active and its completely changed how I went about it. I was basically the idle up adder as my P value. You dont need as much I if you use P to get drive you to the target faster. Some D should just prevent the P code from overshooting that target.



Are you saying you have that code now? or were you just able to delay the compressor onset? I would time it better so the idle speed increases just as the compressor is turned on and would otherwise cause them to drop.

Greg G

No change in code. 3.1.1 'mariob v5'

I have an external adjustable time delay relay intercepting the output from 1J. So the purge solenoid and the spark table switch occur ahead of the AC clutch engagement.

So it looks like I have too much delay on that graph? Hard to time it on the car, looking at the log, its about 3 seconds. Will adjust that, then the closed loop idle. The only thing left is to convince Ken to give me that instant idle duty response on a hardware trigger. Hmm, if that happens, then I'd have to drastically reduce the delay. Now I have to ask for a delay in the idle up from the hardware trigger, to match the external delay on the compressor

Braineack

iTrader: (62)

how much is the delay? IIRC, I'm shooting the pwm% up 5% on a 500ms delay.