# Read the wire log

- **MCP resource:** rdmbench://help/wire-log
- **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

Every report, monitor round and behavior check is made of packets: the
bench asks, and the fixture answers or stays silent. The wire log is
those packets. It lists each one the bench sent, what came back, and
how long the reply took, along with the bytes themselves.

Most of the time you will not need it, because the report and the
monitor already say what the packets mean. Open it when you need the
evidence behind a reading: a fixture that seems to go quiet, a value
that looks wrong, or a broken rule you are about to report to the
maker.

## Opening it

Choose **Fixture → Wire Log…** (⌥⌘L) *(macOS)*
while connected. It shows everything this connection has sent since
you connected, across every fixture on the line. Opening it sends
nothing to the line.

The log is kept in memory only. It is not saved anywhere until you
choose **Export…**, and it is gone when you choose to disconnect. On a very long
session the oldest exchanges are let go, and the sheet says how many;
export sooner if you need all of them. The log does not follow along
while it is open, so choose **Refresh** to see what the monitor has
sent since you opened it.

## When the widget was unplugged

If the widget is unplugged while connected, the log of that connection
is kept, so the packets leading up to the drop can still be read.
**Wire Log…** opens it, marked as the connection that ended and when,
and **Export…** saves it. It is kept until you next choose
**Connect…**. If the widget is plugged back in and the bench reconnects
by itself, the log of the new connection says the earlier one is still
held, and **Show It** opens it. Only the most recent dropped connection
is kept.

## Reading the table

The line above the table counts the **exchanges**, those **unanswered**,
those **late**, and **interface errors**: times the widget or its USB
connection failed, so there is no telling what the fixture did. Each
row is one exchange:

- **#**: its number in the log. The same exchange has the same number
  in the app, the CLI and an exported file, so "exchange 412" means the
  same packet to whoever you send it to.
- **Time**: how long after the log started it was sent. **Took**: how
  long the bench waited for the answer.
- **Sent**: what was asked, in E1.20's own words: the command (`GET`,
  `SET`, `DISC`) and the parameter's name, such as `DEVICE_INFO`.
  `DISC_UNIQUE_BRANCH` is discovery asking a range of UIDs who is
  there. A DMX row shows the levels that went out, and appears only
  when they changed.
- **To**: the fixture's UID, and a sub-device when it was not the
  fixture itself. For discovery, the range of UIDs asked.
- **Came back**: `ACK` and how many bytes of data, or `NACK` and the
  fixture's reason for refusing. **No reply** is silence. **Late** is a
  reply that came, but after the time E1.20 allows. Anything wrong with
  the reply follows: a bad checksum, a transaction number that does not
  match the request, or a reply about a different parameter.

Some rows that look like failures are not:

- **Broadcast**: a request sent to every fixture at once. Fixtures do
  not answer those, by design.
- **Ignored, as it should be**: the behavior check sent a request with
  a bad checksum on purpose, and the fixture rightly ignored it.
- **Silence** and **Several answered** in discovery: a range with
  nobody in it, and a range with more than one fixture in it. Both are
  how discovery works on any line with more than one unit.

None of these is counted as unanswered.

## What's worth a look

**Only what's worth a look** hides every row that went as it should.
What remains is shown in red, or orange when late: requests with no
reply, late or unreadable replies, a bad checksum or transaction number,
a reply about another parameter, interface errors, and a fixture that
answers a GET addressed to every sub-device at once, which E1.20 does
not allow.

A request that is never answered is not always the fixture's fault.
Check that the line is terminated and the cable is good before blaming
the unit (see [Answered late or asked twice](/help/intermittent/#answered-late-or-asked-twice)).
The same parameter going unanswered every time, on a fixture that
answers everything else, usually means the fixture does not support it
and ignores the request rather than refusing it.

## The bytes

Select a row to see its bytes under the table: what was sent and what
came back, a byte at a time. You can select and copy them. Above them
are the details the table has no room for: who sent the request,
the parameter's number, the transaction number and how much data the
request carried.

The bytes are the record. The words in the table are the bench's
reading of them, and the bytes are what you attach when you tell a
maker their fixture does something wrong.

## Saving and opening a log

**Export…** saves the log as a `.jsonl` file, named by the date and time
so it sorts among the bench's own, and shows it in
Finder *(macOS)* / the file manager *(Windows, Linux)*.
**Open Log…** reads any saved log in the same sheet: one you exported,
one the command line recorded (see
[Record a fixture and replay it](/help/record-replay/)), or one
someone sent you.

A behavior check files its own log, holding only the packets that check
sent, beside its result in the captures folder. **Show Wire Log** on
the check opens it (see [Keeping the result](/help/behavior/#keeping-the-result)).

## From the command line

`rdmbench-cli wire` reads the newest log in the captures folder, or the
file you give it, one exchange per line, with the same tally at the
end. `--hex` prints each exchange's bytes under it. To keep a log of
a command-line run, or to answer for a fixture from one, see
[Record a fixture and replay it](/help/record-replay/).