SIST EN 50325-4:2003

Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces -- Part 4: CANopen

EN 50325-4 specifies the following particular requirements for CANopen:
•   requirements for interfaces between programmable controllers and devices with input/output capabilities;
•   normal service conditions for devices;
•   constructional and performance requirements.

Industrielles Kommunikationssubsystem basierend auf ISO 11898 (CAN) -- Teil 4: CANopen

Sous-système de communications industriel basé sur l'ISO 11898 (CAN) pour les interfaces des dispositifs de commande -- Partie 4: CANopen

Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces - Part 4: CANopen

General Information

• Status: Published
• Publication Date: 30-Jun-2003
• ICS: 35.240.50 - IT applications in industry
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: MOV - Measuring equipment for electromagnetic quantities
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Jul-2003
• Due Date: 01-Jul-2003
• Completion Date: 01-Jul-2003
• Ref Project: EN 50325-4:2002 - Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces - Part 4: CANopen

Overview

EN 50325-4:2002 defines the CANopen profile of the industrial communications subsystem based on ISO 11898 (CAN) for controller–device interfaces. Published by CENELEC and adopted in national standards (e.g., SIST EN 50325-4:2003), this part of EN 50325 sets particular requirements for interfaces between programmable controllers and I/O-capable devices, specifies normal service/ambient conditions, and lays down constructional and performance requirements for CANopen devices used in industrial automation.

Keywords: EN 50325-4, CANopen, ISO 11898, Controller Area Network, industrial communications, device interfaces

Key topics and requirements

• Scope and intent: Defines CANopen-specific requirements for controller–device communications, device behavior under normal service, and construction/performance expectations.
• Device model: Devices are organized into communication, object dictionary, and application functional units. The object dictionary is the canonical interface between communication and application.
• Object dictionary structure:
  • Uses a 16‑bit index and sub‑index mechanism to access up to 65 536 entries.
  • Index ranges include: static data types (0001–001Fh), complex types (0020–003Fh), communication profile area (1000–1FFFh), standard device profiles (6000–9FFFh), and manufacturer‑specific areas (2000–5FFFh).
  • Supports Multiple Device Modules (up to eight device profile segments) and PDO distribution offsets for segment mapping.
• Communication model:
  • Supports synchronous (e.g., Sync message) and asynchronous transfers.
  • Defines triggering modes, inhibit-time to limit minimum time between transmissions, and relationships: master/slave, client/server, and producer/consumer.
• Service primitives and types: Request, indication, response, confirmation; service types include local, unconfirmed (one‑to‑many), and confirmed (request/response) services.
• Normative and informative annexes: Annexes A and B are normative (data types/encoding and object dictionary); C–E are informative (implementation guidance, diagnostics, bibliography).

Applications and who uses it

• Targeted at industrial automation: programmable controllers, I/O modules, motion controllers, HMIs, sensors, encoders, valves, and closed‑loop controllers.
• Primary users:
  • Control system integrators and automation engineers implementing CANopen networks.
  • Device manufacturers creating CANopen-compliant hardware and firmware.
  • System architects specifying controller–device interfaces and interoperability requirements.
• Practical benefits: ensures interoperable device profiles, predictable behavior under normal service conditions, and consistent network services for real‑time control.

Related standards

• ISO 11898 (Controller Area Network - CAN)
• EN 50325‑1 (general requirements)
• EN 50081‑2, EN 61000‑6‑2, EN 55011 (EMC references)
• EN 61131‑3 (programmable controller programming languages)

