^^^^^^^^^^^^^^^^^^^^^^^^^^^[Warning: Broken Record Alert]
Connect a friggin' scan tool, find out what the computer wants you to know. If your fuel pressure is low, or you have the wrong injectors, the fuel trims should be screwed-up. If the knock sensor is unhappy, the knock counts will be high. If the TPS, or the CTS or whatever is messed-up, it'll show on the data stream. This engine have an AIR pump? If it doesn't divert to the air cleaner as the engine warms-up, it'll freak-out the O2 sensor.
Make sure the EGR is plumbed and wired correctly. Did you source the correct PCV valve? But if there's a strong vacuum leak, the IAC counts will be off, and maybe the fuel trims too.
This engine is crying out for a scan tool.
{Warning: TLDR Alert}
Greetings @DeCaff2007,
I've taken an interest in your project for a couple of reasons. First, anyone who refuses
to give up on a project until it is successfully completed is a kindred spirit, and deserves
whatever help I can provide.
Second, your 4.3 > 5.7 upgrade project is complex enough that it would be a perfect case
study for the benefits of a structured Analytic Troubleshooting approach. I was fortunate
enough to spend my entire career troubleshooting, 2/3 hands on, and the remaining 1/3
training others. (lecture/lab civilian, OJT on a military flightline)
If possible, I'd like to help demonstrate to enthusiasts that are new to the hobby of driving
old that a disciplined, analytic troubleshooting approach is a valuable tool that folks should
consider adding to their skill set. (IMHO, this approach will help you nearly everywhere in life...)
****
Troubleshooting stuff you are intimately familiar with requires just getting sync'd up
with the problem du jour in front of you, and pretty much letting your muscle memory
take over. No jawboning, just get elbows deep and make it happen.
This is the show that The Elders put on while they worked, and it was obvious while you watched them
in action. It was as entertaining to see them ply their craft as watching any magician on stage in Vegas.
But for me, troubleshooting in a less familiar arena requires a more formal, more disciplined approach in
order to be successful.** This is because when you are intimately familiar with a machine, you pick up
on subtle cues that others miss, and further know which small handful of cues are truly important,
and also that the majority of operating sounds are literally background noise of no troubleshooting
consequence.
Instead, on 'new to me' machinery I feel like I've lost my hearing, and yet I find myself sitting in the
good seat in front of a highly resolving SOTA audio system...and others want me to pick out
subtle sonic differences between 2 different vacuum tube preamps. :0)
So this is when those around me see me shift gears mentally, and observe me trying to quantify the
quality of the data that we are collecting, or advocating for careful failure data collection, and then
following that data wherever it leads us.
****
Q: So where am I going with all this?
A: Schurkey is well known for advocating that when a new GMT400 owner pops in here and asks for help
(diagnosing a complex powerplant under the computer-controlled Closed Loop) ...after already replacing
a laundry list of parts & no joy...his trademark response is to ask the OP to get a scan tool involved.
Not a code reader, but a live data capable tool that allows us to look inside the Closed Loop data streams
while it is operating. It takes the troubleshooting from a WAG/SWAG level to employing a more formal
Scientific Method.
One complication that you see in this hobby is that a lot of times someone who is a guru on all things
mechanical is not as well versed in analog electricity/electronics. Meanwhile, an older analog guru freezes
up when confronted with control data that's laid out in hexadecimal. And finally, the next generation
computer geeks who love nothing better than to roll around in databases simply haven't had the
opportunity to get much real world 'hands-on' experience with mechanical stuff.
In pre-emissions purely mechanical computer days (think muscle car camshaft + carburetor + distributor)
the better mechanics had no problem making an engine bend to their troubleshooting will. But even
then, while many of the same mechanics wouldn't hesitate to help fix a knocking engine, by the same
token they wouldn't be nearly as keen to jump into a tough electrical issue. (Like the '68 Fury III that will start
if you drive it every day...but if you let it set over a long weekend, there's no joy? WTF? :0)
...but I digress. To be perfectly candid, it goes without saying that as a grandfather I am all for cleaning up the
HC & NOx emissions as much as possible. But the way that these mandated emission-reduction goals were
implemented in the typical GMT400 engine bay, the successful mechanic has to bring a winning combo of mechanical,
analog, and computer chops to the table. And it was tough enough when these trucks were brand new...but
those that are reading this like a challenge, so here in the GMT400 forum we've added the following to the mix:
* The engine bays in the oldest '88 vehicles are now *36* years old.
* Due to the engine upgrade, this individual combo of engine bay/computer/350 doesn't provide the
troubleshooting jumping off point of a previous moment in time where this all once interoperated 100%?
To me, this moves the troubleshooting effort from a pure 'repair back to original state' to a 'sort out a brand
new creation'? (This means that we must consciously keep all possible combinations of unknowns affecting
other unknowns on the table until otherwise proven good.)
* And instead of working shoulder to shoulder, we insist on collaborating remotely on this problem child while
literally spread out around the world? Talk about yet another layer of communication complexity?
Given the above, in order to be successful, the GMT400-linked mechanic actually needs these *6* skillsets:
* Mechanical
* Analog electric / electronic measurement skills, and able to compare what they measure to what is documented.
* Some Digital chops
* Above average reading for comprehension / writing skills (to enable/support the remote troubleshooting team)
* Ability to compose/take/upload well-lit, sharp photos with enough depth-of-field to show all relevant detail.
* A side order of ambassador skills when the inevitable 'flare ups in the talent pool due to frustration' occur. :0)
And here's a short, incomplete list of items that slow down/block progress:
* Frustration leading to negative emotional reaction. To anything. (Tough to do when you are a human.)
* Not cross-checking/validating failure info to the maximum extent possible before following it
down the garden path.) Examples include running the wrong firmware revision in the scan tool
you are relying upon > wrong cylinders identified for misfires, aged electric oil pressure gauges
lying about hot idle oil pressure, off-brand sensor(s) sending erroneous signals to computer,
wrong computer sourced from Treasure Yard that almost, but doesn't quite match the engine
in the engine bay, etc.
There are a *lot* of individual links in the success chain in this troubleshooting scenario, so you almost
need to invoke a 'chain of custody' mindset when reviewing/analyzing the failure data set. (Chain of Custody)
* Folks more interested in maintaining some perceived pecking order vs actually fixing stuff.
(Thankfully absent here in the GMT400 forum. Other forums? Not so much. :0)
****
So what does all this mean to you?
Schurkey is giving you not just sound, but profound advice.
We've already discussed that you & I are both forced to work under the super frugal rulebook, but
frankly we've just about exhausted what we can sort out using old school pre-emissions troubleshooting
tools & skills.
So however you can achieve the best bang for the buck when it comes to acquiring a live data scan tool,
then this is the next thing that needs to happen. Just like when you are working with piston wrist pins,
if you don't have the right tools on hand, you simply won't end up with a successful outcome.
Tools are how mechanics cheat to win, and can repair vehicles that normal folks can not. If it helps to
take some of the sting out of the scan tool acquisition, buy the tool in such a way that after you have
used it, down the road when the time is right you can turn around and sell it. Do this correctly, and
the all-important 'Price Per Use' metric will end up being a very affordable, easy justifiable number. (!)
For what it's worth. Looking forward to when you (& the combined efforts of all the talent in the GMT400
forum) get this project propelled over the Finish Line.
As The Elders used to tell me, "Nothing Good is Easy."
****
(Troubleshooting Appendix)
**Short story version. I went from entry level parts cannoneer (battle cry: "Fix machine, Get banana!")
to the support ranks after being formally exposed to the Kepner-Tregoe Analytical Troubleshooting training.
(Here and Here) Disclaimer: I don't own stock in K-T, never worked for them, etc. But back in late '87
I was introduced to their method, and it literally changed my professional trajectory for the better.
Truly good stuff, and well worth your consideration.
Last edited: