The Connection state follows the Session state in the FSoE connection setup. Its purpose is to transfer the 16-bit Connection ID — a unique identifier generated by the safety configurator of the FSoE Master — together with the 16-bit FSoE Slave Address from the master to the slave. The slave acknowledges by echoing the same safety data back. From this point on, the Connection ID is carried in the Conn_Id field of every subsequent Safety PDU, so that both nodes can check whether a telegram is actually addressed to them.
This article walks through the two Connection-state PDUs defined in ETG.5100 S (D) V1.2.0, §8.2.2.4, 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.
Note — the relevant data bytes are the Connection ID and the FSoE Slave Address. In every Connection-state PDU, the four SafeData octets carry two 16-bit values:
SafeData[0..1](octets 1 and 2) — the Connection ID (low octet, high octet). This is a unique 16-bit value generated by the safety configurator;0x0000is not permitted, so up to 65 535 FSoE connections can coexist in one communication system.SafeData[2..3](octets 5 and 6) — the FSoE Slave Address (low octet, high octet). This is a unique address set at the respective FSoE Slave device.Unlike the Reset and Session states, the
Conn_Idfield (octets 9 and 10) is no longer 0 — it now carries the actual Connection ID, just as it will in every subsequent Safety PDU once the connection is established. The CRC fields are still transmitted and must verify, computed from the reset initial state inherited from the preceding Reset state (see FSoE: How does CRC inheritance work? and How to compute the CRC checksum for FSoE PDUs?).
When is the Connection state entered and exited?
The Connection state is entered when the master leaves the Session state by sending a Safety Master PDU with the Connection command. The state transitions mirror those of the Session state:
| Direction | Condition |
|---|---|
| Master exits Connection | It has transferred the complete Connection ID and FSoE Slave Address and received the associated acknowledgement from the slave, then sends a Safety PDU with the Data command (entering the cyclic data exchange). |
| Slave exits Connection | It receives a Safety PDU with the Data command from the master. |
Both nodes also exit the Connection state immediately if they detect an FSoE communication error — in that case they fall back to the Reset state.
Safety data transferred in the Connection state
Before looking at the full PDU layout, it is worth focusing on just the safety data portion. Table 15 of ETG.5100 S (D) V1.2.0 defines which bytes are transferred:
| SafetyData Octet | Description |
|---|---|
| 0 | low octet (bits 0–7) of the Connection ID |
| 1 | high octet (bits 8–15) of the Connection ID |
| 2 | low octet (bits 0–7) of the FSoE Slave Address |
| 3 | high octet (bits 8–15) of the FSoE Slave Address |
The Connection ID and the FSoE Slave Address are each 16 bits wide, so together they occupy exactly 4 SafeData octets. This has an important consequence for the number of FSoE cycles required:
| Safety data length | Cycles to transfer Connection ID + Slave Address | Reason |
|---|---|---|
| 4 octets | 1 cycle | All 4 octets fit into one PDU. |
| 2 octets | 2 cycles | Only 2 SafeData octets per cycle. |
| 1 octet | 4 cycles | Only 1 SafeData octet per cycle. |
This is why the spec’s examples use 4 octets of safety data: with 4 octets, the entire Connection ID and FSoE Slave Address are transferred in a single FSoE cycle.
Master Connection PDU (FSoE Master → Slave)
The master sends this PDU to transfer the Connection ID and the FSoE Slave Address. The example below is Table 16 of ETG.5100 S (D) V1.2.0 for 4 octets of safety data.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octet 0 | Connection Id, low octet Octet 1 | Connection Id, high octet Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | FSoE Slave Address, low octet Octet 5 | FSoE Slave Address, high octet Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, low octet Octet 9 | Connection Id, high octet Octet 10 |
Key points:
- Command (octet 0) is
Connection. - SafeData[0..1] (octets 1 and 2) carry the 16-bit Connection ID (little-endian). This is the same value that now also appears in the
Conn_Idfield. - SafeData[2..3] (octets 5 and 6) carry the 16-bit FSoE Slave Address (little-endian). This is the unique address configured at the slave device.
- Conn_Id (octets 9 and 10) carries the Connection ID — it is no longer 0 as in the Reset and Session states. From this PDU onwards, the
Conn_Idfield is populated in every Safety PDU. - CRC_0 and CRC_1 are transmitted as 16-bit little-endian values, computed from the reset initial state inherited from the preceding Reset state.
Slave Connection PDU (FSoE Slave → Master, acknowledgement)
The slave acknowledges the Connection command by sending back the same safety data — i.e. it echoes the Connection ID and the FSoE Slave Address that the master sent. This is Table 17 of ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octet 0 | Connection Id, low octet Octet 1 | Connection Id, high octet Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | FSoE Slave Address, low octet Octet 5 | FSoE Slave Address, high octet Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, low octet Octet 9 | Connection Id, high octet Octet 10 |
Unlike the Session state, where the slave responds with its own independently generated Slave Session ID, in the Connection state the slave echoes back the Connection ID and FSoE Slave Address that the master sent. This is the slave’s way of confirming that it has received and accepted the addressing information.
Why are both the Connection ID and the FSoE Slave Address transferred?
The two values serve complementary roles in addressing:
- The FSoE Slave Address is unique in the communication system and is set at the respective FSoE Slave device. By transferring it together with the Connection ID, the slave can check whether it was actually addressed — so that invalid addressing would be detected.
- The Connection ID is also unique in the communication system (generated by the safety configurator of the FSoE Master). Because it is unique, it is sent in the
Conn_Idfield of every subsequent Safety PDU, so that both the FSoE Master and the FSoE Slave can detect whether they are addressed with the telegram.
The combination of the two means that a slave can verify during connection setup that it is the intended target (via the FSoE Slave Address), and then during cyclic operation both nodes can verify each telegram (via the Connection ID in the Conn_Id field).
How many FSoE connections are possible?
The Connection ID is a 16-bit value, which would nominally allow 65 536 distinct values. However, Connection ID = 0x0000 is not permitted, so the maximum number of FSoE connections in a communication system is 65 535. If several FSoE Masters are present in the communication system, the user must ensure that the Connection IDs used by all masters are unique across the entire system.
Putting it together: the Connection-state exchange
The Connection state is a simple echo handshake:
- Master → Slave: Safety Master PDU with
Command = Connection, carrying the Connection ID inSafeData[0..1], the FSoE Slave Address inSafeData[2..3], and the Connection ID in theConn_Idfield. - Slave → Master: Safety Slave PDU with
Command = Connection, echoing back the same Connection ID and FSoE Slave Address.
Once the master has transferred the complete Connection ID and FSoE Slave Address and received the slave’s acknowledgement, it leaves the Connection 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.
Summary
In the Connection state the FSoE Safety PDU carries two 16-bit values in the SafeData fields: the Connection ID (a unique system-wide identifier generated by the safety configurator) and the FSoE Slave Address (a unique address set at the slave device). The slave acknowledges by echoing this data back. Unlike the Reset and Session states, the Conn_Id field is now populated with the actual Connection ID — and it stays populated in every subsequent Safety PDU, enabling both nodes to verify that each telegram is addressed to them. Because Connection ID 0x0000 is not permitted, up to 65 535 FSoE connections can coexist in one communication system.
References
- ETG.5100 S (D) V1.2.0, §8.2.2.4 Connection state, Tables 15–17.
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 Parameter PDU: Master and Slave Structure — PDU layout for the Parameter 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