This standard is essential when designing, certifying, or integrating CANopen devices to guarantee consistent controller–device interoperability and predictable performance in industrial environments.

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Industrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces - Part 4: CANopenIndustrielles Kommunikationssubsystem basierend auf ISO 11898 (CAN) -- Teil 4: CANopenSous-système de communications industriel basé sur l'ISO 11898 (CAN) pour les interfaces des dispositifs de commande -- Partie 4: CANopenIndustrial communications subsystem based on ISO 11898 (CAN) for controller-device interfaces -- Part 4: CANopen43.040.15Car informatics. On board computer systems35.240.50Uporabniške rešitve IT v industrijiIT applications in industryICS:Ta slovenski standard je istoveten z:EN 50325-4:2002SIST EN 50325-4:2003en01-julij-2003SIST EN 50325-4:2003SLOVENSKI
STANDARD
EUROPEAN STANDARD
EN 50325-4 NORME EUROPÉENNE EUROPÄISCHE NORM
December 2002 CENELEC European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung
Central Secretariat: rue de Stassart 35, B - 1050 Brussels
© 2002 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 50325-4:2002 E
ICS 43.180
English version
Industrial communications subsystem
based on ISO 11898 (CAN)
for controller-device interfaces Part 4: CANopen
Sous-système de communications industriel basé sur l'ISO 11898 (CAN) pour les interfaces des dispositifs de commande Partie 4: CANopen
Industrielles Kommunikationssubsystem basierend auf ISO 11898 (CAN) Teil 4: CANopen
This European Standard was approved by CENELEC on 2002-07-01. CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the Central Secretariat or to any CENELEC member.
This European Standard exists in one official version (English). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to the Central Secretariat has the same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal, Slovakia, Spain, Sweden, Switzerland and United Kingdom.
The text of the draft was submitted to the Unique Acceptance Procedure and was approved by CENELEC as EN 50325-4 on 2002-07-01. The following dates were fixed:
- latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2003-07-01
- latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2005-07-01 Annexes designated "normative" are part of the body of the standard.
Annexes designated "informative" are given for information only.
In this standard, annexes A and B are normative and annexes C, D and E are informative. This European standard is part of EN 50325 which consists of four parts: Part 1 General requirements Part 2 DeviceNet
Part 3 Smart Distributed System (SDS)
Part 4 CANopen The specifications for DeviceNet,SDS and CANopen are based on ISO 11898 Controller area network (CAN) for high-speed communication, a broadcast-oriented communications protocol. However, ISO 11898 specifies only part of a complete communication system, and additional specifications are needed for other layers to ensure precise data exchange functionality and support of inter-operating devices. General information on licensing and patents Attention is drawn to the possibility that some of the elements of the European Standard EN 50325-4 may be the subject of patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights If during the application of those Standards Intellectual Property Rights may appear and will not be made available on reasonable and non discriminatory terms and conditions to anyone wishing to obtain such a license, applying the rules of CEN/CENELEC Memorandum 8, this fact shall be brought to the attention of CENELEC Central Secretariat for further action. SIST EN 50325-4:2003

- 3 - EN 50325-4:2002
Contents
Page Introduction. 4 1
Scope. 4 2
Normative references. 4 3
Definitions. 4 4
Classifications. 5 5
Characteristics. 12 6
Product information. 64 7
Normal service, transport and mounting conditions. 64 8
Constructional and performance requirements. 65 9
Tests. 67
Annex A (normative) Data types and encoding rules. 68 Annex B (normative) Object dictionary. 75 Annex C (informative) Implementation recommendations. 115 Annex D (informative) Diagnostic information. 115 Annex E (informative) Bibliography. 115
Part 2: Industrial environment EN 61000-6-2 1999 Electromagnetic compatibility (EMC) - Generic standards -
Part 2: Immunity for industrial environments EN 55011 1998 Industrial, scientific and medical (ISM) radio-frequency equipment – Radio disturbance characteristics - Limits and methods of measurement (CISPR 11: 1997, mod.) EN 61000-4 Electromagnetic compatibility (EMC) – Part 4: Testing and measurement techniques EN 61131-3 1993 Programmable controllers – Part 3: Programming languages
(IEC 61131-3:1993) ISO 11898 1993 Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication ISO 646 1991 Information technology - ISO 7-bit coded character set for information interchange ISO 7498-1 1994 Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model ISO 8859 1998 Information technology - 8-bit single-byte coded graphic character sets 3 Definitions For the purpose of EN 50325-4 the definitions of EN 50325-1 and the following apply. 3.1
Automatic Repeat Request (ARQ) scheme used to confirm the transmission of an SDO block 3.2
Node-ID number, uniquely assigned to an NMT (NetworkManagemenT) slave; if 0, the NMT protocols address all NMT slaves SIST EN 50325-4:2003

