Fault codes, freeze frames and clearing

A fault code on a heavy truck is four things: the module that raised it, the SPN (what), the FMI (how), and the state it is in. Rignos keeps all four visible, because dropping any one of them is how a confident wrong answer gets written on a customer’s report.

Which module raised it

Every module on the bus has a source address: engine 0x00, transmission 0x03, brakes 0x0B, body controller 0x21, cab controller 0x31, aftertreatment 0x3D, and so on. Rignos polls each module it has seen by address, every 60 seconds, for stored (DM2), permanent (DM28) and freeze-frame (DM4) data — PACCAR modules, for one, ignore those requests when they are broadcast.

The Modules tab is the inventory: name from the module’s own Component ID, maker from its NAME, and a card per module showing only the parameters that module actually broadcasts. A module whose card says ? for a value is one we have not verified against a dealer tool yet — the app says so instead of guessing.

Which table decodes it

The code is looked up in the table of the module maker, not the engine maker:

• Cummins — fault codes as INSITE names them.
• PACCAR — P-codes, with Davie descriptions where we have them; the same SPN/FMI can map to several P-codes, and the app lists all of them with a (?) rather than picking one.
• Detroit — SPN/FMI with the Detroit description (Detroit has no separate code number since DDEC VI).
• Bendix — blink codes, e.g. 5-2.
• Meritor WABCO — blink codes for E-version ABS.
• Eaton — FC numbers, e.g. FC 36.

Not yet covered: Allison, International/Navistar, Freightliner body modules and the Bendix Wingman family. Their codes still show, as SPN/FMI with the generic SPN name where a generic name exists. Manufacturer-range SPNs (520192 and up) are never given a generic name, because the same number means different things to different makers.

Active, stored, permanent

Active (DM1)

The fault is present now. It cannot be cleared while its cause is still there — a clear command followed by the same code coming straight back is normal, not a failure.

Stored (DM2)

Happened before, not present now. This is what a clear command actually removes.

Permanent (DM28)

Emissions-related codes the ECM keeps until it has verified the repair itself over drive cycles. No tool clears these, JPRO and DDDL included; the app lists them under their own heading so nobody promises a customer otherwise.

Freeze frame (DM4)

For a stored code the ECM may keep a snapshot of the moment it set: engine speed, load, coolant temperature and more. The Faults tab shows a ❄ on codes that carry one, and the snapshot opens under the code. Modules that do not answer DM4 (older PACCAR MX engines, for example) show a dashed placeholder rather than an empty table.

Clearing, and what the app can prove

1. Engine off, key on. Most ECMs refuse a clear with the engine running; Cummins answers access denied.
2. The app sends DM11 (clear active) and DM3 (clear stored) to each module by address, then broadcasts once more for anything it missed.
3. It waits for each module’s ACK or NACK, then re-reads stored and permanent codes at 3 and 8 seconds and writes a verdict per module: cleared, refused, still present (cause remains), or no answer.

A guided test script can end with an engine-off clear as its final step; that step is skipped with a reason rather than marked passed when the engine is still turning or no module answers.

The event log

Alongside the codes, each session records when things happened: a code appearing or going away, a lamp changing, a regen starting, derate and engine-protection flags, engine start and stop, and every clear command with its outcome — per module, timestamped. Questions like “did it derate before or after the regen?” are answered from that log instead of from raw frames.