We recently added PID margins for the idle closed loop.
This solves the problem you are describing.
The margin disables PID if you are too far from the target.
You should try that.
We recently added PID margins for the idle closed loop.
This solves the problem you are describing.
The margin disables PID if you are too far from the target.
You should try that.
Yes, I have used that. It cannot be set too close to target, or there may be scenarios where closed loop does not get enabled. 300rpm seems to work well. If you roll in gear at 1100rpm when target is 900, the integral term will still saturate.
I don’t see how you could saturate the PID in that situation.
The target error and duration should be low enough to not do that.
At this point, you would need to show me this in the log so I can confirm it before adding any extra features.
I’ve noticed this mostly on cars with slower reacting hardware or wild engine combos. PWM idle control valves are a little tricky to get setup in this case. Steppers are fast enough where P can be set pretty high to “catch” the I windup before it stalls the motor.
I agree, PID margins isn’t a great solution. Lets even say it’s set to 50 RPM off target, coasting at 960 rpm when idle is targeting 900 will still windup
I think a disable/enable PID channel would be a nice feature although I bet you could get it where you need it with some more tuning.
IF vehicle speed > 1 & clutch is out THEN idle target is 300 RPM higher
This doesn’t make sense.
If the margin is 50 rpm, the target is 900, and the current rpm is 960, the PID is off, so there is no windup. I assume you meant a current RPM of 940 or something similar, so it’s within the margin.
But then again, how are you coasting at a constant speed above the target without pressing the accelerator pedal? The car should be slowing down in that situation.
If there is an actual issue, we can try other solutions.
But as I said, I need to see a log because this can be a simple calibration problem.
If anyone sends me a log showing this issue and the project, we can revisit this discussion. You can send the files in a private message if you want.
I noticed this in another thread when we were talking about it and never got around to diving into it
4Hz/rpm = 24kHz @ 6000 rpm
but in my case
@ 6000 rpm = 100 rotations per second … cam speed is 1/2 that, 50 rotations per second … spark fires 8 times with each full cam rotation, 400 times per second at 6000 rpm…
400hz @ 6000 rpm or 0.066Hz/rpm
Obviously there is another calculation going on there under the hood and somehow the unit on the front end got mess up. This explains why it took me so long to get the tach working on the car.
Now that you’ve clarified the margin don’t know if I agree that there is an issue, I was just presenting some other solutions for @ATSAustin
Sorry, I haven’t used the margin… I didn’t know how it worked, I assumed since you mentioned it that the margin turned the PID off outside of a window, not the other way around. I don’t find it necessary to use regardless
Hmm… down a hill??? or maybe it’s just a heavy car and taking a while to stop but eventually will. I engine brake up to the point where I’m about to stop sometimes, then push in the clutch. It allows plenty of time for the Integral to windup. Easily corrected with speed. What speed does the clutch get pushed in at? That speed is the threshold for higher idle target.
The speed-target correction is one of those things that most OE ecu’s do and the EMU Black spoon fed the tuner “I see option, I put in number”. The EMU pro requires studying or knowing what’s going on and seeking out a specific solution sometimes in a creative way but the paths to a reasonable solution are all there for the most part.
I think of all idle control as as a “target RPM” based system, not “target airflow” based system. The EMU Pro is superior in that way.
Tune the airflow and ignition targets to hit the RPM target. I think the way the EMU Pro does this with a “target” ignition and airflow PID is peak ![]()
There are plenty of airflow corrections for sudden load changes so even that is covered pretty extensively ![]()
hello, I dont use pro every day but every time I connect to it I find some ways to improve it
could you guys please implement it that when when you are adding new channel in log graph it would automatically pick different color than channels already have like I add channel and it’s always green
not sure maybe there is setting for that or you always need to change that manually?