DIYPNP install: inital tuning
#222
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
This seems to explain why my idle seemed to get worse when I added D term.
The almost immediate disregard for the MS2extra code pisses me off. I'm aware that MS3 is the future, but damn, let's perfect the MS2 code if possible. Especially since I'm stuck with MS2 with the diypnp. Don't even get me started on that BS.
The almost immediate disregard for the MS2extra code pisses me off. I'm aware that MS3 is the future, but damn, let's perfect the MS2 code if possible. Especially since I'm stuck with MS2 with the diypnp. Don't even get me started on that BS.
#223
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
I don't even consider it an MS2extra issue- for all we know it may be in MS3extra as well. So finding a solution is win-win ![](https://www.miataturbo.net/images/smilies/smile.gif)
The idle improvement on the Mario b code was discovered in ms2..and was implemented in ms3! Hope we can get it included in the next update, hopefully with the D solution as well. Again, sorry to impose on the programmers, but really, I think it'll help everybody. All I can offer are my pseudoscientific testing methods
![](https://www.miataturbo.net/images/smilies/smile.gif)
The idle improvement on the Mario b code was discovered in ms2..and was implemented in ms3! Hope we can get it included in the next update, hopefully with the D solution as well. Again, sorry to impose on the programmers, but really, I think it'll help everybody. All I can offer are my pseudoscientific testing methods
![wink](https://www.miataturbo.net/images/smilies/wink.gif)
#224
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
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......
Cheers.
Cheers.
Now, it does take up to 2 loop iterations to fully react since it's taking data from the previous two datapoints (due to being the 2nd derivative), and that can cause the phase shift, but the sign is definitely correct.
Again, take a look at http://bestune.50megs.com/typeABC.htm, specifically type C. It has the D term getting subtracted, and in practice in bench testing, it responds in the correct direction.
EDIT:
In case you didn't want to look at that site, here is the PID equation:
Code:
CO(k) = CO(k-1) - Kp[PV(k)-PV(k-1)] + KiTe(k) - Kd/T[PV(k)-2PV(k-1)+PV(k-2)]
Ken
Last edited by muythaibxr; 06-15-2011 at 05:31 PM.
#225
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
This seems to explain why my idle seemed to get worse when I added D term.
The almost immediate disregard for the MS2extra code pisses me off. I'm aware that MS3 is the future, but damn, let's perfect the MS2 code if possible. Especially since I'm stuck with MS2 with the diypnp. Don't even get me started on that BS.
The almost immediate disregard for the MS2extra code pisses me off. I'm aware that MS3 is the future, but damn, let's perfect the MS2 code if possible. Especially since I'm stuck with MS2 with the diypnp. Don't even get me started on that BS.
Ken
Last edited by muythaibxr; 06-15-2011 at 05:51 PM.
#226
Elite Member
iTrader: (1)
Join Date: Jun 2006
Location: Warrington/Birmingham
Posts: 2,642
Total Cats: 42
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Ken, see the other posts, and ignore the rant. This may be a relevant discussion to improving both MSII and MSIII's idle code.
If you look at the datalogs Greg has posted, you can clearely see the wave moving to the left rather than the right when more D is added, this is in contradiction to how it 'should' work and how you say it worked on the stim.
Must be worth investigating?
If you look at the datalogs Greg has posted, you can clearely see the wave moving to the left rather than the right when more D is added, this is in contradiction to how it 'should' work and how you say it worked on the stim.
Must be worth investigating?
#227
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Ken, see the other posts, and ignore the rant. This may be a relevant discussion to improving both MSII and MSIII's idle code.
If you look at the datalogs Greg has posted, you can clearely see the wave moving to the left rather than the right when more D is added, this is in contradiction to how it 'should' work and how you say it worked on the stim.
Must be worth investigating?
If you look at the datalogs Greg has posted, you can clearely see the wave moving to the left rather than the right when more D is added, this is in contradiction to how it 'should' work and how you say it worked on the stim.
Must be worth investigating?
As far as I'm concerned, the only thing there is to investigate is implementing the D term using a method more similar to ideal PID instead of type-C PID. The current code is correct as it stands though. The sign is not wrong.
Ken
#228
2 Props,3 Dildos,& 1 Cat
![](/mt2011/images_td/ranks/supporter1.gif)
![](/mt2011/images_td/ranks/smod.png)
iTrader: (8)
Join Date: Jun 2005
Location: Fake Virginia
Posts: 19,338
Total Cats: 573
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
For MS3, the D term is the same implementation (minus in front of the Kd term) for boost and VVT and both of those behave exactly as you'd expect.
I tuned I and P to obtain a very low steady state error and fast rise to target with minor overshoot.
Then I increased D until the overshoot was minimized within what I was comfortable with (say 5 kPa for boost, a degree or two for VVT).
And it works exactly as you'd expect PID to work.
I tuned I and P to obtain a very low steady state error and fast rise to target with minor overshoot.
Then I increased D until the overshoot was minimized within what I was comfortable with (say 5 kPa for boost, a degree or two for VVT).
And it works exactly as you'd expect PID to work.
#229
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
I think you meant to say it was moving to the right rather than left
![Laugh](https://www.miataturbo.net/images/smilies/laugh.gif)
So for some reason, on my car, D is moving the sinusoids the wrong way.
Ken,
Thanks for taking the time to discuss this. I do appreciate it, and all the work you put into the code. As I said, in all other aspects, it is running great! Maybe just a bit more, and it'll be as close to perfect as we can get it. If there is no solution to the D issue, may I just again request a % duty adder for the idle valve, hardware triggered?
Guys,
Let's keep this discussion friendly shall we? I know it's MT but maybe just here we can play nice
![Laugh](https://www.miataturbo.net/images/smilies/laugh.gif)
Greg
#230
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
AND, it shifts right MORE as Greg increases the 'D' gain. If the sign were correct, increasing D should have started canceling out the delay due to the calculation ticks and should cause it to begin shifting left as D is increased.
#231
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Here is the relevant code.
Let's check the signage.
Let's pretend target is 1000 and 3 samples go like this:
1000
1000
900
When 900 comes around the P, I, and D terms should all open the solenoid.
rpm_error = PV - SP;
900-1000 = -100
pwmidle_deriv = PV - (2*PV_last[0]) + PV_last[1];
900-2000+1000 = -100
Kp = ((long)((PV - PV_last[0]) * flash5.pwmidle_Kp));
900 - 1000 = -100
Note at this point all 3 have negative values
Now come some more scaling factors. Note none of them invert the sign.
Ki = ((((long)rpm_error * flash5.pwmidle_ms) / 1000) * flash5.pwmidle_Ki);
Kd = ((long)pwmidle_deriv * (((long)flash5.pwmidle_Kd*10)/flash5.pwmidle_ms));
Now here is the calculation for the duty cycle.
tmp1 = IACmotor_pos - (((long)(Kp + Ki - Kd) * ...
So Kp, Ki, and Kd are all negative numbers, and with the above equation Kp and Ki cause the duty cycle to increase, but Kd causes the duty cycle to decrease ... ??
Let's check the signage.
Let's pretend target is 1000 and 3 samples go like this:
1000
1000
900
When 900 comes around the P, I, and D terms should all open the solenoid.
rpm_error = PV - SP;
900-1000 = -100
pwmidle_deriv = PV - (2*PV_last[0]) + PV_last[1];
900-2000+1000 = -100
Kp = ((long)((PV - PV_last[0]) * flash5.pwmidle_Kp));
900 - 1000 = -100
Now come some more scaling factors. Note none of them invert the sign.
Ki = ((((long)rpm_error * flash5.pwmidle_ms) / 1000) * flash5.pwmidle_Ki);
Kd = ((long)pwmidle_deriv * (((long)flash5.pwmidle_Kd*10)/flash5.pwmidle_ms));
tmp1 = IACmotor_pos - (((long)(Kp + Ki - Kd) * ...
#232
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
tmp1 = IACmotor_pos - (((long)(Kp + Ki - Kd) * ...
tmp1 = IACmotor_pos - (((long)(Kp - Ki + Kd) * ...
- KiTe(k) which would make everything make sense.)
What am I missing?
#234
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Well that's another reason for this thread! We can all learn together!
I found this on the net. Might be useful to somebody- it's way above my head :P
http://www.dee.ufc.br/~sdaher/aciona/PDF/PID/DWYER.pdf
I found this on the net. Might be useful to somebody- it's way above my head :P
http://www.dee.ufc.br/~sdaher/aciona/PDF/PID/DWYER.pdf
Last edited by Greg G; 06-16-2011 at 06:49 AM.
#235
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
That the code I wrote is exactly what's in the page I referenced? That said code is what several commercial applications use?
Or perhaps that when you test each term independently on the MS, the response is in the correct direction?
Tested on the MS?
The response is in the correct direction, the code is correct.
Ken
Or perhaps that when you test each term independently on the MS, the response is in the correct direction?
Tested on the MS?
The response is in the correct direction, the code is correct.
Ken
#236
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Let me try a different way of explaining.
Lets try a decrease in RPM over 2 samples:
1200
1000
900
pwmidle_deriv = PV - (2*PV_last[0]) + PV_last[1];
900 - 2000 + 1200 = 100
That's now positive and will react in the same direction as P and I. (P and I will still be negative in this example).
I can come up with a whole list of examples where the output of the D (without even considering weather it's added or subtracted to/from the rest) doesn't necessarily have the sign you'd expect.
The characterization I'd give it is:
- If RPM is constantly increasing or constantly decreasing over time, D won't have a huge effect, but its effect will be in the same direction as P or I (depending heavily on if the rate of change is increasing or decreasing)
- If RPM just started to change, the first response will be a very small response in the opposite direction of P and I (hence its dampening effect on P and I) then if RPM keeps going that direction, it'll start to respond in the same direction as P and I.
- If RPM was changing and stops, what you'll actually see is while RPM is still changing, D will respond in the same direction as P and I. As the rate of change slows/stops, the D term if high enough will actually cause a brief response in the opposite direction before disappearing.
So, the D term in ideal PID is the 1st derivative of the actual error. In my code, the derivative of the whole PID equation was taken (since I'm summing the end result of the whole equation instead of using a bias + the PID output), which results in the D term needing to be the 2nd derivative.
That 2nd derivative form of the D term can cause "interesting" (but still correct) behavior, but I don't necessarily think it can be directly compared to what happens in the ideal form of PID.
I do think that taking the 2nd derivative of the error and adding that instead of subtracting it (form A of PID) may have a response closer to what you're expecting though.
I could easily make up a type D PID which keeps the P term as it is, but incorporates the setpoint into the D term to see if that gives the behavior you're expecting (essentially type C PID with type A's D term).
Ken
Lets try a decrease in RPM over 2 samples:
1200
1000
900
pwmidle_deriv = PV - (2*PV_last[0]) + PV_last[1];
900 - 2000 + 1200 = 100
That's now positive and will react in the same direction as P and I. (P and I will still be negative in this example).
I can come up with a whole list of examples where the output of the D (without even considering weather it's added or subtracted to/from the rest) doesn't necessarily have the sign you'd expect.
The characterization I'd give it is:
- If RPM is constantly increasing or constantly decreasing over time, D won't have a huge effect, but its effect will be in the same direction as P or I (depending heavily on if the rate of change is increasing or decreasing)
- If RPM just started to change, the first response will be a very small response in the opposite direction of P and I (hence its dampening effect on P and I) then if RPM keeps going that direction, it'll start to respond in the same direction as P and I.
- If RPM was changing and stops, what you'll actually see is while RPM is still changing, D will respond in the same direction as P and I. As the rate of change slows/stops, the D term if high enough will actually cause a brief response in the opposite direction before disappearing.
So, the D term in ideal PID is the 1st derivative of the actual error. In my code, the derivative of the whole PID equation was taken (since I'm summing the end result of the whole equation instead of using a bias + the PID output), which results in the D term needing to be the 2nd derivative.
That 2nd derivative form of the D term can cause "interesting" (but still correct) behavior, but I don't necessarily think it can be directly compared to what happens in the ideal form of PID.
I do think that taking the 2nd derivative of the error and adding that instead of subtracting it (form A of PID) may have a response closer to what you're expecting though.
I could easily make up a type D PID which keeps the P term as it is, but incorporates the setpoint into the D term to see if that gives the behavior you're expecting (essentially type C PID with type A's D term).
Ken
#237
Elite Member
iTrader: (1)
Join Date: Jun 2006
Location: Warrington/Birmingham
Posts: 2,642
Total Cats: 42
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
I could easily make up a type D PID which keeps the P term as it is, but incorporates the setpoint into the D term to see if that gives the behavior you're expecting (essentially type C PID with type A's D term).
(me and Greg
![wink](https://www.miataturbo.net/images/smilies/wink.gif)
#238
2 Props,3 Dildos,& 1 Cat
![](/mt2011/images_td/ranks/supporter1.gif)
![](/mt2011/images_td/ranks/smod.png)
iTrader: (8)
Join Date: Jun 2005
Location: Fake Virginia
Posts: 19,338
Total Cats: 573
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
It makes sense to me that D is negative if you consider that its job is to counteract the approach to the set point. It is counteracting the P and I terms that are driving toward the target.
D must be negative or it will increase overshoot.
D must be negative or it will increase overshoot.
#240
![Default](https://www.miataturbo.net/images/icons/icon1.gif)
Or to put to the extreme, with P and I set to 0, D will still have it's own action. Which shows its independence from those 2 terms.
I hope I explained myself. Again, this is how I understand it. The calculation part, I leave to those with the aptitude for it
![](https://www.miataturbo.net/images/smilies/smile.gif)
Having said that, I am curious now why we are encouraged to use as little D as possible...
Last edited by Greg G; 06-16-2011 at 11:56 PM.