PDA

View Full Version : LMM-commanded boost



killerbee
January 19th, 2010, 11:45 AM
Is there a commanded or desired boost PID? I don't see one. My actual boost is not jibing with the tables.

GMPX
January 19th, 2010, 01:12 PM
I don't think so, GM.BOOST2_DMA is the measured boost pressure, we only added that due to the usual boost pressure upper limit problem on the GM boost PID.

killerbee
January 19th, 2010, 01:24 PM
I have too much boost. Don't know what to do with it all. The tables don't predictably reduce it.

bballer182
January 19th, 2010, 02:07 PM
In BBL

DESTCBOST (desired turbo boost (kpa)):good:;)

killerbee
January 20th, 2010, 08:49 AM
Here is shot. Makes no sense really. B2206 and B2209 tables are asking for 19 psia, transient set to the same, and I am getting 30.

I have no idea what is going on here, but I am afraid of blowing up the turbo if I can't assess and fix this.

http://forum.efilive.com/attachment.php?attachmentid=7043&d=1264016748

GMPX
January 20th, 2010, 11:26 AM
Michael,

I think it's time for the dreaded DMA PID additions :bawl:.The process the ECM goes through is as follows:


First determine if the EGR is on or off, then select the des boost tables based on that, lets assume it's off.
Get the values from all 3 boost tables (Low, Med, High).
Multiply each by the altitude factor
Add all altitude corrected values for a final base boost value.
Then it does the ECT & Intake temp correction and adds the result to the previous base boost value for the final des boost value.

I can only think that it might be an issue where the vane position is actually causing the mismatch, overriding the desired boost as it were. In fact, have you tried playing with the Vane position tables only to see if they are having the final say?
There is different strategies for when regen is active, but I am guessing this is not your issue.

Cheers,
Ross

killerbee
January 20th, 2010, 11:44 AM
I am at 14.1 psia, so my factor is 1 for low, 0 for the others.

I did set all boost values in the 3 low tables to 14.1, and ran a test. Attached is the log. It was all over the map, at times looking like it was complying (low vane), and then it would shoot into space. Log attached.

I do get a sense that vane position is driving boost when this happens, but I can not narrow down what tables would be doing it, if any.

I did a controlled vane position test yesterday, and had equally inconclusive results.

bballer182
January 20th, 2010, 03:49 PM
Have you tried using B2232 and B2231 to isolate the problem.
Setting the two tables with high mm3 values would eliminate the referencing of the vane tables and would only look at the desired boost.
Conversely setting the two tables with low to zero mm3 values would make the ecm go solely off the vane tables and disregard the desired boost.

(theoretically)

I've done this a few times to isolate boost/vane issues that have arisen.

killerbee
January 20th, 2010, 05:51 PM
High? B2231 should be lowered, not increased, correct?

Big D
January 20th, 2010, 07:06 PM
I think BB is saying that with high values this will tell the ecm to not reference the vane position, bypassing those tables and only using boost tables. So by raising B2231 it will not enable ecm control of vane pos.

I will test this on Sat to confirm. I am in the same situation as you KB with spikes in boost and no clear references to tables.

Good thread.

bballer182
January 21st, 2010, 03:32 AM
Have you tried using B2232 and B2231 to isolate the problem.
Setting the two tables with high mm3 values would eliminate the referencing of the vane tables and would only look at the desired boost.
Conversely setting the two tables with low to zero mm3 values would make the ecm go solely off the vane tables and disregard the desired boost.

(theoretically)

I've done this a few times to isolate boost/vane issues that have arisen.



High? B2231 should be lowered, not increased, correct?

The definitions of those two tables are a little hard to understand correctly and probably should say something to the affect of "it uses the vane tables when the main rate goes above X and uses the boost table when the main rate goes below X" you know something like that.

But yeah what i did in order to eliminate the boost tables was set both tables at 200 so that the ECM would reference the vanes only and throw desired boost out the window and eliminating the possibility of getting a boost code too. so lowering them should net you the opposite result.

