Domain 3: FSoE frame structure and data coding
Domain 3 tests whether you can read an FSoE frame and explain what each field protects. You need the safe data container, command field, connection identifier, and CRC arrangement, plus the data-coding rules that keep mapped safety data unambiguous.
Core rules
- Command field: identifies the FSoE phase or service, such as session, connection, parameter, data, or fail-safe. It tells the receiver how to interpret the safe data container.
- Connection identifier: a 16-bit runtime handle for a specific FSoE connection. It prevents a valid frame from being accepted by the wrong slave or connection.
- Safe data container: carries the mapped safety process data. Its length and layout are configuration-controlled; the black channel treats it as opaque bytes.
- CRC: FSoE uses two 16-bit CRCs. CRC_0 protects the command and safe data; CRC_1 protects the connection identifier together with CRC_0. This gives both data integrity and connection/addressing integrity.
- Data coding: multi-byte values use the profile's defined byte order; safe inputs and outputs are mapped bit/byte-exactly at both ends. A mapping error is a safety error, not a cosmetic one.
Worked example
A master sends a Data frame: command = Data, connection ID = 0x1234, two safe output bytes = 0x01 0x00, then CRC_0 and CRC_1. The slave checks that 0x1234 is its active connection, recomputes CRC_0 over command and data, and recomputes CRC_1 over connection ID and CRC_0. If a bit flip changes the connection ID to 0x1334, CRC_0 may still pass because the data area is unchanged, but CRC_1 fails. If a bit flip changes the output byte, CRC_0 fails. Only after both checks does the slave apply 0x01 0x00.
Traps
Confusing the EtherCAT FCS with the FSoE CRCs. Assuming the command field is free-form application data. Checking only CRC_0. Forgetting that a connection ID mismatch is a safety fault. Mapping a 16-bit value with opposite endianness at master and slave.