LS XGT Cnet Frame Decoder
Split an XGT Cnet frame into its fields and verify the BCC.
BCC matches · expected A4 · found A4
| # | Device | Type | Count | Data |
|---|---|---|---|---|
| 1 | %MW100 | Word | — | — |
<ENQ>20rSS0106%MW100<EOT>A4
This tool decodes an LS ELECTRIC XGT Cnet dedicated-protocol frame. Paste it as hex bytes, as raw text, or with <ENQ>markers, and it separates the station, command, command type, data blocks and any error code — then verifies the BCC and tells you what it should have been. Reference: the frame summing to 03A4 carries BCC A4.
How it works
An XGT frame is delimited by control characters — ENQ opens a request, EOT closes it, and a response opens with ACK or NAK and closes with ETX. Between them everything is ASCII: the station is two hex characters, the command is a single letter whose case decides whether a BCC follows, and the command type says whether the data area lists devices individually or describes one continuous run.
The checksum is where most time gets lost, because two different mistakes look identical on an analyser. Either the sum is wrong, or the frame lost a byte and the sum is right for what remains. Showing the expected value beside the received one separates them immediately, which is why the decoder computes it even for frames that are not required to carry a BCC at all.
Worked example
ENQ · station 20 · r SS · 1 block · size 06 · %MW100 · EOT
sum ENQ…EOT = 03A4 → low byte A4
lowercase r → BCC required · sent A4 → matches
Frame fields
| Parameter | Value | Notes |
|---|---|---|
| ENQ / EOT | 0x05 / 0x04 | request delimiters |
| ACK / NAK / ETX | 0x06 / 0x15 / 0x03 | response delimiters |
| Station | 2 ASCII hex chars | |
| Command | R W X Y | lowercase adds a BCC |
| Command type | SS / SB | individual / continuous |
| Variable size | character count of the name | |
| Error code | 4 ASCII chars | NAK frames only |
| BCC | sum header…tail mod 256 |
Source: LS ELECTRIC, Cnet I/F Module (XGL-C22A/C22B/CH2A/CH2B/C42A/C42B) User's Manual V3.3, Ch.7; BCC arithmetic from the XGB Cnet I/F User's Manual V2.0, §7.2.1.
FAQ
▸When does an XGT frame carry a BCC?
Only when the command letter is lowercase. LS states it plainly: with a lowercase command the BCC is added to the frame check, with an uppercase one it is not. So r, w, x and y frames end with two extra characters and R, W, X and Y frames do not — the decoder flags a frame that breaks either half of that rule.
▸How is the BCC calculated?
Add every byte from the header through the tail, both included, and keep the low byte: for a request that is ENQ through EOT, for a response ACK or NAK through ETX. The result is written as two ASCII hex characters after the tail. It is a plain unsigned 8-bit sum — no XOR, no seed, no complement.
▸My BCC looks wrong — what does the decoder show?
Both numbers. It always computes what the BCC should be and shows it next to what was actually sent, so you can see whether the mismatch is a checksum bug or a byte that went missing earlier in the frame. A payload that does not add up still decodes into blocks rather than failing outright, so a data error never hides the checksum verdict.
▸What do the command types SS and SB mean?
SS is the individual form and SB the continuous form. R with SS reads named devices one by one, up to sixteen blocks; R with SB reads a run of words from one starting device. Write mirrors it. Bit devices cannot be read or written continuously.
▸Where does the NAK error code sit?
Between the command type and the ETX, as two hex bytes written as four ASCII characters. The decoder looks the code up in the published table, so 0011 reads as a data error and 1232 as a request beyond sixty words.
▸Is my frame uploaded?
No. Decoding runs entirely in your browser.