- 5 - EN 50325-4:2002
4 Classifications 4.1 General Networks compliant to EN 50235-4 shall use the following reference model, device model, and communication model. 4.2 Reference model
Figure 1 – Comparison with OSI reference model The communication concept is described similar to the OSI reference model (left side of Figure 1). 4.2.1 Application layer: The application layer comprises a concept to configure and communicate real-time-data as well as the mechanisms for synchronisation between devices. The functionality the application layer offers to an application is logically divided over different service objects in the application layer. A service object offers a specific functionality and all the related services. These services are described in the Service Specification of that service object. Applications interact by invoking services of a service object in the application layer. To realise these services, this object exchanges data via the CAN network with (a) peer service object(s) via a protocol. This protocol is described in the Protocol Specification of that service object. Application (1)Application Presentation Session Transport Network
Data link
Physical
(2)(2)(1) specified in this European Standard(2) specified in ISO 11898 LLC MAC PLS PMA MDI Application Process SIST EN 50325-4:2003

• A confirmed service may involve only one peer service object. The application issues a request to its local service object. This request is transferred to the peer service object that passes it to the other application as an indication. The other application issues a response that is transferred to the originating service object that passes it as a confirmation to the requesting application.
• A provider initiated service involves only the local service object. The service object (being the service provider) detects an event not solicited by a requested service. This event is then indicated to the application. Unconfirmed and confirmed services are collectively called remote services. SIST EN 50325-4:2003

- 7 - EN 50325-4:2002
4.3 Device model 4.3.1 General A device is modelled as follows (see Figure 3): • communication – This function unit provides the communication objects and the appropriate functionality to transport data items via the underlying network structure; • object dictionary – The Object dictionary is a collection of all the data items which have an influence on the behaviour of the application objects, the communication objects and the state machine used on this device; • application – The application comprises the functionality of the device with respect to the interaction with the process environment. Thus the Object dictionary serves as an interface between the communication and the application. The complete description of a device’s application with respect to the data items in the Object dictionary is named device profile. Figure 3 - Device model 4.3.2 Object dictionary 4.3.2.1 General The most important part of a device profile is the Object dictionary description. The Object dictionary is essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Each object within the dictionary shall be addressed using a 16-bit index. The overall layout of the standard Object dictionary is shown in Table 1. This layout closely conforms to other industrial serial bus system concepts. Application Object dictionary Communication State machineComm. object Comm. object Comm. object Comm. object Application object Entry 1Entry 2Entry n: Application object Application object Application object Process Bus system SIST EN 50325-4:2003

