The Parameter state follows the Connection state in the FSoE connection setup. Its purpose is to transfer the safety-related communication parameters (the FSoE watchdog value) and the device-specific safety-related application parameters from the master to the slave. The slave acknowledges each Parameter PDU by echoing the safety data back. Because the application parameters can have any length, the transfer may span multiple FSoE cycles. CRC inheritance ensures the safety and consistency of the parameter transfer across all cycles (see FSoE: How does CRC inheritance work?).
This article walks through the Parameter-state PDUs defined in ETG.5100 S (D) V1.2.0, §8.2.2.5, using the spec’s canonical example of 4 octets of safety data and 2 octets of safety-related application parameter, which requires two FSoE cycles.
Note — the number of safety data bytes is fixed per direction. Each FSoE connection has a fixed safety data length (master→slave and slave→master), configured identically on both nodes. The permitted lengths are 1, 2, 4, 6 or 8 octets. The actual length for a given connection depends on the FSoE slave device and must be taken from the slave’s documentation or device description file (ESI/EEPROM). The examples below use 4 octets as in the spec; the byte layout for other lengths follows the same pattern (SafeData octets are filled in order, with unused octets in the last cycle set to 0).
When is the Parameter state entered and exited?
The Parameter state is entered when the master leaves the Connection state by sending a Safety Master PDU with the Parameter command. The state transitions are:
| Direction | Condition |
|---|---|
| Master exits Parameter | It has transferred the complete set of communication and application parameters and received the associated acknowledgements from the slave, then sends a Safety PDU with the Data command (entering the cyclic data exchange). |
| Slave exits Parameter | It receives a Safety PDU with the Data command from the master. |
Both nodes also exit the Parameter state immediately if they detect an FSoE communication error — in that case they fall back to the Reset state.
Safety data transferred in the Parameter state
The safety data in the Parameter state is structured differently from the previous states. Instead of a fixed set of fields, it carries a variable-length payload headed by three 16-bit header fields. Table 18 of ETG.5100 S (D) V1.2.0 defines the layout:
| SafetyData Octet | Description |
|---|---|
| 0 | low octet (bits 0–7) of the length of the communication parameters in octets (= 2) |
| 1 | high octet (bits 8–15) of the length of the communication parameters in octets (= 0) |
| 2 | low octet (bits 0–7) of the FSoE watchdog (in ms) |
| 3 | high octet (bits 8–15) of the FSoE watchdog (in ms) |
| 4 | low octet (bits 0–7) of the length of the application parameters in octets |
| 5 | high octet (bits 8–15) of the length of the application parameters in octets |
| 6 | 1st octet of the safety-related application parameter |
| … | |
| n+5 | nth octet of the safety-related application parameter |
The first two 16-bit fields are the communication parameter length (always 2, i.e. just the watchdog value) and the FSoE watchdog value in milliseconds. The next 16-bit field is the application parameter length, followed by the application parameter bytes themselves. The FSoE watchdog and the safety-related application parameters are configured via the safety configurator of the FSoE Master.
How many FSoE cycles are required?
Because the application parameters can have any length, the total number of FSoE cycles depends on both the application parameter length and the fixed safety data length of the Safety PDU:
$$ \text{cycles} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$where the 6 accounts for the three 16-bit header fields (comm. param. length, watchdog, app. param. length). If not all safety data octets are required in the last FSoE cycle, the unused octets shall be transferred as 0.
For the spec’s example (4 octets of safety data, 2 octets of application parameter), the total payload is 6 + 2 = 8 octets, which fits into ⌈8/4⌉ = 2 FSoE cycles. The first cycle carries the communication parameter length, the watchdog, and the first two octets would be the application parameter length — but in this example the application parameter length (2) is sent in the second cycle together with the two application parameter bytes, as shown below.
First cycle — Communication parameters
First Safety Master PDU (FSoE Master → Slave)
The master sends this PDU to transfer the communication parameter length and the FSoE watchdog value. This is Table 19 of ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | comm. param. len, lo Octet 1 — = 2 | comm. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, lo Octet 5 — in ms | watchdog, hi Octet 6 — in ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Key points:
- Command (octet 0) is
Parameter. - SafeData[0..1] (octets 1 and 2) carry the 16-bit communication parameter length in octets. This is always 2 (little-endian:
0x02, 0x00), because the only communication parameter is the 16-bit watchdog value. - SafeData[2..3] (octets 5 and 6) carry the 16-bit FSoE watchdog value in milliseconds (little-endian).
- Conn_Id (octets 9 and 10) carries the Connection ID — as in the Connection state, it is now populated in every Safety PDU.
- CRC_0 and CRC_1 are transmitted as 16-bit little-endian values. CRC inheritance is active across all Parameter-state cycles.
First Safety Slave PDU (FSoE Slave → Master, acknowledgement)
The slave acknowledges the first Parameter PDU by echoing back the same safety data. This is Table 20 of ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | comm. param. len, lo Octet 1 — = 2 | comm. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, lo Octet 5 — in ms | watchdog, hi Octet 6 — in ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Second cycle — Application parameters
The FSoE Master sends the second Safety Master PDU once it has correctly received the first Safety Slave PDU.
Second Safety Master PDU (FSoE Master → Slave)
The master sends this PDU to transfer the application parameter length and the application parameter bytes themselves. This is Table 21 of ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | app. param. len, lo Octet 1 — = 2 | app. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | app. param. byte 1 Octet 5 | app. param. byte 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Key points:
- SafeData[0..1] (octets 1 and 2) carry the 16-bit application parameter length in octets (little-endian). In this example it is 2.
- SafeData[2..3] (octets 5 and 6) carry the application parameter bytes. In this example there are exactly 2 bytes, filling both available slots.
- If the application parameter were longer than the available SafeData octets in one cycle, the transfer would continue in additional cycles, with the remaining bytes placed in the same SafeData positions (starting at SafeData[0] of the next cycle, after any remaining header). Unused octets in the last cycle are set to 0.
Second Safety Slave PDU (FSoE Slave → Master, acknowledgement)
The slave acknowledges the second Parameter PDU by echoing back the same safety data. This is Table 22 of ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | app. param. len, lo Octet 1 — = 2 | app. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | app. param. byte 1 Octet 5 | app. param. byte 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Putting it together: the Parameter-state exchange
The Parameter state is a multi-cycle echo handshake. Each cycle follows the same pattern:
- Master → Slave: Safety Master PDU with
Command = Parameter, carrying the next chunk of the parameter payload in the SafeData fields. - Slave → Master: Safety Slave PDU with
Command = Parameter, echoing back the same safety data.
The master sends the next cycle only after it has correctly received the slave’s acknowledgement of the previous cycle. The transfer continues until all communication and application parameters have been sent. Once the master has transferred the complete parameter set and received the final acknowledgement, it leaves the Parameter state by sending a Safety PDU with the Data command — this transitions the connection into cyclic data exchange. If either node detects an FSoE communication error during the exchange, both fall back to the Reset state.
Why is CRC inheritance important in the Parameter state?
Because the parameter transfer spans multiple FSoE cycles, CRC inheritance is what binds the individual PDUs into a single safety-relevant transfer. Each cycle’s CRC is computed not just over the current PDU’s bytes, but also over the CRC of the previous PDU — forming a chain that the receiver can verify end-to-end. If any PDU in the sequence is corrupted, lost, or reordered, the CRC chain breaks and the receiver detects the error. This is why the spec notes that “CRC inheritance ensures safety and consistent parameter transfer.” See FSoE: How does CRC inheritance work? for the details of the algorithm.
Summary
In the Parameter state the FSoE Safety PDU carries a variable-length parameter payload headed by three 16-bit fields: the communication parameter length (always 2), the FSoE watchdog value in milliseconds, and the application parameter length. The application parameter bytes follow. Because the payload can exceed the fixed safety data length of the PDU, the transfer may span multiple FSoE cycles, with unused octets in the last cycle set to 0. The slave acknowledges each cycle by echoing back the safety data. CRC inheritance across all cycles ensures the safety and consistency of the complete parameter transfer. The connection leaves the Parameter state when the master sends the Data command, entering cyclic data exchange.
References
- ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tables 18–22.
Related posts
Overview & basics
- What does the FSoE abbreviation actually mean? — what the FSoE acronym stands for
- FSoE frame structure explained by examples — general Safety PDU layout
- All the states of the FSoE state machine — the five FSoE states and their transitions
- FSoE: Safety PDU command table — the full list of FSoE commands
PDU structures by state
- FSoE Reset State PDU: Master and Slave Structure — PDU layout and error codes for the Reset state
- FSoE Session PDU: Master and Slave Structure — PDU layout for the Session state
- FSoE Connection PDU: Master and Slave Structure — PDU layout for the Connection state
- FSoE Data PDU: Master and Slave Structure — PDU layout for the Data state
- FSoE Reset PDU: Master and Slave Structure — byte layouts for all safety-data lengths
CRC
- FSoE CRC: Which polynomial does it use? — the 17-bit polynomial behind the FSoE CRC
- How are the FSoE CRC tables constructed? — how the CRC lookup tables are generated
- FSoE: How does CRC inheritance work? — how the CRC chain links consecutive PDUs
- How to compute the CRC checksum for FSoE PDUs? — byte-by-byte CRC calculation algorithm
Error codes & data format
- FSoE: List of all communication error codes — all FSoE communication error codes
- FSoE: Is data transmitted little-endian or big-endian? — byte order of multi-byte fields
