JasonC SBB

The same wrong D sign may be present in the MS3. Here we have a guy who will test improvements.

miatauser884

iTrader: (11)

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.

Greg G

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

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

muythaibxr

What I'm trying to say is that according to the site I linked, I've implemented the D term *exactly* as the site has it there, and I have tested "D" only on the bench, making sure that it reacts in the correct direction.

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:

Notice the minus before the D gain is multiplied in and compare to my code.

Ken

muythaibxr

Do you want to pay me to work on ms2 then? I work on both ms2 and ms3 in my *spare time*. I don't have time to do both for every feature.

Ken

richyvrlimited

iTrader: (1)

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?

muythaibxr

If the direction of response is correct, then the sign is correct. It lags 2 loop iterations because of the form of PID I used and the requirement that type-C PID use the 2nd derivative... so changes will be up to 2 loop iterations behind. Please Please PLEASE look at the equation, compare it to my code, and see that they're the same.

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

y8s

iTrader: (8)

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.

Greg G

Richie,

I think you meant to say it was moving to the right rather than left

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

Greg

JasonC SBB

The amount of shift-right in the logs (which is the wrong direction), is quite a bit more than 2 ticks (which is 200 ms in Greg's setup IIRC). Eyeballing the timescales, the shift-right appears to be about > 500 ms.

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.

JasonC SBB

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.
Note at this point all 3 have negative values

Now come some more scaling factors. Note none of them invert the sign.Now here is the calculation for the duty cycle.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 ... ??

JasonC SBB

Here is the MS2 code.Comparing the 2, the MS2 code should have been
Which is also appears wrong based on the example I made above. (This suggests there's an error in that quoted page. I think the middle term in the quote from the page should be
- KiTe(k) which would make everything make sense.)

What am I missing?

richyvrlimited

iTrader: (1)

Man I wish I was cleverer and could understand all this stuff...

Greg G

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

muythaibxr

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

muythaibxr

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

richyvrlimited

iTrader: (1)

Ken, if you'd be willing to do that I know of at least 2 people who would try it in a shot!

(me and Greg )

y8s

iTrader: (8)

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.

Greg G

Ready!

Greg G

The way I understand D (from an non engineer point of view) is that it does not react to P nor I, but to the rate of change from the set point. So, the idle valve will be driven by a number based on the P I D, not necessarily in the same direction, but with different factors influencing their value (P: amount of error; I: error over time; D: rate of change from set point). D is also driving the controller output, independent of P or I. So with P and I constant, the D value will increase or decrease depending on the rate of change, and that will cause the apparent 'counteraction' or 'cushioning' to the P and I values. And it will always be acting opposite to the direction of the rate of change of the setpoint. So it will only have a strong action (depending on the D value) if the rate of change is high, like the idle dip from AC engagement. This is also why a higher D value will cause an apparent shift to the left of the CO sinusoid.

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

Having said that, I am curious now why we are encouraged to use as little D as possible...