I must be in Waaay over my head

[MadMikeZ28]

There is nothing wrong with the fan wiring. I have been driving the car on different tunes for 3-4 years now.

I also have several modified Memcals so I could drive on one and burn to another. They contain SST 27SF512 chips.

I did semi figure out a couple things,

I copied the timing tables from an ARAP bin I downloaded from here. I pasted it to my stock AYPN. When I pasted it, some values turned red and were lower than what was copied.
I assume there is something else in the tune that would need to be changed to allow for the higher values?
I thought Scaler because I saw things like max advance. But that in both tunes were set the same.

I also noticed that when I went into the ARAR timing tables that the numbers were waaay different (much lower across the board) than the ARAP, APYN and a Hypertech tune for an 89 Camaro.
So as for the no start with ARAR, I think the ARAR tune found on this site has been modified. But I dont know where else to look for why the fan switch change does not allow the fans to NOT come on with the key on engine off.

I will try your ARAR bin.

Thanks

[NomakeWan]

The 27SF512 is a 64 KB chip. The BIN for your ECM is 16KB. So you should be BIN Stacking.

I've attached a modified version of the above BIN designed for a 64KB chip to this post.

If when pasting values it seems like they don't all change correctly, that sounds like the tables don't actually align between wherever you're copying them and where you're pasting them. Personally I do not like pasting tables in TunerPro for exactly this reason and would rather just type them out manually.

The 6E_expanded.xdf actually doesn't have limits set per se; the only limits it has are on the actual size of the data address. For example, if the data address is an 8-byte address, then you can only have data values of 0 to 255. What those data values translate to in "human readable" things like milliseconds or degrees or whatever depends on an equation included in the XDF (right-click on a parameter, click "Edit Parameter XDF Info," then at the bottom switch to the Conversion tab to see what equation is being used to convert raw ECM data to human-readable values). You should under no circumstances modify this equation unless you know for a fact that it is wrong. And even then you should double-check and triple-check to be absolutely certain. My recommendation is to leave the XDF well enough alone. If you're using the same one I am, it is not the culprit.

If by "turned red" you don't mean the text (which indicates that a value has been altered) but rather the background color of the cell, that color is useless and can be ignored. It's a reference color relative to other values in the table. It is perfectly normal to have a cell be "red" if it is intentionally a larger value than most everything else in the table (this happens a lot in transmission tables, for example).

[MadMikeZ28]

timing tables.jpgThe guy that gave up on making my tunes told me nothing about stacking.

I will have to try the new bin tomorrow as I had the car running and it needs to cool so the fans are certain they wont come on with the key. The other bin you provided did have the fans come on and did not start the motor. But I was more concerned with the fan function. I don't need the ARAR bin but I just thought I would start with that as aluminum head Corvette and I installed aluminum heads

The XDF is the same as what the guy that was doing the tune was using. As you can tell I don't seem to know anything about modifying the bin, I'm certainly not going to change the XDF.

The actual numbers in the timing table that changed to a different value from what was copied and pasted were in red. Some of them were anyway. Numbers in the lower left quarter that were in the 47 and 48 range changed to the 42 range and showed in red numbers after the paste. All others changed and were colored black.
Also in one table, forget which one, I wrote down values from another bin and manually entered each one. After clicking the Commit Change in that table, the table closed. When I opened it again, all these that I entered manually were of a much lower value and of the same number. So manually or pasting, does it to me both ways.

The tuner emailed me today and told me,
"I'm telling you it's very complicated and you can't just go swapping values without understanding all the other affected settings "
And that is all he tells me.

If there were a tuner in the Sacramento area, I would just pay to get it done. Due to my health, the days of a leisurely 400 mile cruise are over.

