FSoE Data PDU: Master and Slave Structure

The Data state is the final state of the FSoE connection setup and the one in which the connection spends the rest of its lifetime. It follows the Parameter state. Unlike the previous states, where the number of FSoE cycles was fixed by the protocol, the Data state runs continuously — FSoE cycles are transferred until either a communication error occurs or an FSoE node is stopped locally. In each cycle, the FSoE Master sends SafeOutputs to the FSoE Slave, and the FSoE Slave acknowledges by sending SafeInputs back to the master.

The Data state uses two commands:

• ProcessData — used when the safety data is valid.
• FailSafeData — used when a node locally detects that its safety data is not valid or is to be switched to the safe state.

This article walks through all four Data-state PDUs defined in ETG.5100 S (D) V1.2.0, §8.2.2.6, using the spec’s canonical example of 4 octets of safety data.

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 is shown in FSoE Reset PDU: Master and Slave Structure.

When is the Data state entered and exited?

The Data state is entered when the master leaves the Parameter state by sending a Safety Master PDU with the ProcessData (or FailSafeData) command. Once in the Data state, the connection stays there indefinitely:

Both nodes exit the Data state immediately if they detect an FSoE communication error — in that case they fall back to the Reset state.

ProcessData command (valid data)

Safety Master PDU (FSoE Master → Slave)

The master sends this PDU to transfer SafeOutputs to the slave. This is Table 23 of ETG.5100 S (D) V1.2.0 for 4 octets of safety data.

Key points:

• Command (octet 0) is ProcessData.
• SafeData[0..3] carry the SafeOutputs — the actual safety-related output data from the master to the slave. The bytes are placed in order: SafeData[0] is the 1st octet, SafeData[1] is the 2nd, and so on.
• Conn_Id (octets 9 and 10) carries the Connection ID, as in the Connection and Parameter states.
• CRC_0 and CRC_1 are transmitted as 16-bit little-endian values. CRC inheritance is active across all Data-state cycles, chaining each PDU to the previous one.

Safety Slave PDU (FSoE Slave → Master)

The slave acknowledges the master’s ProcessData PDU and sends SafeInputs back to the master. This is Table 24 of ETG.5100 S (D) V1.2.0.

Note the asymmetry with the earlier states: in the Data state, the slave does not echo back the master’s safety data. Instead, it sends its own SafeInputs — the safety-related input data from the slave to the master. The master sends SafeOutputs, the slave responds with SafeInputs; each direction carries its own independent payload.

FailSafeData command (safe state)

If the FSoE Master locally detects that the SafeOutputs are not valid or are to be switched to the safe state, it sends the FailSafeData command instead of ProcessData. The same applies to the FSoE Slave: if it locally detects that the SafeInputs are not valid or are to be switched to the safe state, it sends FailSafeData instead of ProcessData.

Safety Master PDU with FailSafeData (FSoE Master → Slave)

This is Table 25 of ETG.5100 S (D) V1.2.0 for 4 octets of safety data.

Key points:

• Command (octet 0) is FailSafeData.
• All SafeData octets are set to 0 — the fail-safe data carries no useful payload; it signals that the sender has switched its outputs to the safe state.
• Conn_Id and CRC fields behave exactly as in the ProcessData PDU. The CRC is still computed and must still verify — the fail-safe state is a defined operational state, not a communication error.

Safety Slave PDU with FailSafeData (FSoE Slave → Master)

This is Table 26 of ETG.5100 S (D) V1.2.0 for 4 octets of safety data.

ProcessData and FailSafeData are chosen independently

A key property of the Data state is that the choice between ProcessData and FailSafeData is independent in each direction — it depends only on local circumstances, not on the command received from the peer:

• The master sends ProcessData if its SafeOutputs are valid, or FailSafeData if they are not.
• The slave sends ProcessData if its SafeInputs are valid, or FailSafeData if they are not.

This means it is entirely normal for one direction to carry ProcessData while the other carries FailSafeData in the same cycle. For example, if the master’s SafeOutputs are valid but the slave’s SafeInputs are not, the master sends ProcessData and the slave responds with FailSafeData. Neither node needs to wait for the other to switch commands; the decision is purely local.

Putting it together: the Data-state exchange

The Data state is a continuous cyclic exchange:

1. Master → Slave: Safety Master PDU with Command = ProcessData (carrying SafeOutputs) or Command = FailSafeData (all SafeData = 0).
2. Slave → Master: Safety Slave PDU with Command = ProcessData (carrying SafeInputs) or Command = FailSafeData (all SafeData = 0).

This cycle repeats indefinitely. The command in each direction is chosen independently based on the local validity of the safety data. If either node detects an FSoE communication error (see FSoE: List of all communication error codes), both nodes fall back to the Reset state and the connection setup starts over.

Summary

In the Data state the FSoE Safety PDU finally carries user safety data: the master sends SafeOutputs and the slave responds with SafeInputs, each using the ProcessData command. If either node’s safety data is not valid or is to be switched to the safe state, it sends the FailSafeData command instead, with all SafeData octets set to 0. The choice between the two commands is independent in each direction and depends only on local circumstances. The Data state runs continuously until a communication error occurs (triggering a fallback to Reset) or a node is stopped locally. CRC inheritance chains every PDU to the previous one throughout the entire Data state, so any corruption, loss, or reordering is detected immediately.

References

• ETG.5100 S (D) V1.2.0, §8.2.2.6 Data state, Tables 23–26.

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 Parameter PDU: Master and Slave Structure — PDU layout for the Parameter 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