miatauser884

iTrader: (11)

i need an ms3 microsquirt module

muythaibxr

Lucky. I had 4 bytes of flash left in page 5 where the boost control settings live. I only needed 2 bytes. I've both fixed the feature in MS3 so it works as an offset from the target (when boost gets above target - this setting, PID activates, and before that the valve remains closed), and backported it to ms2.

I'll need to do a quick bench test before giving it to you. I should have time to fire up my bench and do a quick test tomorrow evening.

Ken

miatauser884

iTrader: (11)

nice, cant wait to tune. Snowing now, so it will be a day or two.

muythaibxr

Cool, That gives me time to more thoroughly bench test.

Ken

Braineack

iTrader: (62)

sometimes I wonder why they didn't do that in the first place... considering you need little off the mainboard (kinda making the v3.0 board useless/extra) and the ms3x is connected by ribbons. Just need to combine them on one board and add the power input circuit and blamo!

miatauser884

iTrader: (11)

Well, I kinda feel like the diypnp gys got the shaft considering how soon ms3 came out after these. I guess at the end of the day I don't need all of the features, but it is becoming obvious that the MS2 is at the end of its road as far as software evolution due to it's memory allocation.

There has to be a way to upgrade a DIYpnp to MS3

Braineack

iTrader: (62)

they've been working on it from what I hear.

muythaibxr

Actually, the MS3 was in planning before James and I ever heard of the DIYPNP. It was a surprise to us around the megameet in '09 when we got our first MS3s for testing, and Jerry introduced the DIYPNP with the uSquirt module.

The MS3 actually started real planning in '08 at that megameet, but even before that James had ms2/extra ported to the new chip and running on a demo board connected to a v3 board. That was in summer of '07.

Ken

Braineack

iTrader: (62)

yeah, the DIYPNP is based around the microsquirt...which was already in existence.

they just need more MS3Xcrosquirt

miatauser884

iTrader: (11)

As soon as there is one that plugs into my diypnp, then I'm on it.

Put me on the list for testing

I think I said earlier that what I have is plenty, but I like having all of the latest and greatest software/hardware. That's why I'm running the 3.1 code.

How hard would it be to make a harness that plugged an MS3 into the ecu port so that I could just unplug my diypnp and have an MS3 take its place?

It seems like that would be pretty easy.

Jump on it Brain.....quasi plug and play MS3 for those that already have a diypnp.

JasonC SBB

I *have* been staring at the equation in the link you gave:
http://bestune.50megs.com/typeABC.htm

However what I missed was the part halfway down starting with the statement "the fact that the setpoint should be removed from the P-term and D-term because otherwise the P-term will become an infinity (a Dirac function) and so will the D-term if there is a step change in SP. Therefore, the traditional PID equations (1) and (2) should be changed to"

And then it shows the P and D terms changed to Kp*MAP and Kd*d(MAP)/dt

Which BTW automatically makes it a type C. I don't know if you mean you took the above equivalent-to-type-C and further "type-B-fied" it.

My original statement, that it relies on I to find the "correct" duty cycle, stands. You need a large I to find it quickly (so the duty cycle ramps quickly), and large I tends to cause instability. (I'm assuming you start from 0 duty cycle whenever the target transitions from off boost into boost)

As for the P term appearing to be backwards, that's because you do the P term as

Pterm = Kp * -MAP

So as 'I' works its way up and boost increases, the Pterm reduces duty cycle, which is what it's supposed to do, but it goes from 0 to more negative, explaining why it seems backwards - that more P slows the boost rate of rise. This is as opposed to the P term initially producing a positive number to get a large duty cycle, and diminishing as boost rises.

This is akin to a standard PID wherein the P initially produces a large positive number, but the 'I' has a large negative number preloaded into it (= to -P) which cancels the initial P, resulting in zero CO whenever the loop is intialized.

I suggest changing the P term to the standard approach
P = Kp*E
and initialize the I term to -P whenever the target transitions into boost, in order to prevent the windup problem in the same way. This also changes your loop from type C to type B, so that a step up in target while in boost already, will force the P term to add duty cycle. (You will also need to clip the P term).



I hope other users, with TPS controlled boost target, know how to use their right foot properly.

miatauser884

iTrader: (11)

Now way, it's like navigating without a gps.

Big sign says "this way to your destination" but gps says go "this way" then we have an internal struggle.

Agree, we can't let technology override common sense and good practice.

JasonC SBB

Can someone post a datalog 1-2-3 or at a 2-3 or 3-4 shift?
I'm curious what duty cycle does when boost target steps up at high RPM.

Braineack

iTrader: (62)

Talk to Ben, I know they were fooling with the idea.

miatauser884

iTrader: (11)

I will when I get home. I actually have one taken while I was tuning this. It is not with the PID tuned to perfection.

muythaibxr

Honestly, the way I have it now works fine if it's tuned well. I think sometimes tuning PID throws people for a loop (though I've tailored my manual to explain how to tune it even with the behavior being a little different from standard PID). What you are suggesting there is essentially what I already have for the I term (again since it's CO = CO + PID). There isn't a windup problem on the I term also because of the way I did this. I don't think it makes sense to have both P and I essentially work out to the same math.

I essentially took what they had for "type B" there on that site, and implemented it. I had actually started with type C, but that made P term unresponsive to target changes, and I thought it was a good idea for the algorithm to respond to target changes, so type B it is.

Further testing by people (even on this forum) showed that type B worked better than type C had, so I stuck with type B.

As a result, we already get good response when the target changes (even with P only) because P incorporates the setpoint. For example, if you're in boost, and you lift off the throttle, dropping the target, the wastegate will open very quickly as a result of P, then the I part of PID will get you the rest of the way to the target.

We actually support a 3D table with TPS vs RPM... this one user just didn't *want* to control his right foot properly (believe me, that was the first thing I suggested).

Ken

muythaibxr

I'd say wait till you have PID tuned.

That way the P term will be responding to the initial target change instead of it all being the I term.

(previously when I used a type C loop, the P term would not have responded, and it would've been all I term; I switched to type B in order to make P respond to target changes).

Braineack looks to have his tuned pretty well, so it might be worthwhile to show what his does with a target change once already in boost.

Ken

Braineack

iTrader: (62)

if you notice my log the boost increase towards redline, i have that built into my targets map. it's nice.

JasonC SBB

Brain do you have logs showing a couple of upshifts? I'm curious how quickly duty cycle ramps up. If you look at my logs on page 6, duty hits 100% then ramps down pre-emptively before hitting target 9from the D), to prevent overshoot.

JasonC SBB

Are you talking about the type B eqn near the beginning of the article, or one of the equations in the middle, where the setpoint info is gone from the D and P?

You didn't cripple the algorithm for everyone else, just for this one guy, did you?