without seeing your log vs. the tune i would bet that the vane and boost tables are mis-matched and the main rate is varying so the the ECM is falling in and out of the main rate that dictates whether or not it is supposed to use the vane tables or not.

Just a guess.

killerbee
January 21st, 2010, 03:48 AM
Lowering them did nothing for me, in fact, the logs above are with these tables lowered. It sounds like you have no boost control either then,

This LMM has an endless number of frustrations. Do you really want to run on vane position? I am going to have to set up a separate weekly anger management session, just for this platform.

duramaximizer
January 21st, 2010, 06:30 AM
This LMM has an endless number of frustrations. Do you really want to run on vane position? I am going to have to set up a separate weekly anger management session, just for this platform.

I thought you drive off vain position anyway it's just a matter of how you get there. You are wanting boost to control vain position like it's sapose to and then you don't have to worry about target vain position.

I read this, and maybe I am missing it but which one has final say on vain position, the target vain position table or the desired boost table. Why would you want a target vain position table?

:confused:

killerbee
January 21st, 2010, 07:13 AM
The whole point of variable geometry, is MAP governed boost. Without the ability to regulate it, there is no point in even having a map sensor. For that matter, you may as well just throw on a wastegate. At this point, that is what is called for, unless there is a way to cap boost production.

As far as final say on vain position, that is mute at this point. Actual logged vane has no resemblence to what is entered in the tables.

Max vane does seem to cap vane position, but as far as regulating boost, that is worthless. Max vane is necessary for transient considerations. It is very valuable in enabling quicker spoolup. If I reduce all those numbers, we get a slug performance-wise.

GMPX
January 21st, 2010, 03:26 PM
bballer182 is on the money with setting B2231 & B2232 high to stop the ECM trying to correct the boost away from the desired tables.
With those set high it should just use Desired Boost + ECT Boost + IAT Boost as the determining factor. If commanded fuel is within the window of B2231 & B2232 then the ECM will still use the boost values but they are corrected using a PID controller routine, this is what will (should) be causing the erratic control based on what the desired boost values should be.
Looking at the table values you can see that GM use the desired boost tables only when at idle, but about about 900RPM they use the correction.
If someone is brave I can attempt to find and add in the PID control tables if someone want to play with them. PID loop calibration = :wallbash:

Cheers,
Ross

duramaximizer
January 21st, 2010, 03:37 PM
Baby steps, but I am will to help, you just have to let me know what you need from me and tell me how. LOL I can do logs etc etc.

BTW I didn't know 2242 was a table, but I love it. :)

duramaximizer
January 21st, 2010, 03:55 PM
The whole point of variable geometry, is MAP governed boost. Without the ability to regulate it, there is no point in even having a map sensor. For that matter, you may as well just throw on a wastegate. At this point, that is what is called for, unless there is a way to cap boost production.

As far as final say on vain position, that is mute at this point. Actual logged vane has no resemblence to what is entered in the tables.

Max vane does seem to cap vane position, but as far as regulating boost, that is worthless. Max vane is necessary for transient considerations. It is very valuable in enabling quicker spoolup. If I reduce all those numbers, we get a slug performance-wise.

I understand the MAP governed boost. I thought if in fact the desired boost was "the table," then then when you stand on it, it should adjust the vains to make the boost accordingly. Guess that doesn't work like it should.

GMPX
January 21st, 2010, 04:08 PM
BTW I didn't know 2242 was a table, but I love it. :)That eliminated one 'what the?' question on LMM boost control, I do remember adding that one in real time with someone testing on the other end!

Cheers,
Ross

killerbee
January 21st, 2010, 04:17 PM
bballer182 is on the money with setting B2231 & B2232 high to stop the ECM trying to correct the boost away from the desired tables.
With those set high it should just use Desired Boost + ECT Boost + IAT Boost

Description of the table. Did I misinterpret this?

"Based on the commanded main fuel rate and RPM, this table will enable the ECM to control boost pressure once the commanded fuel rate goes above the values in this table."


I took this to mean that I needed low values in order to "control boost pressure"

