Help

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). To find which unit on a line drops out, watch them all at once (see Watch the whole 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). 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 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 has the exchange behind each one.