Protocol conformance tests

The suite now lives inside the explorer itself.

Why it moved. This page used to load the explorer in a hidden frame and drive its decoder from the outside. That works over http, but not when the files are opened straight from disk: the browser gives every file:// document its own unique origin, so one page cannot reach into another — it does not merely return nothing, it throws.

Running the tests inside the explorer avoids that entirely, works from a hosted copy and a saved offline copy alike, and has a genuine advantage: the tests exercise the code in that very file, so they verify the copy you are actually holding rather than a copy of the logic.

What it checks

One hundred and twenty-three assertions: sixty-two across all fifteen commands plus framing, request encoding and the read-only guard, twenty-eight that drive every simulator fault through the real receive path and the receiver's own rules, and thirty-three diagnostics checks built from the frames a real console actually sent on FSE23204 and from regressions caught across five rounds of review.

What the simulator group now proves. It used to decide for itself why each reply had ended, which meant the receiver's end-marker check, its 64 KB cap, its idle timer and its cleanup were never run: any of them could be deleted with the suite still green. Replies are now fed through the real receive path in chunks, and six assertions pin the receiver's rules directly — ending on the end marker, ending on an idle gap, ending on the timeout, reassembling a reply split across many short reads, cutting one short when the gap exceeds the idle threshold, and capping an oversized reply at 64 KB.

Known gaps, stated rather than implied. The field layouts for i113, i114, i601, i701 and i873 are not anchored to any document we hold, so those tests pin the bytes we believe are right rather than proving them. The display-format commands, the ESC handling and the documented commands this tool does not implement have no tests at all. Each response is built to the layout documented in the Veeder-Root TLS-4xx RS-232 Serial Commands Manual, and every decoded field is compared against the value that was encoded — so a parser reading the right bytes from the wrong offsets fails rather than quietly producing plausible numbers.

Simulator faults. When served over http, the suite also loads the console simulator in a hidden frame and pushes every fault mode it offers — all nineteen, including loopback and echo — through the analyser, one fault at a time against every command the simulator knows. Each must raise the anomaly its help text promises and nothing it should not; conformant frames must raise none. The group also checks coverage both ways, so a fault added to the simulator without an expectation here is a failure, not a silent gap. From a saved offline copy this group is reported as skipped, never as passed, because a file:// page cannot reach into the frame.

The suite is itself checked for teeth: deliberately reverting the checksum, the liquid-sensor alarm table, the input status names and the tank bound each produce failures. A green run means something.

Verifying a customer's copy

If a report ever looks doubtful, ask them to add ?selftest to the address of the page or file they ran and send a screenshot. It confirms whether their build's protocol arithmetic was sound, without needing them to re-run anything against the console.

Serving locally, if you want to

Needed only for the simulator-fault group; everything else runs from disk:

python -m http.server 8765

then open http://localhost:8765/index.html?selftest.