His tunes seemed to be working fine for me. I had an AFR gauge in the car and when we seemed to be done with tuning i took the gauge out. I was doing the tuning for a cam and head swap. While tuning someone kept telling me the valves sound a little noisy. My hearing is poor so I did not notice it. Turned out the Summit Racing sold me two of their Trick Flow heads with two different spring rates. The left side, The O2 sensor side by the way, had worn rockers and push rods making them real loose. The right side with the correct spring rate was fine. I went to smog (it did pass two year and two thousand miles ago with a previous tune) and Nox was way high. Higher than a non working EGR. More of a lean condition. I put the AFR gauge back in and what used to run in the 14.7 area at idle and cruise is now in the mid 15 area.

After testing fuel injectors, AIR system, Evap, Installing bushings in the TB, smoke testing for leaks, installing a heated O2 in the right side pipe so I can data log off that side and get basically the same readings, All I can think of is the tune as it was being done on a failing valve train. Rockers loose, valves not opening fully while data logging?

And apparently I dont even know how to post a JPG of the tuner pro screen shot

[NomakeWan]

tables.jpg

Okay, so one thing at a time.

I do not see a "6E_Extended.xdf" on Scott Hansen's site, only 6E.xdf. Scott knows his stuff so if you did get your XDF from him, I have no reason to believe it is incorrect. The labels in your screenshot do not match the labels in mine, so we're definitely not using the same XDF, but again I'd trust Scott's work.

Okay, so now that I see the table I probably know where your confusion is coming from regarding inputted values. As I mentioned earlier, the actual values you see are calculated from 8-bit or 16-bit data (0-255 or 0-65535). That is the maximum numer of possible values, but what that translates to in the particular table depends on the equation GM used. Do open the "Edit Parameter XDF Info" on a table you're interested in and click Conversion. You'll see that for the Spark Advance table, the equation to convert the binary data to human-readable data is:

0.351567 * X + 0.000000

Where "X" is a binary data value. If you right-click in a table and click "Show Raw Hex" you can see what the raw hex data value of a cell is. In my screenshot, the upper-leftmost cell has a hex value of 3D. This converts to 61 in decimal. 61 * 0.351567 = 21.445587, which rounded to the second place gives you 21.45, which is exactly what's shown in my table. That's how this conversion works. Now, let's say I change that hex value from 3D to 3E, just increasing it by 1. Now it's 62 * 0.351567, which comes out to 21.797154. That means any value between 21.45 and 21.80 will be impossible to enter, because the data literally cannot represent it. It can only represent 21.45 or 21.80 but nothing in between.

Now, here comes the tricky bit. On my XDF, this particular table is set to have a maximum human-readable value of 43.00 degrees of spark advance. But you can see in my screenshot that from the factory, the table has values of up to 49.92 degrees! Now obviously it'll never hit that because the maximum spark advance is set to 39.73, but still, the fact remains that the factory data in the table goes way higher. So, what happens if I try to modify the stock table? Say, drop a value from 49.92 to 48 degrees? When I commit changes and then reopen the table, my 48 degrees will magically become 42.89 degrees! This is because the XDF has set a limit for all user-created inputs to 43, and the closest value less than or equal to 43 is 42.89.

You can raise this specific limit by clicking "Edit Parameter XDF Info" and then changing the number in "Use High Range" on the right in the General tab. This is what sets TunerPro's limit for a particular cell. It sounds like your XDF has that limit set to 46 instead of 43.

If your tuner told you nothing about stacking, I wonder if the tunes he was sending you were pre-stacked? I know I'd do the same thing if I knew my end-user was using a chip larger than the BIN. It's easy to tell the difference; a factory BIN is 16KB, while a pre-stacked BIN (like the second one I posted) would be 64KB.

As for the specific issue with smog and valvetrain, yes, if the engine was not fully mechanically sound when doing the tune that will 100% screw up the tune. Fixing vales that weren't opening all the way means you're getting a lot more air into the combustion chamber than you were before, but if your tune was expecting less volumetric efficiency (less airflow into the chamber), then it'll be delivering less fuel than the air you're actually getting in. Classic lean condition, so you're probably spot on the money.

