Never take anyone else’s word for it – including the computer’s!
One of our member’s sent me this troubleshooting story:
“The company I worked for had invested in a complete overhaul of the engine on an older Mack truck, sleeper version in otherwise poor cosmetic shape. In addition, they were the proud owner of a mechanically poor, cosmetically good Mack in a non-sleeper configuration. The decision was made to do a cab swap, and so it went in a relatively straightforward manner. Several weeks after the now good looking, good running day-cab truck was commissioned, it began to shut down unexpectedly. But would restart immediately, until the day it didn’t restart at all.
A check of the “blink code” diagnostic facility revealed a defect in one of the two data bus systems. Connections were checked, and all connectors and fuses and relays tested correctly. A local dealer was called, and a laptop computer was used to read the fault codes. This confirmed the error code indication of a data bus fault.
I personally performed data bus resistance and continuity testing, and reported my findings of good continuity, as expected resistance, and no shorts. My concern was that the harness was good, and the issue was likely an engine or body computer problem. As per shop manual instructions, known good engine and body computers were substituted with the existing units with no success. The same data bus error remained.
By decree, the engine harness forward of the firewall was not the issue because this had been recently replaced with factory new because it was thought to be the cause of a previous no start. (In this case it was a bad fuel pump drive gear and in no way electrical: a $10,000 misdiagnosis.)
So I was ordered to change the cab side of the harness, a three day job, and after which the error code remained. The engine and body computers were tried in a different truck to rule out damage during the previous a/b swaps, and were found to be good. The truck still didn’t run. So it was taken to another outside mechanic who diagnosed a bad flywheel sensor. Upon replacement of this sensor the truck ran like a champ.
It turns out the sensor on the flywheel was electrically sound, but the plastic mounting tab was cracked, preventing the Hall effect sensor from sending timing pulses. At the same time, the sensor was neither open nor shorted. So the ECU interpreted this as a data bus issue.
Expensive fix: code reader $650, fuel pressure tester $200, firewall forward harness $10,000, labor to replace firewall back harness with used and untested harness, 3 days labor, truck off the road for 3-1/2 months.
The actual fix: a new flywheel sensor: $125.”
This troubleshooting tale contains multiple breaches of the 12 troubleshooting principles (TP’s) explained in The Hydraulic Troubleshooting Handbook. But I only have space here to call out two of them.
In my discussion of TP#3; Check the easy things first in the above publication, I explain that common faults with unusual symptoms occur more often than unusual faults with common symptoms. And I tell a story about a fault on a Hitachi EX3600 excavator which shares many similarities to the one above. In the Mack truck story, a sensor problem (common fault) resulted in an unusual symptom–in this case, an erroneous and misleading error code. Importantly, this scenario is a more likely occurrence than a bus problem (unusual fault) with common symptom–an accurate fault code indicating a bus fault.
This means in the order demanded by TP#3; Check the easy things first, all sensors should have been physically inspected and their connections checked long before harnesses and computers were changed out.
Inextricably linked to the above protocol is TP#5: Never take anyone else’s word for it. And this includes the computer. Just because the ECU software indicates a certain fault, it doesn’t necessarily mean this information is correct. As with all information provided by third parties when troubleshooting, consider it, but don’t automatically accept it as fact. As in this case, doing so can hoodwink you into skipping important and necessary prior steps. And this can be very costly, as it was in this case.