# Chase an intermittent fault

- **MCP resource:** rdmbench://help/intermittent
- **Version:** 0.2.0
- **Runs on:** macOS 15 Sequoia or later, Apple silicon or Intel
- **Needs:** An Enttec DMX USB Pro with its DMX/RDM firmware (major version 2)
- **Price:** Free

Some faults are not there when you look: a fixture that overheats after
twenty minutes, a status message that comes and goes, a connector that
drops the line when it is touched, a unit that stops answering now and
then. A single report misses them. Monitoring catches them, because it
keeps asking and writes down the time of every change (see
[Watch a fixture over time](/help/monitor/)). To find which unit
on a line drops out, watch them all at once (see
[Watch the whole line](/help/monitor-line/)).

## Wiggle the cable

Start a session and flex each DMX cable and connector in turn, the
fixture's input and output sockets included. A bad joint shows up as
**corrupt frames on DMX input** each time it is moved, or as **device
stopped responding** and back. Move each one slowly and watch the time
of each event, so you know which movement caused it.

## Faults that need heat

A fault that only shows warm needs the unit working while it is
watched. Monitor it and click **Put Under Load…**: the fixture is lit
for as long as you choose, each sensor's climb is in the readings, any
status message that appears has its time beside it, and output ends by
itself (see [Load test a fixture](/help/load/)). For a long
soak, set **Every** to a longer interval; a change of a few seconds
matters less over an hour.

To hold levels of your own choosing for as long as you like instead,
light it with [Send DMX](/help/send-dmx/) and monitor it while
it is lit: the hold stays up while the monitor reads.

## A message that comes and goes

A status message that appears and clears again on its own is an
intermittent fault, and the monitor lists both, in the fixture's own
words, with the time of each. Under **Still active**, the summary names
any message that had not cleared when you stopped.

## Answered late or asked twice

The monitor waits up to a second for each reply, much longer than
the standard allows. A slow fixture is still heard, rather than being
counted as gone:

- **Device answered late**: the reply came, past the time E1.20
  allows. The fixture is working, and the reply is counted. The first
  late reply in a session makes an event; the rest are counted in the
  summary.
- **Device ignored a request and answered it asked again**: no reply
  even after waiting, so the request was sent once more, and that one
  was answered. Counted the same way, as **asked twice**.
- **Device stopped responding**: two requests in a row went unanswered.
  The sensor table says *Fixture not responding* until it is back.

Late and dropped replies are worth noting on a unit that is otherwise
fine. They can come from the fixture or from the line, so before
blaming the fixture, check the line is terminated and the cable is
good. The [wire log](/help/wire-log/) has the exchange behind
each one.