Every few days the SLC drops to fault. Major error 0020. Operators shrug, maintenance clears it, production resumes—until the same math mistake hits again on night shift. That pattern is the overflow trap bit S:5/0 doing exactly what Rockwell designed it to do: latch so you cannot pretend the bad arithmetic never happened.

On a 5/04 such as a 1747-L524, 0020 means an instruction produced a result outside the legal integer window. Signed 16-bit work lives between −32768 and +32767. Blow that ceiling with ADD or MUL, divide by zero, walk a FIFO/LIFO past its buffer, or NEG −32768, and the processor sets S:5/0, then sits faulted until something unlatches that bit. Publication 1747-UM011 / 1747-UM001 family manuals describe the trap; the plant floor just sees a dead CPU.

Legacy SLC processors still carry a lot of discrete machines. Overflow traps are almost always application math—not a dying backplane.

The OTU that stops the bleeding

Most quick recoveries put an OTU on S:5/0 so the scan can continue after the trap. The placement is the whole fight. Put it as the last rung in LAD 2—the file that owns your JSR calls—so every subroutine has already finished before you clear the latch. That way the overflow is detected during the scan, then cleared once, before idle.

LAD 2 — last rung
  S:5/0
----] [----(OTU)----

Drop the same OTU inside the subroutine that overflows and you invent a new failure mode: clear too early, overflow again later in the same scan, immediate refault. Or the OTU fires on a path that never sees the bad math that scan, so you think you “fixed” it while the real rung still detonates twice a week.

Download, key to RUN, watch S:5/0 stay clear across a few shifts. If it stays quiet, you bought time—not a root-cause close-out.

Find the math that actually overflowed

Treat the OTU as a seatbelt. Then go hunting:

• Any recent change that touches integers—batch counts, scaled analogs shoved into N-files, “temporary” MUL for unit conversion
• ADD / SUB / MUL / DIV / DDV without range clamps
• Places that should have been LADD / LMUL (32-bit) once values left the 16-bit comfort zone
• NEG on a value that can sit at −32768
• FIFO/LIFO length versus the buffer you actually reserved

Related status bits worth knowing while you debug: S:5/1 overflow trap enable, S:1/0 first scan, S:2/0 processor fault. Do not clear traps blindly in online edits without knowing which rung is smoking.

Hardware reality check

1747-L524-class 5/04 CPUs are deep into obsolescence. If the chassis is staying, keep a known-good 5/04 spare on the shelf—plants that still buy in this family often land on modules like the 1747-L542. Smaller machines sometimes migrate sideways to a 5/03 such as the 1747-L532, but that is a project decision, not an overflow fix. Longer term, most sites move the process onto CompactLogix or ControlLogix and retire the 16-bit math traps with the platform. Spares strategy for mixed Logix fleets still belongs with how you stock PLC and PAC systems.

Until that migration ships, the discipline is simple: LAD 2 OTU last, then prove which ADD/MUL is lying about its range.