The object dictionary may contain a maximum of 65536 entries which are addressed through a 16-bit index. The Static Data Types at indices 0001h through 001Fh shall contain type definitions for simple data types like boolean, integer, floating point, string, etc. These entries are included for reference only, they shall not be read or written. Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed of simple data types and are common to all devices. Manufacturer Specific Complex Data Types at indices 0040h through 005Fh are structures composed of standard data types but are specific to a particular device.
Device profiles may define additional data types specific to their device type. The static data types defined by the relevant device profile are listed at indices 0060h - 007Fh, the complex ones at indices 0080h - 009Fh. A device may provide the structure of the supported complex data types (indices 0020h - 005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-index 0 then provides the number of entries at this index, and the following sub-indices contain the data type encoded as UNSIGNED16 according to Table B.4. The Communication Profile Area at indices 1000h through 1FFFh shall contain the communication specific parameters for the CAN network. These entries shall be common to all devices. The standardised device profile area at indices 6000h through 9FFFh contains all data objects common to a class of devices that may be read or written via the network. The device profiles may use entries from 6000h to 9FFFh to describe the device parameters and the device functionality. Within this range up to 8 different devices may be described. In such a case the devices are denominated Multiple Device Modules. Multiple Device Modules are composed of up to 8 device profile segments. By this feature it is possible to build devices with multiple functionality. The object entries 6000h to 67FFh of each additional device profiles shall be shifted as follows: - 6000h to 67FFh
for device 0 - 6800h to 6FFFh
for device 1 - 7000h to 77FFh
for device 2 - 7800h to 7FFFh
for device 3 - 8000h to 87FFh
for device 4 - 8800h to 8FFFh
for device 5 - 9000h to 97FFh
for device 6 - 9800h to 9FFFh
for device 7 SIST EN 50325-4:2003

- 9 - EN 50325-4:2002
The PDO distribution shall be used for every segment of a Multiple Device Module with an offset of 64, e.g. the first PDO of the second segment gets the number 65. In this way a system with a maximum of 8 segments is supported. The object dictionary concept caters for optional device features which means a manufacturer does not have to provide certain extended functionality on his devices. However, if he implements this optional functionality, he shall be compliant to definitions given in this European Standard. Space is left in the Object dictionary at indices 2000h through 5FFFh, which may be used for truly manufacturer-specific functionality. 4.3.2.2 Index and sub-Index usage A 16-bit index shall be used to address all entries within the Object dictionary. In case of a simple variable the index references the value of this variable directly. In case of records and arrays, however, the index addresses the whole data structure. To allow individual elements of structures of data to be accessed via the network a sub-index is defined. For single Object dictionary entries such as an UNSIGNED8, BOOLEAN, INTEGER32, etc. the value for the sub-index shall be always zero. For complex Object dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data-structure pointed to by the main index. The fields accessed by the sub-index may be of different data types. 4.4 Communication model 4.4.1 General The communication model specifies the different communication objects and services and the available triggering modes of message transmission. The communication model supports the transmission of synchronous and asynchronous messages. By means of synchronous message transmission a network wide co-ordinated data acquisition and data actuation is possible. The synchronous transmission of messages is supported by pre-defined communication objects (Sync message, time stamp message). Synchronous messages are transmitted with respect to the pre-defined Sync message, asynchronous messages may be transmitted at any time. Due to the event-driven character of the underlying communication mechanism it is possible to define inhibit times for the communication. In order to guarantee that even communication objects with low priorities are transmitted in an appropriate time, communication objects may be assigned an inhibit-time. The inhibit-time of a communication object defines the minimum time that shall elapse between two consecutive invocations of a transmission service for that communication object. Inhibit-times may be assigned by the application. With respect to their functionality, three types of communication relationships are distinguished • master/slave relationship (Figure 4 and Figure 5), • client/server relationship (Figure 6), • producer/consumer relationship (Figure 7 and Figure 8). 4.4.2 Master/slave relationship At any time there is exactly one device in the network serving as a master for a specific functionality. All other devices in the network are considered as slaves. The master issues a request and the addressed slave(s) respond(s) if the protocol requires this behaviour. SIST EN 50325-4:2003

Figure 5 - Confirmed master/slave communication 4.4.3 Client/server relationship This is a relationship between a single client and a single server. A client issues a request (upload/download) thus triggering the server to perform a certain task. After finishing the task the server answers the request. Figure 6 - Client/server communication data Master Slavesrequest indication indication indication data Client Server confirmation response indication request data data Master Slaveconfirmationresponse Remote Transmit Request indication request SIST EN 50325-4:2003

- 11 - EN 50325-4:2002
4.4.4 Producer/consumer relationship - Pull/push model The producer/consumer relationship model involves a producer and zero or more consumer(s). The push model is characterised by an unconfirmed service requested by the producer. The pull model is characterised by a confirmed service requested by the consumer. Figure 7 - Push model
Figure 8 - Pull model 4.5 Data link layer 4.5.1 General Networks compliant to EN 50235-4 shall be implemented on a data link layer and its sub-layers according to ISO 11898. 4.5.2 CAN frame type This specification shall be implemented using CAN standard frames with 11-bit identifier field. It is not required to support the CAN extended frame with 29-bit identifier field. However, as certain applications may require the usage of the extended frame with 29-bit identifier field the network may be operated in this mode, if all nodes support it.
dataProducer Consumers request indication indication indication dataProducer Consumers responseconfirmation Remote Transmit Request request indicationindication request indication request SIST EN 50325-4:2003

The primitives that are defined for a particular service determine the service type (e.g. unconfirmed, confirmed, etc.). How to interpret the tabular form and what service types exist is defined in 4.4 (Communication model). All services assume that no failures occur in the data link and physical layer of the CAN network. These failures are resolved by the application and fall not in the scope of this European Standard. 5.1.2 Process Data Object (PDO) 5.1.2.1 General The real-time data transfer is performed by means of Process Data Objects (PDO). The transfer of PDOs is performed with no protocol overhead. The PDOs correspond to entries in the device Object dictionary and provide the interface to the application objects. Data type and mapping of application objects into a PDO is determined by a corresponding default PDO mapping structure within the Device Object dictionary.
If variable PDO-mapping is supported the number of PDOs and the mapping of application objects into a PDO may be transmitted to a device during the device configuration process (see Initialisation Procedure) by applying the SDO services to the corresponding entries of the Object dictionary. Number and length of PDOs of a device is application specific and shall be specified within the device profile. There are two kinds of use for PDOs. The first is data transmission and the second data reception. It is distinguished in Transmit-PDOs (TPDOs) and Receive-PDOs (RPDOs). Devices supporting TPDOs are PDO producers and devices which are able to receive PDOs are called PDO consumer. The PDO communication parameter (20h) and the PDO mapping parameter (21h) describe PDOs. The structure of these data types are explained in annex A. The PDO communication parameter describes the communication capabilities of the PDO. The PDO mapping parameter contains information about the contents of the PDOs (device variables). The indices of the corresponding Object dictionary entries shall be computed by the following formulas: • RPDO communication parameter index
= 1400h + RPDO-number –1; • TPDO communication parameter index
=
1800h + TPDO-number –1; • RPDO mapping parameter index
= 1600h + RPDO-number –1; • TPDO mapping parameter index
=
1A00h + TPDO-number –1. For each PDO the pair of communication and mapping parameter shall be implemented. The entries mentioned above are described in annex B. 5.1.2.2 Transmission modes The following PDO transmission modes are distinguished: • Synchronous transmission • Asynchronous transmission SIST EN 50325-4:2003

- 13 - EN 50325-4:2002
In order to synchronise devices a synchronisation object (SYNC object) is transmitted periodically by a synchronisation application. The SYNC object is represented by a pre-defined communication object (see 5.1.4). In Figure 9 the principle of synchronous and asynchronous transmission is shown. Synchronous PDOs are transmitted within a pre-defined time-window immediately after the SYNC object. The principle of synchronous transmission is described in more detail in 5.2. SYNCSYNCSYNCSynchronousAsynchronoustimeSynchronousPDOsLengthPDOsObjectWindowObjectObject Figure 9 - Synchronous and asynchronous transmission The transmission type parameter of a PDO specifies the transmission mode as well as the triggering mode.
For synchronous TPDOs the transmission type also specifies the transmission rate in form of a factor based on the basic SYNC-object transmission period. A transmission type of 0 means that the message shall be transmitted after occurrence of the SYNC but acyclic (not periodically), this is if an event occurred before the SYNC. A transmission type of 1 means that the message shall be transmitted with every SYNC object. A transmission type of n means that the message shall transmitted with every n-th SYNC object. Asynchronous TPDOs are transmitted without any relation to a SYNC. The data of synchronous RPDOs received after the occurrence of a SYNC is passed to the application with the occurrence of the following SYNC, independent of the transmission rate specified by the transmission type. The data of asynchronous RPDOs is passed directly to the application.
5.1.2.3 Triggering modes Three message triggering modes are distinguished: • Event driven
Message transmission is triggered by the occurrence of an object specific event. For synchronous PDOs this is the expiration of the specified transmission period, synchronised by the reception of the SYNC object.
For acyclically transmitted synchronous PDOs and asynchronous PDOs the triggering of a message transmission is a device-specific event specified in the device profile. • Timer driven
Message transmission is either triggered by the occurrence of a device-specific event or if a specified time has elapsed without occurrence of an event. • Remotely requested Transmission of an asynchronous PDO is initiated on receipt of a remote request initiated by any other device (PDO consumer).
5.1.2.4.2 Write PDO For the Write PDO service the push model is valid. There are zero or more consumers of a PDO. A PDO shall have exactly one producer.
Through this service the producer of a PDO sends the data of the mapped application objects to the consumer(s) (see Table 2). Table 2 - Write PDO Parameter Request / Indication Argument PDO Number Data
Mandatory1 mandatory mandatory
1 Mandatory attributes shall be implemented
5.1.2.4.3 Read PDO For the Read PDO service the pull model is valid. There are one or more consumers of a PDO. A PDO shall have exactly one producer. Through this service the consumer of a PDO requests the producer to supply the data of the mapped application objects (see Table 3). The service is confirmed. The remote result parameter will confirm the value. Table 3 - Read PDO Parameter Request / Indication Response / Confirm
Argument PDO Number
Remote Result Data
Mandatory mandatory
Mandatory mandatory
- 15 - EN 50325-4:2002
5.1.2.5 PDO protocol 5.1.2.5.1 Write PDO protocol The service for a PDO write request is unconfirmed. The PDO producer sends the process data within a PDO to the network. There may be 0.n PDO consumers. At the PDO consumer(s) the reception of a valid PDO is indicated. Figure 10 shows the Write PDO Protocol. Figure 10 - Write PDO protocol
Process-Data: up to L bytes of application data according to the PDO mapping If L exceeds the number of bytes ‘n’ defined by the actual PDO mapping length only the first ‘n’ bytes shall be used by the consumer. If L is less than ‘n’ the data of the received PDO shall not be processed and an Emergency message with error code 8210h shall be produced if Emergency is supported. 5.1.2.5.2 Read PDO protocol The service for a PDO read request is confirmed. One or more PDO consumer transmit a remote transmission request frame (RTR) to the network. At the reception of the RTR frame the PDO producer of the requested PDO transmits the PDO. At all PDO consumers for this PDO the reception is indicated. There may be 0.n PDO consumers. The read service depends on the hardware capabilities. Figure 11 shows the Read PDO Protocol.
Figure 11 - Read PDO Protocol Process-Data: up to L bytes of application data according to the PDO mapping If L exceeds the number of bytes ‘n’ defined by the actual PDO mapping length only the first ‘n’ bytes shall be used by the consumer. If L is less than ‘n’ the data of the received PDO shall not be processed and an emergency message with error code 8210h shall be produced if emergency is supported. Process Data PDO
Producer PDO
Consumersresponse confirmation 0 L (0 ≤ L ≤ 8) Read PDO Remote Transmit Request request Indication Process Data PDO
Producer PDO
ConsumersRequest IndicationIndicationIndication 0 L (0 ≤ L ≤ 8) Write PDO SIST EN 50325-4:2003

For the block transfer a Go-Back-n ARQ (Automatic Repeat Request) scheme is used to confirm each block. After block download the server indicates the client the last successfully received segment of this block transfer by acknowledging this segment sequence number. Doing this the server implicitly acknowledges all segments preceding this segment. The client starts the following block transfer with the retransmission of all not acknowledged data. Additionally the server shall indicate the number of segments per block for the next block transfer. After block upload the client indicates the server the last successfully received segment of this block transfer by acknowledging this segment sequence number. Doing this the client implicitly acknowledges all segments preceding this segment. The server shall start the following block transfer with the retransmission of all not acknowledged data. Additionally the client shall indicate the number of segments per block for the next block transfer.
For all transfer types it is the client that takes the initiative for a transfer. The owner of the accessed Object dictionary is the server of the SDO. Either client or server may take the initiative to abort the transfer of a SDO.
By means of an SDO a peer-to-peer communication channel between two devices is established. A device may support more than one SDO. One supported Server-SDO (SSDO) is the default case (Default SDO). SDOs shall be described by the SDO communication parameter record (22h).The structure of this data type is given in annex A. The SDO communication parameter describes the communication capabilities of the Server-SDOs and Client-SDOs (CSDO). The indices of the corresponding Object dictionary entries shall be computed by the following formulas: • SSDO communication parameter index
= 1200h + SSDO-number –1; • CSDO communication parameter index
=
1280h + CSDO-number –1. For each SDO the communication parameters shall be implemented. If only one SSDO exists the communication parameters may be omitted. The entries mentioned above are described in annex B. SIST EN 50325-4:2003

- 17 - EN 50325-4:2002
5.1.3.2 SDO services 5.1.3.2.1 General The model for the SDO communication shall be the client/server model as described in 4.4.3. Attributes: - SDO number: SDO number [1.128] for every user type on the local device - user type: one of the values {client, server} - mux data type: multiplexor containing index and sub-index of type
STRUCTURE OF UNSIGNED (16),
UNSIGNED (8) ,
with index specifying an entry of the device object
dictionary and "sub-index" specifying a component of a
device object dictionary entry - transfer type:
depends on the length of data to transfer:
expedited for up to 4 data bytes
segmented or block for more than 4 data bytes - data type: according to the referenced index and sub-index
The following services may be applied to an SDO depending on the application requirements: • SDO Download, which may be split up into - Initiate SDO Download, - Download SDO Segment. • SDO Upload, which may be split up into
- Initiate SDO Upload, - Upload SDO Segment. • Abort SDO Transfer
When using the segmented SDO download and upload services, the communication software will be responsible for transferring the SDO as a sequence of segments. Expedited transfer shall be supported. Segmented transfer shall be supported if objects larger than 4 bytes are supported. The following SDO services for doing a block transfer with higher bus utilisation and performance for a large data set size may be implemented: • SDO Block Download, which my be split up into - Initiate Block Download, - Download Block, - End Block Download. • SDO Block Upload, which may be split up into
- Initiate Block Upload, - Upload Block, - End Block Upload. When using the SDO block download and upload services, the communication software will be responsible for transferring the data as a sequence of blocks. In SDO Block Upload Protocol a support for a switch to SDO Upload Protocol in ‘Initiate SDO Block Upload’ may be implemented to increase transfer performance for data which size does not justifies using the protocol overhead of the ‘SDO Block Upload’ protocol. For aborting an SDO block transfer the Abort SDO Transfer Service is used. SIST EN 50325-4:2003

The service is confirmed. The remote result parameter will indicate the success or failure of the request. In case of a failure, the reason may be confirmed. The SDO download shall consist of at least the Initiate SDO Download service and may consist of Download SDO Segment services (data length > 4 bytes). Table 4 - SDO Download Parameter Request / Indication Response / Confirm
Argument
SDO Number
Data
Size
Multiplexor
Remote Result
Success
Failure
Reason
Mandatory
mandatory
mandatory
optional 1
mandatory
Mandatory
selection
selection
optional 1 Optional attributes may be implemented
5.1.3.2.3 Initiate SDO download Through this service the client of SDO requests the server to prepare for downloading data to the server (see Table 5). The size of the data to be downloaded may be indicated to the server. The multiplexor of the data set whose download is initiated and the transfer type are indicated to the server. In case of an expedited download, the data of the data set identified by the multiplexor and size is indicated to the server. SIST EN 50325-4:2003

- 19 - EN 50325-4:2002
Table 5 - Initiate SDO Download Parameter Request / Indication Response / Confirm
Argument
SDO Number
Size
Multiplexor
Transfer type
Normal
Expedited
Data
Remote Result
Success
Mandatory
mandatory
optional
mandatory
mandatory
selection
selection
mandatory
Mandatory
mandatory
The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO Transfer request shall be executed. In the case of a successful expedited download of a multiplexed DOMAIN, this service concludes the download of the data set identified by the multiplexor. 5.1.3.2.4 Download SDO segment Through this service the client of a SDO supplies the data of the next segment to the server (see Table 6). The segment data shall be and its size may be indicated to the server. The continue parameter indicates the server whether there are still more segments to be downloaded or that this was the last segment to be downloaded. Table 6 - Download SDO Segment Parameter Request / Indication Response / Confirm
Argument
SDO number
Data
Size
Continue
More
Last
Remote Result
Success
Mandatory
mandatory
mandatory
optional
mandatory
selection
selection
Mandatory
mandatory
The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO transfer request shall be executed. In case of success, the server has accepted the segment data and is ready to accept the next segment. There may be at most one Download SDO Segment service outstanding for an SDO transfer. SIST EN 50325-4:2003

The SDO upload shall consist of at least the Initiate SDO Upload service and may consist of Upload SDO Segment services (data length > 4 bytes). Table 7 - SDO Upload Parameter Request / Indication Response / Confirm
Argument
SDO number
Multiplexor
Remote Result
Success
Data
Size Failure
Reason
Mandatory
mandatory
mandatory
Mandatory
selection
mandatory
optional
selection
optional
The service is confirmed. The remote result parameter will indicate the success or failure of the request. In case of a failure, the reason may be confirmed. In case of success, the data shall be confirmed and its size (for segmented transfer) may be confirmed. 5.1.3.2.6 Initiate SDO upload Through this service the client of a SDO requests the server to prepare for uploading data to the client. The multiplexor (index and sub-index) of the data set whose upload is initiated is indicated to the server (see Table 8). The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO Transfer request shall be executed. In the case of success, the size (for segmented transfer) of the data to be uploaded may be confirmed. In case of successful expedited upload, this service shall conclude the upload of the data set identified by multiplexor and the corresponding data shall be confirmed. SIST EN 50325-4:2003

- 21 - EN 50325-4:2002
Table 8 - Initiate SDO Upload Parameter Request / Indication Response / Confirm
Argument
SDO number
Multiplexor
Remote Result
Success
Size Multiplexor
Transfer type
Normal
Expedited
Data
Mandatory
mandatory
mandatory
Mandatory
mandatory
optional
mandatory
mandatory
selection
selection
mandatory
5.1.3.2.7 Upload SDO segment Through this service the client of a SDO requests the server to supply the data of the next segment (see Table 9). The continue parameter indicates the client whether there are still more segments to be uploaded or that this was the last segment to be uploaded. There may be at most one Upload SDO Segment service outstanding for a SDO. The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO Transfer request shall be executed. In case of success, the segment data shall be and its size may be confirmed. A successful Initiate SDO Upload service with segmented transfer type shall have been executed prior to this service. Table 9 - Upload SDO Segment Parameter Request / Indication Response / Confirm
Argument
SDO number
Remote Result
Success
Data
Size
Continue
More
Last
Mandatory
mandatory
Mandatory
mandatory
mandatory
optional
mandatory
selection
selection
This service aborts the up- or download of a SDO referenced by its number (see Table 10). The reason may be indicated. The service is unconfirmed. Both the client and the server of a SDO may execute the service at any time. If the client of an SDO has a confirmed service outstanding, the indication of the abort is taken to be the confirmation of that service. Table 10 - Abort SDO Transfer Parameter Request / Indication
Argument
SDO number
Multiplexor
Reason
Mandatory
mandatory
mandatory
mandatory
5.1.3.2.9 SDO block download Through this service the client of SDO downloads data to the server of the SDO (owner of the Object dictionary) using the block download protocol (see Table 11). The data, the multiplexor (index and sub-index) of the data set that has been downloaded shall be indicated to the server and its size may be indicated as well.
The service is confirmed. The remote result parameter will indicate the success or failure of the request. In case of a failure, the reason may be confirmed. Table 11 - SDO Block Download Parameter Request / Indication Response / Confirm
Argument
SDO Number
Data
Size
Multiplexor
Remote Result
Success
Failure
Reason
Mandatory
mandatory
mandatory
optional
mandatory
Mandatory
selection
selection
optional
5.1.3.2.10 Initiate SDO block download Through this service the client of SDO requests the server of SDO (owner of the Object dictionary) to prepare for downloading data to the server (see Table 12). The multiplexor of the data set whose download is initiated shall be and the size of the downloaded data in bytes may be indicated to the server.
The client as well as the server indicating their ability and/or demand to verify the complete transfer with a checksum in End SDO Block Download. SIST EN 50325-4:2003

- 23 - EN 50325-4:2002
Table 12 - Initiate SDO Block Download Parameter Request / Indication Response / Confirm
Argument SDO Number Size CRC ability yes no Multiplexor
Remote Result Success CRC ability yes no Blksize
Mandatory mandatory optional mandatory selection selection mandatory
Mandatory mandatory mandatory selection selection mandatory
The se
...