VE table changes (increasing size)

[beestoys]

Is there any hazard to copying a 93 VE table into a 95 PCM. Both are LT1's the 93 VE tables have a higher resolution. Would this cause a brick effect of the PCM I have copied and flashed the matching table parameters with no ill effects. I would like to copy over the whole table if it won't crash something. Figure the greater resolution can't hurt.

[EagleMark]

Figure the greater resolution can't hurt.

In this case it would... can't change a table that is already in the Mask. Unless you want to re-write the entire bin to make sure it works...

[RobertISaar]

wouldn't need to rewrite a lot of code, but there is some degree of uncertainty when patching code that runs on a flash PROM.... make a code mistake with a MEMCAL based ECM and you get odd operating characteristics or an engine that doesn't even start. oh well, try again, no harm done other than some damaged pride unless you REALLY screw something up.

do it with a flash unit and you may brick it, requiring you to pull the flash PROMs from the board, burn them manually and re-connect them, or just replace the PCM entirely and try not to make the same mistake.



for this reason, i've patched the P66 V6 code as little as possible and with a lot more prior testing since i don't have a burner that will work with these PROMs yet. i also don't look forward to removing the PROM from the board and soldering a socket down in its place. what would be neat...... is if a hot-swapping program would be possible to impliment for a case like this. if there was a PROM that was modified and caused a brick event, pull it, insert another with some special code on it that would be copied to RAM upon boot, pull that PROM, insert the bad one and then flash a known good BIN into it using no external burner. i THINK this is possible to do, but i'm not 100% on that.

[beestoys]

In this case it would... can't change a table that is already in the Mask. Unless you want to re-write the entire bin to make sure it works...

Thanks Eagle
Has a feeling that might be the case so I only copied over the rows that matched. Still trying to get this over rich thing sorted. it's fat all across the board so thinking I either have a constant I haven't hit right yet or my 02's are toasted. Got the pieces to put in the wideband to verify just need to drop the headers and install the 02 socket's. Plan to order the Earl's pressure seal inserts once I figure out what's in there.
Another question pertaining to VE tables I see a VE trim enable with Scan9495 going active and inactive. Could someone explain what the function of this is?

[EagleMark]

I've never used Scan9495. Got everything I need in the TP ADX... as far as VE Trim enable it sounds like that means Closed Loop is on?

[brian617]

VE Learn would be my guess. Have seen similar PIDs when using Snap-ON Modis.

[beestoys]

VE Learn would be my guess. Have seen similar PIDs when using Snap-ON Modis.

Eagle
Yes it is in closed loop.

brian
I be that's it I know the system is trying to pull out fuel. I am running 108 and the INT is hovering around the same 108 to 117 at the most. I know if I rest it with Scan9495 back to 128 it will stay that way for about 5 seconds then pull back to the 108. when it's at the 128 it's very happy. you can hear it dropping then compensate as it's pulling back down to 108. I'll do some more research in TP and see if there a corresponding flag or indicator in there.

I am now thinking I may go pick up an 02 sensor and drop it one side and see how it reacts. Because they are all getting pulled to 108 even during normal runs. I ran this thing for a quite a while with the speed sensor side disabled unawares to the effect it has on the fueling map. Trying to deduce without spending money until payday and the tinker gremlin in me. Can't leave well enough alone especially if I know somethings amiss.