duramaximizer
January 21st, 2010, 04:20 PM
Good Job, I think that was causing most of my wheel hop during shifts while truck pulling! I am willing to work with you on any LMM problems.

I am willing to play with PID's. I know adding the files in the right spot can be a little tricky, but once over that, I can help.:) BTW I am running a public release, not the beta.

GMPX
January 21st, 2010, 04:25 PM
If actual mm3 > B2231 ECM controls boost
If actual mm3 < B2232 ECM does not control boost

Now by saying does not control boost is not 100% correct, but it bypasses the PID controller for boost so it should just aim for the base boost values.

If you look at the numbers in those tables you can see at idle they bypass the PID, above that it's pretty much enabled the whole time.

Cheers,
Ross

bballer182
January 21st, 2010, 04:48 PM
I wouldn't mind having a whack a the PID controllers. I messed a little with the fuel pressure ones.

GMPX
January 21st, 2010, 05:42 PM
Did they help? Or make a significant difference to what you were trying to achieve?
Normally the PID calibrations would only need to be altered from factory settings if there is a big enough change (physically) in what they are controlling.

bballer182
January 21st, 2010, 05:51 PM
With a big rapid request in fuel pressure i could get it to change quicker and smother than stock. The changes are almost negligible performance wise but i can notice it on logs. I would imagine that the boost PID routines would be a little more noticeable than the fuel pressure.

killerbee
January 21st, 2010, 06:26 PM
Did they help? Or make a significant difference to what you were trying to achieve?
Normally the PID calibrations would only need to be altered from factory settings if there is a big enough change (physically) in what they are controlling.

I will take a closer look tomorrow, if I can get through a regen. But my logs with all values set to 95mm, were significantly high.

Can you shed some understanding on why a pid requires calibration? Could this also help timing and pressure? These have disparities also, especially pressure.

bballer182
January 21st, 2010, 07:09 PM
I will take a closer look tomorrow, if I can get through a regen. But my logs with all values set to 95mm, were significantly high.

Can you shed some understanding on why a pid requires calibration? Could this also help timing and pressure? These have disparities also, especially pressure.

P.I.D.

not like parameter identifier

look it up on wikipedia.

bballer182
January 21st, 2010, 07:11 PM
I will take a closer look tomorrow, if I can get through a regen. But my logs with all values set to 95mm, were significantly high.

Can you shed some understanding on why a pid requires calibration? Could this also help timing and pressure? These have disparities also, especially pressure.

The P.I.D. for fuel pressure is in all OS' (LBZ/LMM) but 8594...

GMPX
January 21st, 2010, 07:56 PM
Sorry, should have pointed that out from the begining, PID in this case means proportional–integral–derivative (http://en.wikipedia.org/wiki/PID_controller) controller.A good read before bed :grin::grin:

duramaximizer
January 22nd, 2010, 07:41 PM
OMG trig? D(y) D(x), functions, summations, limits ....... Maybe I should go back to college... I always liked a good challenge.

bballer182
April 17th, 2010, 04:17 AM
Thread from the dead but i see the the P.I.D boost tables made it into public release!

Thanks Ross!:good:

killerbee
April 17th, 2010, 04:36 AM
I have not had the courage to mess with these. Process controls was a favorite subject, but it was so long ago.

I do see some serious vane and boost swings under steady state conditions sometimes. I am not sure where to begin, P, I , or D.

vortecfcar
April 17th, 2010, 10:14 AM
Very nice addition!

Thanks Ross,

Nick

Probably one of the most practical/useful excerpts from the article:

Where the tuning parameters are:

Proportional gain, Kp
Larger values typically mean faster response since the larger the error, the larger the proportional term compensation. An excessively large proportional gain will lead to process instability and oscillation.

Integral gain, Ki
Larger values imply steady state errors are eliminated more quickly. The trade-off is larger overshoot: any negative error integrated during transient response must be integrated away by positive error before reaching steady state.


Derivative gain, Kd
Larger values decrease overshoot, but slow down transient response and may lead to instability due to signal noise amplification in the differentiation of the error.