What you can do as an easy test is to just change fuel across the board, and lower spark advance a little across the board. Leave the big tables alone. Just change the Maximum Spark Advance to something lower (factory on the Corvette is 41.84, so try that), and then change "Single Fire FI Size @ 40 psig" and "Double Fire FI Size @ 40 psig" both to a slightly smaller number. This will trick the computer into thinking you have smaller fuel injectors than you actually do, which will have the effect of increasing fuel flow uniformly across the entire fueling table.

Now, here's the bombshell. While getting you information for this post I actually found that the problem may in fact be the ARAR BIN itself. I've never used it; I just had it downloaded from this forum, same as you did. But comparing it against other $6E BINs it has a bunch of data that is just plain wrong. I don't know why it's so wrong, but it's incredibly wrong (for example, it reads as having a rev limit of only 1182 RPM, and fuel injectors that are only 6 lb/hr instead of 22!!!).

I've attached an ARAP file to this post. It's got the same modifications as before (no VATS, cooling fan set to Normally Open), and is stacked for your chip. Give it a whirl.

[MadMikeZ28]

bin stack wrong.jpg

I first downloaded (and printed out screen shots of installing all and data logging) the XDF from Scott's web site. Then the person that was doing my tune sent me the extended version. And the person doing my tune knows Scott and lives close to him.

When you mentioned "bin stacking", later on while I was doing something else I had remembered reading something about that in the TP help. So I looked into it and it looked as if I had the wrong settings shown in the image. So I changed it to bin size 16, chip 64 and block 32. I did not see a "save" button but I closed that window and reopened and the changes were the same.

My edit XDF also shows the same 0.351567 * X + 0.000000. Which I suppose makes sense as that is the XDF supplied to me by the tuner. I think he just made a small change to Scott's XDF.

In Gerneral of my XDF parameter it shows "use high range", a box checked and a range of "43.0000". So that is why any of the cells that had a value above that, like were some were "47.xx" automatically changed to "42.89".

I will try that lowering maximum Advance (that is the scaler? mine is 42 now) and the single and double fire and see what happens. As long as the changes take. But I did fix the bin stacking as far as I know.

I also saw somethings in the ARAR bin from this forum. Like the spark table was WAAAY different than any other bin I looked into. I first chose the ARAR because the name showed a gear ratio closer to my 2.77. But after seeing those tables o much different, I gave up on that ARAR.

I have to go to another computer so I can print this stuff. Good reading.

The car is warm so I can't find out if that ARAR wont turn fans on with the key right now. But I am going to try that spark advance and single/ double fire right now.

Thanks!

[NomakeWan]

No problem! I apologize that it took several posts before I actually went and had a look at the ARAR BIN more deeply; that should've been the first thing I did, but since it came from here I just trusted that it would be okay. D'oh!

The ARAP BIN checked out so it should be okay, and your car should start with it. Hopefully the fans work right too!

For BIN stacking a 16KB bin into a 64KB chip, I use Bin Size 16KB, Block Size 64KB, Chip Size 64KB. Then I just feed it the one BIN file I want to stack as Pos 0. Other way you could do it is Bin Size 16KB, Block Size 16KB, Chip Size 64KB, then place the BIN you want to stack into all four positions.

[MadMikeZ28]

I could have brought up that the ARAR bin from the forum did not look right in other areas. But I assumed it was your bin from somewhere else and my mind is taking in so much. It is like filling a shot glass with a pitcher of beer.

I did try changing the Max spark from 42 to 38 and the injector size from 22.?? to 19.?? and it still shows lean on the AFR gauge. But at least I am learning something! I just hope it sticks.

I also changed the bin stacker to 16, 64 and 64 and noticed it was already pos 0.

When looking in Parameter Category, under "Fuel" it shows Start up enrichment and multiple MAF tables.
Is that has a richer or leaner AFR is achieved? By adjusting MAF tables?