DIYPNP install: inital tuning
#204
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Here's a code snippet from ms2_extra_idle.c
tmp1 = IACmotor_pos - (((long)(Kp + Ki - Kd) * ...
Why is Kd subtracted from the others and not added??
This appears to be the inverted sign problem.
How hard is it to get someone to change the sign, recompile, and for Greg to flash the new program in?
tmp1 = IACmotor_pos - (((long)(Kp + Ki - Kd) * ...
Why is Kd subtracted from the others and not added??
This appears to be the inverted sign problem.
How hard is it to get someone to change the sign, recompile, and for Greg to flash the new program in?
#207
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
What Ken said, "The D term is not coupled to error in the idle speed control loop, it's only coupled to change in RPM, which changes the sign you need to use to get the proper behavior." suggests that the code needs to be modified then, so that the sign is inverted, to get the proper behaviour.
EDIT: Nevermind, I figured it out. If you assume the target is constant it cancels itself out of each first-order change calculation. Then you're just calculating the difference between the current stage error and the previous stage error.
Last edited by bearda; 06-13-2011 at 10:43 PM.
#212
Elite Member
![](/mt2011/images_td/ranks/supporter1.gif)
iTrader: (10)
Join Date: Jun 2006
Location: Athens, Greece
Posts: 5,987
Total Cats: 359
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
I don't remember whether the 3.1.1 directory I edited was the vanilla or the mario_b version, however, I didn't find the "tmp1 = IACmotor_pos ..." snippet, instead I found "tmp1 = IACmotor100 ..." which leads me to believe that I had in fact, applied mario_b's patch to that directory.
#213
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Well I tried it! No dice. :(
The idle valve would immediately go to 60.2 (maximum open duty) and stay there. Idle RPMs stayed at 2k. Even setting PID to 0 0 0 didn't lower the idle duty. Setting it to PWM warmup lowered the idle duty as preset (so I know it isn't stuck).
Thanks again for the modified file Reverant!
The snippet from Jason came from me- I sent him the file from the mario b version. So you may have modified the release version of 3.1.1. Could that have caused the high idle issue?
EDIT: Oh crap I forgot to point the TS project to the correct firmware directory after flashing, maybe that's the issue...I found it set to 3.1.0 >.<
The idle valve would immediately go to 60.2 (maximum open duty) and stay there. Idle RPMs stayed at 2k. Even setting PID to 0 0 0 didn't lower the idle duty. Setting it to PWM warmup lowered the idle duty as preset (so I know it isn't stuck).
Thanks again for the modified file Reverant!
I don't remember whether the 3.1.1 directory I edited was the vanilla or the mario_b version, however, I didn't find the "tmp1 = IACmotor_pos ..." snippet, instead I found "tmp1 = IACmotor100 ..." which leads me to believe that I had in fact, applied mario_b's patch to that directory.
EDIT: Oh crap I forgot to point the TS project to the correct firmware directory after flashing, maybe that's the issue...I found it set to 3.1.0 >.<
Last edited by Greg G; 06-14-2011 at 06:08 AM.
#217
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Hi Ken,
I understand that the "type C" controller in the above link removes the setpoint information from the 'D' calculation. My hypothesis as to the problem has nothing to do with this.
What I see from ggermar's datalogs is that the effect of the D term (comparing 0, to medium, to large values of D), seems to have its sign inverted. That is, a dropping RPM seems to reduce the solenoid duty cycle, and vice versa, instead of the dropping RPM producing an increase in solenoid duty cycle. I see comparing the RPM and duty cycle sinusoids.
With a pure P controller the sinusoids will be inverted from each other (sinusoid of duty will be upside down compared to the sinusoid of RPM). That's because a dip in RPM produces a rise in duty. The D term should "mix in" a 90* phase shifted sinusoid. So as D is added, the duty cycle sinusoid should start "shifting left" as compared to the old P-only duty sinusoid. That is, the duty sinusoid should peak *before* the RPM has reached bottom. This is from the math:
-Derivative of a sinusoid is a 90* phase shifted sinusoid.
- If you add a 90* phase shifted sinusoid to a regular sinusoid, it looks like a sinusoid that's phase shifted between 0 and 90*.
- If you add an inverted, 90* phase shifted sinusoid, it phase shifts between 0 and -90* instead. (visually it appears to shift in the opposite direction)
What I see in Greg's datalogs is that the phase shift is *to the right* instead of to the left. This suggests that the D calculation is inverted (subtract instead of add, or vice versa). And the code snippet I posted, appears to be it. The P and I terms are added, but the D term is subtracted......
This is why practical D circuits in electronics are called "phase lead" circuits. Its sorta kinda like leading the clay pigeons when you shoot 'em.
Cheers.
I understand that the "type C" controller in the above link removes the setpoint information from the 'D' calculation. My hypothesis as to the problem has nothing to do with this.
What I see from ggermar's datalogs is that the effect of the D term (comparing 0, to medium, to large values of D), seems to have its sign inverted. That is, a dropping RPM seems to reduce the solenoid duty cycle, and vice versa, instead of the dropping RPM producing an increase in solenoid duty cycle. I see comparing the RPM and duty cycle sinusoids.
With a pure P controller the sinusoids will be inverted from each other (sinusoid of duty will be upside down compared to the sinusoid of RPM). That's because a dip in RPM produces a rise in duty. The D term should "mix in" a 90* phase shifted sinusoid. So as D is added, the duty cycle sinusoid should start "shifting left" as compared to the old P-only duty sinusoid. That is, the duty sinusoid should peak *before* the RPM has reached bottom. This is from the math:
-Derivative of a sinusoid is a 90* phase shifted sinusoid.
- If you add a 90* phase shifted sinusoid to a regular sinusoid, it looks like a sinusoid that's phase shifted between 0 and 90*.
- If you add an inverted, 90* phase shifted sinusoid, it phase shifts between 0 and -90* instead. (visually it appears to shift in the opposite direction)
What I see in Greg's datalogs is that the phase shift is *to the right* instead of to the left. This suggests that the D calculation is inverted (subtract instead of add, or vice versa). And the code snippet I posted, appears to be it. The P and I terms are added, but the D term is subtracted......
This is why practical D circuits in electronics are called "phase lead" circuits. Its sorta kinda like leading the clay pigeons when you shoot 'em.
Cheers.
Last edited by JasonC SBB; 06-14-2011 at 07:56 PM.
#219
Boost Czar
![](/mt2011/images_td/ranks/supporter1.gif)
![](/mt2011/images_td/ranks/admin.png)
iTrader: (62)
Join Date: May 2005
Location: Chantilly, VA
Posts: 79,688
Total Cats: 4,113
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
I have no issue with the code. but i don't have crazy throttled volume.
problem is, when they went to the ms3 they made a huge improvement with the a/c idle up adder...and they really have no motivation to backport things to older hardware and would like to move forward with ms3 features and improvements.
problem is, when they went to the ms3 they made a huge improvement with the a/c idle up adder...and they really have no motivation to backport things to older hardware and would like to move forward with ms3 features and improvements.
#220
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
I just feel the MS2extra code is very close to done. And it's very good. Maybe just a final update incorporating the mario b patch, and hopefully a solution to the D issue, and it'll be perfect. The data collected does show that the sinusoid moves to the right, not left. So there is something there not working properly...
I understand the focus is on MS3, but solving the PID issue will benefit MS3 as well.
I understand the focus is on MS3, but solving the PID issue will benefit MS3 as well.