The real-time data transfer shall be performed by means of Safety Process Data Objects (SPDO).
Data length and mapping of application objects into SPDOs shall be determined by the corresponding SPDO mapping structures within the Safety Object Dictionary (SOD). The mapping of application objects into an SPDO may be transmitted to a device during the device configuration process by applying the SSDO services to the corresponding entries of the Object Dictionary.
The length of SPDOs of a device is application-specific and shall be determined by the corresponding mapping object.
There are two uses for SPDOs. The first is data transmission and the second data reception.
Transmit SPDOs (TxSPDOs) and Receive SPDOs (RxSPDOs) are distinguished. Devices supporting TxSPDOs are SPDO producers and devices which are able to receive SPDOs are called SPDO consumers.
SPDOs is described by the SPDO communication parameter and the SPDO mapping parameter. For each SPDO, the pair of communication and mapping parameters shall be mandatory.
SPDO communication parameter shall describe the communication capabilities of the SPDO.
SPDO mapping parameter shall describe mapping for each object contained in SPDO payload data to object dictionary entries and vice versa.
SPDO mapping shall be variable or static. Static mapping shall be pre-defined by the vendor and shall not be modified in any way. Variable mapping shall be configured during commissioning.
7.6.2 Transmit SPDOs
The TxSPDO communication parameters shall be specified by SOD indices 1C00h -- 1FFEh (SPDO_TxCommParam_XXXh_REC). An SN may support up to 1 023 TxSPDOs. The implementation of the first TxSPDO shall be mandatory. The amount of additional TxSPDOs is vendor specific. The TxSPDO mapping parameters is described by indices C000h -- C3FEh (SPDO_TxMappParam_XXXh_AU32). The data to be transmitted shall be assembled according to the corresponding mapping data.
Sending SPDO data shall be implicitly limited to the Operational state. Refer to 7.5 for the corresponding entries within the SOD.
7.6.3 Receive SPDOs
The RxSPDO communication parameters is described by indices 1400h -- 17FEh (RxSPDOCommParam_XXXh_REC). An SN may support up to 1 023 RxSPDOs. The implementation of RxSPDOs shall be optional (e.g. an input module, which is a simple producer, does not need to have an RxSPDO). The RxSPDO mapping parameters is described by indices 1800h -- 1BFEh (SPDO_RxMappParam_XXXh_AU32). The received data shall be transferred to the communication objects assigned to them by the RxSPDO mapping parameters. The application accesses the received SPDO data by reading these communication objects.
Receiving SPDO data shall be implicitly limited to the Operational state. Refer to 7.5 for the corresponding entries within the SOD.
7.6.4 SPDO mapping parameter
The indices 1800h -- 1BFEh (SPDO_TxMappParam_XXXh_AU32) and C000h -- C3FEh (SPDO_RxMappParam_XXXh_AU32) shall contain the mapping parameters for transmitting and receiving SPDOs. For both indices, sub index 0 shall contain the number of valid mapping entries which is also the number of communication variables (SOD entries) to be transmitted or received. The sub indices 01h to NumberOfEntries shall contain information about the mapped application variables. These entries shall describe the SPDO contents by their index, sub index and length. All three values shall be given in hexadecimal notation. The encoding of a mapping entry (sub index 01h -- FDh) is specified by Table 163. The length entry contains the length of the object in bits (01h -- FFh). This parameter can be used to check the overall mapping length.
Table 163 – Structure of SPDO mapping entry
Bit 31 -- bit 16 Bit 15 -- bit 8 Bit 7 -- bit 0 Index (16 bit) sub index (8 bit) data length (8 bit)
The commissioner shall be responsible for the correctness of the mapping data. If objects are mapped which shall not be mapped according to the object attribute, the SN shall not switch to state Operational. If data within an RxSPDO is not used by the consumer, it shall be mapped to the data types (index 0001h -- 0007h), these serve as “dummy entries”. The corresponding data within the RxSPDO shall not be evaluated by the device. This feature is useful if a TxSPDO is used for several consumers, each only utilizing parts of the transmitted data. It shall not be possible to map those “dummy entries” into a TxSPDO.
7.6.5 SPDO mapping example Example devices (see Figure 42) are:
⎯ the SN with “Main-SADR” 12 is an input module with 32 digital inputs,
⎯ the SN with “Main-SADR” 13 is an output module with 8 digital outputs, and
⎯ the SN with “Main-SADR” 14 is an output module with 16 digital outputs.
Figure 42 – SPDO mapping example
It is assumed that the inputs are available at SOD-index 6000h sub indices 01h – 04h and that the data type is UNSIGNED8. It is also assumed that the outputs need to be written to SOD index 6200h sub indices 01h respectively 01h and 02h. The data type again is UNSIGNED8. It is then assumed that SN 13 needs the information from the 3rd input octet and that SN 14 needs the information from the 1st and 4th input octet.
The communication parameters from SN 12 (producer) are shown in Table 164.
Table 164 – Mapping example table 1
Index Sub index Data Description 1C00h 1 12 The TxSPDO is broadcast under the SADR 12
The mapping of SN 12 (producer) may be specified as in Table 165.
Table 165 – Mapping example table 2
Index Sub index Data Description C000h 0 4 four valid mapping entries
1 60000108h Mapping entry 1: 8bits of the object from index 6000h sub index 1 are mapped into the SPDO
2 60000208h Mapping entry 2: 8bits of the object from index 6000h sub index 2 are mapped into the SPDO
3 60000308h Mapping entry 3: 8bits of the object from index 6000h sub index 3 are mapped into the SPDO
4 60000408h Mapping entry 4: 8bits of the object from index 6000h sub index 4 are mapped into the SPDO
SN
Device with multiple SNs SN MN
SC CN
Modular Device with multiple SNs SN
Direct Communication between a SN and a specific bit of another SN
SADR 14 SADR 12
SADR 13
This TxSPDO mapping could be a predefined mapping. Input 2 is mapped into the TxSPDO although it is not needed by any of the SNs.
According to the mapping parameters, the payload data of the TxSPDO looks as in Table 166.
Table 166 – Mapping example table 3
Octet Data 1 Input Octet 1
2 Input Octet 2 3 Input Octet 3 4 Input Octet 4
The communication parameter for SN 13 is specified as in Table 167.
Table 167 – Mapping example table 4
Index Sub index Data Description 1400h 1 12 SN 13 will map the data of a received TxSPDO from
SADR 12 according to the mapping entries
The mapping of the SN 13 looks as in Table 168.
Table 168 – Mapping example table 5
Index Sub index Data Description 1800h 0 2 two valid mapping entries
1 00060010h Mapping entry 1: 16 bits of the RxSPDO are mapped into the object at index 0006h sub index 0
2 62000108h Mapping entry 2: 8bits of the RxSPDO are mapped into the object at index 6200h sub index 1
3 00050008h Mapping entry 2: 8bits of the RxSPDO are mapped into the object at index 0005h sub index 0
As described above, SN 13 is only interested in the 3rd input octet of SN 12. Therefore, the first two input octets (first two octets of the RxSPDO) are ignored by using “dummy mapping”.
The 4th octet is also mapped to a “dummy entry”. This is required because only RxSPDOs which have the same length as the mapped data are accepted.
The communication parameter of SN 14 is shown in Table 169.
Table 169 – Mapping example table 6
Index Sub index Data Description 1400h 1 12 SN 14 will map the data of a received TxSPDO from
SADR 12 according to the mapping entries
The mapping of the SN 14 is shown in Table 170.
Table 170 – Mapping example table 7
Index Sub index Data Description 1800h 0 3 three valid mapping entries
1 62000108h Mapping entry 1: 8bits of the RxSPDO are mapped into the object at index 6200h sub index 1
2 00060010h Mapping entry 2: 16 bits of the RxSPDO are mapped into the object at index 0006h sub index 0
3 62000208h Mapping entry 3: 8bits of the RxSPDO are mapped into the object at index 6200h sub index 2
As described above, SN 14 is only interested in input octets 1 and 4 of SN 12. Input octets 2 and 3 (respectively octet 2 and 3 of the RxSPDO) are ignored by using “dummy mapping”.
7.6.6 SPDO error handling
7.6.6.1 Non-mapable application object
The SN shall ensure that only mapable application objects are accepted. If a non mapable object is recognized, the SN shall not store this mapping data into the SOD.
NOTE As a result, the checksum of the SOD will be different from the expected checksum stored on the SCM and therefore, the SN will not be switched to the Operational state (see 7.7.12.2).
7.6.6.2 Unexpected length of RxSPDO
If an SPDO is received with a length that is not equal to the length of the mapped data, the SPDO shall be ignored. Additional diagnosis data may be provided via the SOD.