lakeffect2

Two weeks ago before the Os sensor failed, I was able to hook up the new Lenova laptop to the ECM. I was able to find two comm ports in the EBL WUD that were open. 1 & 7. The ECM was on cmm port 7 (via the USB cable)

I put the new Sensor this morning. It works. I went to hook up the WUD, to flash in a bin to cut open loop fuel, and there isn't a single 'Open" comm port that shows up in the menu. Both 1 &7 (ok last week) were now listed as closed. There was no obvious communication to the ECM from the laptop. No response that the ECM was being recognized, all attempts at flashing failed.

I checked the new pinned connections to the ECM, they seem fine .Key was on, not running, 1/8 jack and USB were connected.
Any ideas as to why not a single comm port is showing up as open?

Dave

RBob

iTrader: (1)

You don't need to be in the car to troubleshoot this. Just boot up the laptop and plug the USB comm cable into a port on the laptop. That is enough to have a serial port assigned to the cable.

If auto update is set on your laptop you may need to reload drivers or some such thing. Here is a link that shows how to check which port is assigned to the comm cable:

http://www.dynamicefi.com/USB2SerialSetup.php

RBob.

lakeffect2

Thanks, I followed your instructions and discovered the need to reload the drivers. I did so off of the EBL owners CD, Afterward the EBL was found on com port 3. I was wondering if that was odd, because it originally showed up on com 7.

Next step, was to replace the battery charger that died as well. ( can't catch a break here). The car has an Accel double strike ignition system and does not like to fire up when under or near 11.0 volts.
it's on the charger now.

So it's

RBob

iTrader: (1)

Being reassigned to COM3 on a new driver load is normal. The driver seeks the lowest unused COM port to use for that particular cable. The O/S remembers this as the cable has a USB serial number.

If you use a different cable it would be assigned the next unused COM port.

RBob.

lakeffect2

IT'S ALIVE!

lakeffect2

The VE LEARN function has already proved invaluable.

I saw where there is a condition of minimum temp before it learns.
Oddly it seems not to learn when I'm dropping off to what should be idle. So I'm wondering if there are other conditions that I'm not meeting for a "learn" to continue in those areas of concern.
The ECM has been holding high RPM's and Very Rich AFR's when it should be dropping off to idle.

I've seen some tables related to idle and IAC conditions which show promise. but I would have expected entries to show up in the VE learn charts that would correlate to these ultra-rich areas, 11.5-12.5 at 1000 rpm while sitting at a light, or when backed off. easy low speed neighbor hood streets.

The cursor recognizes the area, but no distinctions (differences) are left behind to evaluate. I must be missing something.

Once again,,my sincere thanks to all those taking time to respond.

RBob

iTrader: (1)

The open loop decel option flag is usually set in the base calibrations. Un-check that box to get closed loop and BLM based learning in those areas.

If you use WB VE Learns then need to force open loop.

There are VE Learn preferences in the Preferences dialog. Including a min & max CTS for allowing VE Learns. They do need to be done in the normal operating range of the engine.

RBob.

lakeffect2

Found it under "Option Word 1 OpDcl"


... or maybe it was "OCD Optional ", so I hit it 137 times to be sure.


Once again RBob to the rescue!
Thanks,

Dave

lakeffect2

After having watched the VE learns over the past week I can better understand the "open loop decel option flag" With it unchecked, it seems like the VE Learn function wants to counter the Decel areas to make them richer. ( may or may not be true)

I had been wondering why in a decel situation, my AFR was going to high 12's -13 until I remembered that I had turned off that check box. I'll go back , turn it back on and edit those VE areas by hand in TunerPRO.



.. and an additional word of thanks to all those who've helped by answering my questions over the past several years, particularly RBob, JP, Ronny and several others. God Bless Grumpy

Dave Buchholz,
Rochester Ny

Ronny

iTrader: (1)

Just a guess but when you deacell you induce a high vac that pulls the gas off the runners in the manifold creating a rich condition. Maybe the OL-D is there to disallow Learn so as not to create unwanted INT/BLM changes? DE enleanment would help to counteract the enrichen. I get BLM reads above 12 MPH as that is the threshold I placed. OL < 12 mph.

Does your OL vs VAC table have values of 14.3-14.7 in those areas? If so maybe the VE table is too fat there. I needed to pull a lot of VE value in those cells that I am OL driving. Especially the 20MAP column to get the A/F close to 14.0/1 in deaccelleration.

lakeffect2

Thanks for the response Ronny.

My observations came more from looking at the graphs of the Lower VE table, and doing comparisons of the several most recent post VE learn changes. I could see the lower KPA areas (20-45) progressively build up after each learn session. As I progressed through the successive comparisons, it was building into a mountain on the graphs., It seemed to me (my best guess) that the VE learn was fighting Decel Enleanment, and was never content, so it kept adding fuel with each VE Learn session. I noticed My AFR's during coast down kept getting richer, 13's , then 12's then 11's after each VE learn was applied. The EBL's Bin select function proved valuable. I could also cycle through successive bins, and confirm the AFR grew richer with each bin.

Soooo... I turned the "option word 1 OpDcl" back on, and returned that area of the tbale back to it's original state by copy and paste from one of the Prior tables. Now when I coast down the AFR bumps to 15-16 , where I want it to be during enleanment episodes. The upper Table also required some modding, but not as much. Will likely need to go clean the plugs again to counter that too rich period in their recent life.

An earlier post in this thread from me was" Oddly it seems not to learn when I'm dropping off to what should be idle"

NOW I understand why it was that way to begin with, and has been returned to the way it was intended..

Ronny asked "Does your OL vs VAC table have values of 14.3-14.7 in those areas? " I looked at that as well per your suggestion, and yes those areas seemed to be commanded a bit rich as well, ad have been modified accordingly. Thanks for the idea.

Starting/idle was an issue as well, but seems to be improving with changes to the Crank,Choke and Open Loop tables. Also found an IAC idle RPM table that seemed to contradict other idle tables. It was trying to keep the idle too low in opposition to my desired RPM that is found in another temp based idle table. The beast likes 900rp, but. 700-800 was where the IAC table tried to direct it until it was modified.