Read the wire log

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). 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), 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).

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.