DAF CF Cut Out Hot and Would Not Restart: The Engine ECU Went Silent on J1939

Cuts Out Hot? Capture The Ecu Before And After

A DAF CF ran normally from cold, cut out as it warmed and would not restart until it cooled. Temperature was clearly a trigger, but “heat-related ECU” was still only a theory. The decisive evidence arrived during the stall: after two brief periods of network silence, other J1939 traffic returned and the engine controller did not.

A meter/scope can support identified CAN-line, power and ground screening before the long network capture. The AUTOOL DM303 is one accessible option for that limited layer after DAF data defines safe points. DM303 can support identified CAN line, supply, ground and slow waveform checks within its ratings. It is not a dedicated J1939 decoder/logger, cannot identify every source address automatically and cannot code a replacement DAF engine ECU.

The sleeping network measured the expected 60-ohm termination, and the bus carried normal traffic while cold. Keeping the recording alive through the hot cutout showed the engine ECU disappear from the conversation. Bench testing confirmed the module fault; replacement and programming returned the truck to the road. The case was solved by preserving the seconds after the engine stopped, not by collecting more static codes.

The cool-down restart is a clue, not a verdict

Start with the driver’s clock. Record minutes from cold start to cutout, coolant and ambient temperature, load, road speed and how long the truck must cool before restarting. Save the 12 active faults and note that 11 were communication-related in the documented case. Several modules reporting missing engine data can create a crowded code list from one absent source. Arrange a safe stationary or road test with recovery support; an engine that can stop in traffic should not be reproduced casually.

Save all communication codes before clearing

With the vehicle powered down and the network truly asleep, the diagnostic connector showed about 60 ohms across the bus, consistent with two 120-ohm terminators in parallel. That is a useful baseline, not a complete network health certificate. An intermittent module can pass resistance cold, and unplugging controllers changes termination. Inspect connectors, batteries and chassis/engine grounds, then restore the network before active voltage tests. Never measure resistance on a powered bus.

Check network resistance only when it is safely asleep

Capture CAN high and CAN low with suitable differential technique while the engine warms. Record normal message identifiers or source addresses long enough to establish which belong to the engine ECU. A handheld physical-layer view can show gross distortion, but proving one node disappears usually requires a longer recording and message analysis. Keep the instrument powered and enough memory available to retain data from before the stall through the failed restart attempt.

Keep the capture running through the hot cutout

At the cutout, the bus went silent in two buffers of roughly 40 milliseconds. Traffic from other controllers then resumed, but normal engine ECU messages were absent. Brief total silence might follow key state, power disturbance or network arbitration; it is the recovery pattern that matters. Compare the message list before and after, not just voltage shape. If the rest of the network returns while the engine source remains missing, investigate that controller and its support circuits.

Separate brief bus silence from one missing controller

Monitor ECU battery feeds, ignition feeds and ground drop through the same heat event wherever service information permits. Check terminal tension and loom movement; an external connection can open with temperature and imitate an internal module failure. If a supply drops when messages disappear, repair that path before sending the ECU away. The network result localizes the missing node, but stable external support is what turns that localization into a defensible module test.

Evidence	Cold/running	Hot/stalled
Bus termination asleep	About 60 ohms	Baseline only
Network traffic	Engine and other nodes present	Other nodes recover
Engine ECU messages	Repeating normally	Remain absent
Restart ability	Starts and runs	Returns only after cool-down

Identify the engine messages in J1939 data

The engine ECU was removed for specialist bench evaluation, which confirmed it faulty. A bench result should be paired with the vehicle evidence, not used to replace it; artificial heating alone may not reproduce load or connector conditions. Match hardware and software identifiers and prepare for coding, immobilizer/security and parameter transfer. Use a stable programming supply and DAF procedure. Do not fit an unverified used unit simply because it communicates on the bench.

Bench-confirm and program the replacement ECU

To verify the repair, warm the truck through the same time, temperature and load window, then continue beyond the original cutout point. Record that engine messages persist, the engine keeps running and the ECU responds during restart checks. Rescan all modules and separate historic communication faults from anything that returns. Inspect charging voltage and cooling behavior so another heat-related condition is not hidden by a successful module replacement. The documented truck returned to road service after programming.

Repeat the warm route before returning the truck

Give the driver the original cutout time and the new test duration in the handover. If the symptom reappears, that comparison will guide the next capture. This DAF case does not establish that every hot no-restart needs an ECU; crank signals, power relays, fuel pressure and wiring can follow the same temperature pattern. The transferable technique is to keep the network record running through the failure and ask which voices come back.

Cooling time made the failure repeatable, but the network made it specific. The engine ECU was not convicted for being hot; it was tested because it alone stayed silent after the rest of the bus resumed speaking.