Pretends to be a TLS-350 console on a serial port, so the TLS-350 Explorer can be tested without real hardware. Deliberately supports misbehaving in specific, reproducible ways — that is the point of it.
version · internal test instrument, not for customer use
This page needs to be on the other end of a serial link from the TLS-350 Explorer. Two ways to do that:
| Virtual pair (no hardware) | Install com0com
on Windows. It creates a linked pair such as COM10 ↔ COM11.
Open one end here and the other end in the check page. |
|---|---|
| Two adapters | Two USB-to-RS232 adapters joined by a null-modem cable (TX↔RX crossed). Closer to the real thing, and it exercises the actual UART. |
Open this page and the check page in separate browser windows. A serial port can only be held by one page at a time.
| # | Product | Volume | TC Volume | Ullage | Height | Water | Temp | Delivery |
|---|
| # | Status |
|---|
| Category | Type | Device |
|---|
With no alarms listed, i101 reports all functions normal. Each alarm adds six characters to the i101 reply (24 + 6×n bytes in all), which is how a client's alarm-count limit is found: add alarms until it stops decoding them. The list is drawn up to 300 rows; beyond that the count is still exact, it is just not drawn.
This is what the simulator is for. Pick a fault, choose which command it applies to and how often, then watch whether the check page detects it.
Walks through every fault in turn so the client can be left running in live monitoring mode and watched. With "behave normally between faults" ticked, each fault is followed by a clean interval — which is what an intermittent problem actually looks like.
Load the tls350-report-….txt that the
TLS-350 Explorer produced at the site. Every reply it recorded is mapped to
the request that produced it, and the simulator sends those bytes verbatim — no framing or
checksum is added, and fault injection is bypassed for mapped requests. Requests are matched on
all six characters, so i20101 and i20102 are different entries.
This is how a site capture becomes a repeatable test.
| Request | Name | Captured | Reply policy | Reply | Will send |
|---|
The explorer keeps only the newest and oldest requests of a long session in its REQUESTS section, so a report can be missing the middle; the note above says when it is. "Captured elapsed time" is the explorer's request-to-reply measurement, which includes the bytes' own transmission time, so it reproduces the console's pace approximately.
Tests whether the client notices bytes arriving out of turn.
Long replies are shown cut at 120 bytes; the copy hex and copy text buttons on each TX line copy the complete reply. Download this alongside the explorer's report when raising a bug. Having both ends of the same conversation makes a disagreement obvious immediately, and both tools share a version number so a matching pair is easy to spot.