make something simpler for reverse a 9x16 table is not needed
Ashford,
There are already two pressure limiting options for reverse: use the table, or use a fixed user value. 100% and a fixed setting the default. You can change the fixed value to whatever you like (between 100 and 40, lower number gives less pressure since this is a bleed valve and the PWM% is 100-setting). See:
http://www.msgpio.com/manuals/mshift/V41tune.html#gs and a discussion here:
viewtopic.php?f=4&t=583#p3294 I am not sure why an additional table is needed for this (but then my use for reverse is pretty much only for backing out of parking spots on pavement, and other users may have more extreme circumstances I haven't imagined in which they are using reverse).
instead of using a maximum shift pressure limiters for individual gears use a 6 point graph for shift pressure load = pwm like mentioned for reverse for each gear
This is essentially what the 16 x 9 line pressure table does. The line pressure is set for two reasons: it must keep the trans from slipping while in gear, and it must provide adequate but not excessive pressure while shifting. The code sets the pressure based on the lower of the line pressure from the table or the user limit. This allows the user to be sure the shift pressure won't be excessive (with the limit), while letting the user 'soften things up' at lower loads (using the 16x9 table instead of your proposed 6 element tables). These slip/shift requirements are similar, on identical components, so perhaps you can show me precisely why the 16 x 9 table isn't working for you (the table concept was developed from GM's design documents specifying pressure and shift tables for the 4L60e, which are set as speed x load). One of the many advantages of user 16x9 tables is that users can put the values where they need them most (i.e., they might only have one PWM for the 1-2 shift, but 8 for the 3-4 shift) without restrictions on how they place them.
the ford 4r70 2nd gear require less pressure than the rest of the gears this is in the factory programming.
If you have both MAP load tables, or both TPS load tables, you can easily accomplish this by setting your lower value all the cells in the line pressure table that have 2 in the corresponding shift table. If you split the table's load indexes (one TPS and one MAP) then you can't do this, but that's a choice you make in setting up that way. Just to be clear for anyone else that stumbles on this thread though, I personally think sure MAP is a much better measure of load for 95% of users, so that's what I recommend anyone with a reasonable intake manifold vacuum signal use (possibly adjusting the smoothing value to get a stable signal, and the load hysteresis value to prevent gear hunting). TPS load was only put in initially for those that didn't have CAN, or that had no usable vacuum signal (hot cam, etc.) and had to use TPS (TPS is a poor indicator of load, especially at low rpms). I made the split loads available because users asked for it, and it was easy, but it was never going to be a preferred option, and comes with a set of compromises on the setup.
i would like to have a load lockout for overdrive
As you say, this can easily be done with MAP based tables. The code does allow locking out the TCC based on load (the TCC is typically the most torque limited component in high gear). With TPS, you could decide what level of throttle is 'unwise' (presumably the amount that gives an unhealthy level of torque) and make all the cells above that level a lower gear. However, things like rev limiting come into play, so I hesitate to put this in play without a clear demonstration that the current algorithm can't be made to work.
However those are just initial thoughts, and I will think about your suggestions much more. For example, maybe what I need to do is have a combination MAP/TPS based load (like MegaSquirt has had for years), though I am not sure that puts us any further ahead and would have to think about it. Or maybe I could make both indexes on the table user-settable to MAP, TPS, speed, rpm, temperature, etc. like the spare port 0 table. Then you could have PWM by MAP versus TPS, or any other combo you liked... But all of these make the code and documentation more complex, and harder to understand for the user.
I would also like to say that I think it is bad engineering practice to simply keep adding tables and factors to 'correct' the operational algorithms for physical systems like a transmission. This causes a number of problems, including increasingly complex and harder to write, debug, test, document, configure and tune the resulting code; as well as increasing deviation from the physics of the hardware we are controlling (making it harder to apply physical logic and experience to the code). So ultimately it is best if such additions refer to physical quantities and verifiable measurements.
But if enough users want the code changed in any particular way, I will certainly do it regardless of whether I think it is a great idea or not.
Lance.
. it show this twice in the logs.