mk e wrote:

apalrd wrote:

I would play with it in EL but my main computer is a Mac.

is that even allowed for anyone calling himself an engineer?

MATLAB/Simulink and NX both run fine, that's the majority of what I need.

mk e wrote:

It a power generated minus power used. The power used is friction and pumping losses which are based on the BMEP formula... times 2 because it didn't seen enough...so it's a bit of a guess. The flow is based on TPS and available flow area, and some tables to convert to MAF and then MAF to MAP...which feeds the pumping losses.

Right now the throttle stay open until it hits the limit (as you want on a performance setup) but then simply can't react quickly enough to close it so it hits the hard stop and bounces the throttle closed in 4-6 bounces. I may do something to prime the PID so when it hit the soft limit it slams the throttle shut. It works with a less violent input, but WOT in neutral with a powerful engine....it bounce a bit playing catch up.

For the rev limiter, hitting redline in WOT in neutral will require almost no throttle to maintain RPM. If you have a very strong derivative term, it should detect this and request a very large negative throttle if the error rapidly approaches zero. If you are far away from the target, the proportional term will also request a very large positive throttle (to bring RPM up to target), so they will cancel and you'll end up with nothing. But as error becomes smaller, the proportional term will fight much less and the derivative will become huge. You could also use a table for P/I/D gains from RPM error to decrease the D and I at low RPM, and increase the P and I at high RPM.

Another option is an algorithm called 'take back half'. Here, you store a state variable 'h' and calculate error 'e' (setpoint - actual). The output 'o' from the block (the throttle position maximum from 0 to 1) is equal to o = h + integrate(e * k). Every time e changes sign, average h and o and set this as the new h. h will eventually get closer and closer to the TPS required to hold RPM, so the k term is less necessary every time it oscillates.

Edit: I didn't explain it very well. There are two variables stored between loops, h and o. e is calculated each loop. o = o + e * k. If e changes sign, then h = (h + o) /2 and o is reset to h.