Check a fixture's RDM behavior

A report believes what the fixture says. The behavior check asks whether what it says can be believed: it sends the fixture a set of requests that E1.20, the RDM standard, says exactly how to answer, and lists which rules the unit keeps and which it breaks.

It answers a different question from the report, which is why it has a window of its own. A unit can break a rule here and still work perfectly in a show. Nothing the check finds changes the fixture’s rating or the dots in the sidebar.

When to run it

• The line misbehaves and the report looks fine. Discovery is slow, comes back short, or finds a different number of units each time. Fixtures change address or start identifying on their own. A unit seems to stop answering when it plainly has power.
• After repairing a control board, to show the unit answers RDM properly again.
• Qualifying stock: a rental house that wants each model’s conformance on paper, one page per unit.
• Before blaming the bench. When the bench reads something odd from one fixture, a broken rule here says the fixture is the one at fault.

Running it

Select the fixture and choose Fixture → Check Behavior… (⇧⌘B) (macOS). The fixture has to be on the line: the check asks it questions rather than reading a saved report. It usually takes a few seconds.

The check changes nothing for good. The identify rule flashes the fixture and then sets identify back to how it found it. Two rules release the unit from discovery’s mute and mute it again, which is how discovery left it. If the fixture refuses to be put back, that rule’s sentence says so, and what the unit was left doing.

Reading the page

The top right says follows the rules, or how many are broken. Under it, conformance, not health, the reminder that a fixture that keeps every rule can still be faulty. A sentence then sums up the result, followed by each rule, one per line, with the section of E1.20 it comes from:

• A green check: the unit kept the rule. A pass needs no explanation, so it has none.
• A red cross: the unit broke it. The sentence under it describes what you would see at the bench because of it, not the clause.
• A gray dash: the rule could not be tested on this unit, and the sentence says why. Do not read it as a pass. Often it points to another rule on the page that explains it. The deferral rule (below) shows a dash on most healthy fixtures, because they answer straight away and never defer, so there is nothing to test.

Every rule is listed, passes included, so the page stands as a record of what was tested.

The rules

• Ignores a request whose checksum does not add up. A unit that breaks it acts on whatever a bad cable puts on the line: an address that changes by itself, an identify that will not clear.
• Answers with the transaction number it was asked with. Broken, every answer looks like a reply to some other request, so a careful controller reports the unit as silent while it is plainly talking.
• Refuses a request whose parameter data does not fit the parameter. Broken, the unit is not reading the length of what it is sent, and a newer controller’s longer request can be taken as something else.
• Refuses a GET addressed to every sub-device at once. Broken, on a dimmer rack or other unit with modules, the modules all answer at once over each other.
• Produces the answer a deferral promised. A unit may ask for more time to answer. Broken, it asks and never answers, which looks like a slow fixture rather than a faulty one.
• Stays quiet for a discovery branch that does not cover it and Stops answering discovery once it has been muted. Broken, either one stops discovery from getting past this unit: the line discovers slowly, and the units behind it are missing.
• Writes only printable ASCII in its text fields. Broken, names and labels show odd characters. The page names each field and shows the bytes the unit sent.
• Reports the identify state it was given. Broken, a controller cannot tell whether the unit is identifying, and a walk down the truss skips it.

The identify rule can only check what the fixture says. A unit that reports identify perfectly can still light when it should be dark, and nothing on the wire shows that: you have to watch the fixture. Where someone has, it is recorded on the model’s profile, and the report reads identify the right way round (see Device state).

Keeping the result

The check is filed under the unit in the bench’s captures folder, together with every packet it sent and what came back. Those packets are the evidence to attach when you write to the maker about a broken rule. Show Wire Log opens them, and Reveal in Finder shows both files. Copy puts the page on the clipboard as plain text, one rule per line, marked PASS, FAIL or --.

From the command line

rdmbench-cli behavior checks the first fixture found, or the one whose UID you give it, prints the same page and saves the same two files. --json prints the result as JSON instead.