Case 821F Lost Engine Messages but Kept Its Power and Grounds: The ECU Was Dropping Off CAN

Engine Messages Vanish? Hold Power And Can Together

A 2015 Case 821F wheel loader intermittently lost engine communication and entered torque limit. The first network picture looked distorted enough to suggest a damaged bus—until the technician noticed a 20 kHz filter left on the scope. Correcting the setup prevented the diagnostic equipment from becoming the first false fault in the case.

For an accessible screening layer, a meter/scope can inspect identified CAN lines and hold selected ECU powers and grounds during the event. The AUTOOL DM303 can support that limited work after the Case diagram and safe probing points are known. DM303 can help screen identified power, ground and CAN line conditions, but its handheld one-channel scope and line-data mode do not reproduce the multi-channel long-duration J1939 capture used to prove this fault or perform Case programming.

With the capture configured correctly and left running, the engine ECU’s meaningful messages disappeared after roughly packet 485 while traffic from other modules continued. Its monitored supplies stayed near 27.9 volts and ground drop about 33.5 millivolts. A programmed replacement ECM ended the fault for at least six months. The proof came from holding communication and power in the same time window.

Write down what the operator sees before it disappears

Ask the operator to describe the job, temperature, engine hours and exact display message when torque limit appears. Save every code with status and timestamp; communication codes stored by several modules can reveal which node they all missed. Do not clear the machine simply to see whether the warning returns. Inspect batteries, disconnects, main grounds and harness rub points before setting up a monitored work test. Establish a safe observer position and stop the loader if steering, braking or controlled movement is compromised.

Check the scope setup before chasing distortion

A scope setting can create a convincing fiction. Bandwidth limits, filtering, probe attenuation, sample rate and grounding all affect what CAN looks like. In this case, the apparent distortion came from a forgotten 20 kHz filter. Correct it, capture a known-good portion again and document the settings. Also inspect termination only with the network asleep and the prescribed isolation. The self-correction is useful evidence: once the instrument error disappeared, the real intermittent problem could be pursued without replacing a harness for an artifact.

Map which controllers share the suspect bus

Map the J1939 branches and source addresses from Case information. Identify the engine ECU, instrument cluster and other controllers that remain visible during the complaint. Capture enough normal traffic to learn which identifiers repeat and how often. A network-wide physical collapse generally affects many nodes; one ECU going silent can leave the remaining bus electrically active. A timeout code alone does not prove the twisted-pair wiring has failed, so it should open a network map rather than order a harness.

Wait for the fault with pre-event data running

Run a long capture through the actual work cycle and keep pre-trigger data. The fault appeared after a substantial amount of normal traffic, and analysis showed the engine ECU’s message contribution fading after about packet 485. Other controllers continued. Count or filter messages by source before and after the event instead of judging a dense trace by appearance. The key finding was absence with context: a previously talkative node stopped, but the shared conversation did not end.

Count the ECU’s messages before and after the event

Power and ground must be measured at the ECU under load, not inferred from a fuse. Monitor every critical feed, ignition input and ground that service data identifies, ideally synchronized with CAN. The documented supplies held at roughly 27.9 volts while ground drop remained around 33.5 millivolts. Those readings argue against a simple power interruption at the monitored points. They do not prove every terminal or internal connection is perfect, so inspect pin fit and reproduce movement or heat before condemning a module.

Synchronized evidence	During normal operation	During the fault
Other J1939 traffic	Present	Continues
Engine ECU messages	Present	Largely disappear
ECM power feeds	About 27.9V	Remain present
ECM ground drop	About 33.5mV	Remains low

Hold power and ground in the same time window

Now the two layers agree: the ECU stopped communicating while its required external support remained available. Confirm part number, software, configuration and immobilizer or machine-security requirements before replacement. Programming on construction equipment can require stable power and OEM access; an interrupted process may immobilize the machine. Preserve the original capture and module report. A replacement that wakes on the bus is not yet the closing proof, especially for a fault that once took hours to appear.

Program the replacement only after both layers agree

Repeat the same duty cycle, temperature and vibration exposure that produced torque limit. Monitor engine messages, supplies and ground through the test, then rescan all controllers. Check commanded torque and engine behavior rather than watching only the warning lamp. The loader initially passed after the programmed ECM was installed, but the stronger closure was time: six months of service without recurrence. Record both the immediate test and the later fleet report.

Use months of real work to close an intermittent case

Intermittent cases benefit from a reusable capture plan. Save channel labels, ranges, network filters, expected message rates and safe lead routing so a recurrence can be compared rather than rediscovered. If the fault returns, verify whether the same node vanishes with the same stable feeds. This single Case 821F outcome does not establish an ECM failure rate. It demonstrates how synchronized evidence can distinguish a controller dropout from a dead bus and from a bad measurement setup.

The decisive moment was not the timeout code. It was seeing one controller leave the conversation while its power stayed home—and then giving an intermittent repair enough real working time to prove itself.