Beckhoff CX-M510 Series User manual

AS2000
Blindtext Blindtext Blindtext
Manual | EN
CXxxxx-M510/B510
CANopen Optional Interface for CX9020, CX5xx0 and CX20xx
2/9/2021 | Version: 1.0

Table of contents
CXxxxx-M510/B510 3Version: 1.0
Table of contents
1 Foreword ....................................................................................................................................................5
1.1 Notes on the documentation..............................................................................................................5
1.2 Safety instructions .............................................................................................................................6
1.3 Documentation issue status ..............................................................................................................7
2 CANopen system overview ......................................................................................................................8
2.1 Network Management .....................................................................................................................10
2.1.1 Boot-up message............................................................................................................. 12
2.1.2 Node Monitoring .............................................................................................................. 12
2.1.3 Process Data Objects (PDO)........................................................................................... 14
2.1.4 Service Data Objects (SDO)............................................................................................ 18
2.2 Technical Data - CANopen..............................................................................................................23
3 Connection and cabling..........................................................................................................................24
3.1 CANopen connection.......................................................................................................................24
3.2 Cabling ............................................................................................................................................25
3.3 Topology..........................................................................................................................................30
4 TwinCAT tabs...........................................................................................................................................31
4.1 Tree view .........................................................................................................................................31
4.2 CANopen master .............................................................................................................................33
4.2.1 General ............................................................................................................................ 33
4.2.2 FC 51xx ........................................................................................................................... 34
4.2.3 ADS ................................................................................................................................. 35
4.3 CANopen slave................................................................................................................................36
4.3.1 CAN node ........................................................................................................................ 36
4.3.2 SDOs ............................................................................................................................... 38
4.3.3 PDO ................................................................................................................................. 39
5 Parameterization and commissioning...................................................................................................40
5.1 PDO Parameterization.....................................................................................................................40
5.2 Parameterization with TwinCAT 2 ...................................................................................................43
5.2.1 Searching for target systems ........................................................................................... 43
5.2.2 Add CANopen slave ........................................................................................................ 45
5.2.3 Creating a virtual slave .................................................................................................... 46
5.2.4 Setting the address.......................................................................................................... 47
5.2.5 Creating further PDOs ..................................................................................................... 48
5.2.6 Creating variables............................................................................................................ 49
5.2.7 Setting the transmission type........................................................................................... 50
5.2.8 Creating a PLC project .................................................................................................... 51
5.2.9 Linking variables .............................................................................................................. 53
5.2.10 Load configuration to CX ................................................................................................. 54
5.2.11 Adding a CANopen master ............................................................................................. 56
5.3 Parameterization with TwinCAT 3 ...................................................................................................58
5.3.1 Searching for target systems ........................................................................................... 58
5.3.2 Add CANopen slave ........................................................................................................ 60
5.3.3 Creating a virtual slave .................................................................................................... 61

Table of contents
CXxxxx-M510/B5104 Version: 1.0
5.3.4 Setting the address.......................................................................................................... 62
5.3.5 Creating further PDOs ..................................................................................................... 63
5.3.6 Creating variables............................................................................................................ 64
5.3.7 Setting the transmission type........................................................................................... 65
5.3.8 Creating a PLC project .................................................................................................... 66
5.3.9 Linking variables .............................................................................................................. 68
5.3.10 Load configuration to CX ................................................................................................. 69
5.3.11 Adding a CANopen master ............................................................................................. 71
6 Error handling and diagnostics..............................................................................................................73
6.1 Diagnostic LEDs ..............................................................................................................................73
6.2 Status messages .............................................................................................................................74
6.3 Communication................................................................................................................................75
6.4 PDOs ...............................................................................................................................................76
7 Appendix ..................................................................................................................................................77
7.1 Accessories .....................................................................................................................................77
7.2 Certifications....................................................................................................................................78
7.3 Support and Service ........................................................................................................................79

Foreword
CXxxxx-M510/B510 5Version: 1.0
1 Foreword
1.1 Notes on the documentation
This description is only intended for the use of trained specialists in control and automation engineering who
are familiar with the applicable national standards.
It is essential that the documentation and the following notes and explanations are followed when installing
and commissioning the components.
It is the duty of the technical personnel to use the documentation published at the respective time of each
installation and commissioning.
The responsible staff must ensure that the application or use of the products described satisfy all the
requirements for safety, including all the relevant laws, regulations, guidelines and standards.
Disclaimer
The documentation has been prepared with care. The products described are, however, constantly under
development.
We reserve the right to revise and change the documentation at any time and without prior announcement.
No claims for the modification of products that have already been supplied may be made on the basis of the
data, diagrams and descriptions in this documentation.
Trademarks
Beckhoff®, TwinCAT®, EtherCAT®, EtherCAT P®, Safety over EtherCAT®, TwinSAFE®, XFC® and XTS® are
registered trademarks of and licensed by Beckhoff Automation GmbH.
Other designations used in this publication may be trademarks whose use by third parties for their own
purposes could violate the rights of the owners.
Patent Pending
The EtherCAT Technology is covered, including but not limited to the following patent applications and
patents:
EP1590927, EP1789857, DE102004044764, DE102007017835
with corresponding applications or registrations in various other countries.
The TwinCAT Technology is covered, including but not limited to the following patent applications and
patents:
EP0851348, US6167425 with corresponding applications or registrations in various other countries.
EtherCAT® is registered trademark and patented technology, licensed by Beckhoff Automation GmbH,
Germany
Copyright
© Beckhoff Automation GmbH & Co. KG, Germany.
The reproduction, distribution and utilization of this document as well as the communication of its contents to
others without express authorization are prohibited.
Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a
patent, utility model or design.

Foreword
CXxxxx-M510/B5106 Version: 1.0
1.2 Safety instructions
Safety regulations
Please note the following safety instructions and explanations!
Product-specific safety instructions can be found on following pages or in the areas mounting, wiring,
commissioning etc.
Exclusion of liability
All the components are supplied in particular hardware and software configurations appropriate for the
application. Modifications to hardware or software configurations other than those described in the
documentation are not permitted, and nullify the liability of Beckhoff Automation GmbH & Co. KG.
Personnel qualification
This description is only intended for trained specialists in control, automation and drive engineering who are
familiar with the applicable national standards.
Description of symbols
In this documentation the following symbols are used with an accompanying safety instruction or note. The
safety instructions must be read carefully and followed without fail!
DANGER
Serious risk of injury!
Failure to follow the safety instructions associated with this symbol directly endangers the life and health of
persons.
WARNING
Risk of injury!
Failure to follow the safety instructions associated with this symbol endangers the life and health of per-
sons.
CAUTION
Personal injuries!
Failure to follow the safety instructions associated with this symbol can lead to injuries to persons.
NOTE
Damage to the environment or devices
Failure to follow the instructions associated with this symbol can lead to damage to the environment or
equipment.
Tip or pointer
This symbol indicates information that contributes to better understanding.

Foreword
CXxxxx-M510/B510 7Version: 1.0
1.3 Documentation issue status
Version Modifications
1.0 First version

CANopen system overview
CXxxxx-M510/B5108 Version: 1.0
2 CANopen system overview
The Beckhoff Embedded PCs can be ordered ex works with an optional interface, e.g. PROFIBUS,
CANopen or RS232. Some of the optional interfaces can be delivered as master or slave.
The following Embedded PCs can be ordered with an optional interface:
• CX9020
• CX50x0
• CX51x0
• CX20x0
CANopen master (M510)
The optional interface M510 is a CANopen master and enables a segment-like construction of control
structures in large plants and machines. Further Beckhoff fieldbus components such as Bus Couplers, Bus
Terminal Controllers, drive components, etc. can be used with an Embedded PC for configuring control
structures.
Fieldbus masters are used for decentralized collection of process data and signals in large machines and
plants. The number of slaves that can be connected to the master is only limited by the respective bus
system. Using master and slave connections makes it possible to link several Embedded PCs with each
other via the fieldbus level.
The optional interfaces are detected, parameterized and configured in TwinCAT, and the connected I/O
components are added. TwinCAT is also used for diagnostics.
CANopen slave (B510)
The optional interface B510 is a CANopen slave and enables an Embedded PC to be used as subordinate
decentral controller for configuring complex or modular systems.
The CANopen slave receives external process data from the master and processes them or returns data
from its own process periphery to the master after processing.
Like the CANopen master, the optional CANopen slave interface is parameterized and configured in
TwinCAT.
Functioning
CANopen is a widely used fieldbus system, which was developed by the CAN in Automation (CiA)
association and in the meantime has been adopted for international standardization.
Further Information
CAN in Automation (CiA) website:
www.can-cia.org
CANopen consists of the protocol definition (communication objects) and the device profiles.
The protocol definition includes the following communication objects:
• Network Management (NMT)

CANopen system overview
CXxxxx-M510/B510 9Version: 1.0
• Process Data Objects (PDO)
• Service Data Objects (SDO)
• And protocols with special functions
The device profiles standardize the data content for the respective device class. The term device class
covers devices such as electric drives, I/O modules, sensors and controllers. The device profiles define the
functionality and the structure of the object directory.
The device parameters and process data are stored in a structured object directory. Any data in this object
directory is accessed via service data objects (SDO).
Process data objects (PDO) are used for fast communication of input and output data. There are,
additionally, a few special objects (such as telegram types) for network management (NMT),
synchronization, error messages and so on.
Communication Types
CANopen defines several communication types for process data objects:
• Event driven:
Telegrams are sent as soon as their contents have changed. This means that the process image as a
whole is not continuously transmitted, only its changes.
• Cyclic synchronous:
A SYNC telegram causes the modules to accept the output data that was previously received, and to
send new input data.
• Requested (polled):
A CAN data request telegram causes the modules to send their input data.
The required communication type is set via the transmission type parameter (see: PDO [}39] tab).
Bus access procedures
CAN operates based on the Carrier Sense Multiple Access (CSMA) method, i.e. all devices have equal
rights and access the bus as soon as it is free (multi-master bus access). The exchange of messages is thus
not device-oriented but message-oriented. This means that every message is unambiguously marked with a
prioritized identifier.
In order to avoid collisions on the bus when messages are sent by different devices, a bit-wise bus
arbitration is carried out at the start of the data transmission. The bus arbitration allocates bus bandwidth to
the messages in order of priority. At the end of the arbitration phase only one bus devices occupies the bus;
collisions are avoided, and the bandwidth is optimally utilized.
Configuration and parameterization
The TwinCAT System Manager allows all the CANopen parameters to be set conveniently. An "eds" file (an
electronic data sheet) is available on the Beckhoff website (www.beckhoff.de) for the parameterization of
Beckhoff CANopen devices using configuration tools from other manufacturers.
Certification
The Beckhoff CANopen devices have a powerful implementation of the protocol, and are certified by the
CAN in Automation Association (www.can-cia.org).

CANopen system overview
CXxxxx-M510/B51010 Version: 1.0
2.1 Network Management
The network management (NMT) defines the communication behavior of a CANopen device and consists of
the states initialization, pre-operational, operational and stopped.
When a device is switched on or restarted, the device automatically switches to the initialization state. When
the initialization state is completed, the device automatically switches to pre-operational state.
From this state any other state can be assumed. For sample, only a single CAN message is required to
make the devices start:
Start_Remote_Node: Identifier 0, two data bytes: 0x01, 0x00.
This message transfers the devices to the operational state.
The following diagram shows which states a CANopen device can assume:
•Initialization
The device automatically switches to the initialization state. When the initialization state is completed,
the device automatically switches to pre-operational state.
•Pre-Operational
After the initialization the device automatically switches to pre-operational state, i.e. without an external
command. In this state the service data objects (SDO) are already active, and the device can be
configured. The process data objects (PDO) are still locked.
•Operational
In operational state the process data objects (PDO) are active.
If the device is no longer able to set outputs, read inputs or communicate due to external influences
(e.g. CAN fault, no output voltage) or internal influences (e.g. K-bus error), it tries to send a
corresponding emergency message. The device then assumes error state and switches back to pre-
operational state. This enables the NMT status machine of the master to detect fatal errors
immediately.
•Stopped
In stopped state (previously prepared) no communication with the device is possible. Only network
management (NMT) messages are received. The outputs go into the fault state.

CANopen system overview
CXxxxx-M510/B510 11Version: 1.0
State transitions
State transitions are executed with a CAN message. The CAN messages have a very simple structure:
CAN identifier 0, with two bytes of data content.
• The first data byte contains the command specifier (cs),
• the second data byte contains the node address (node ID); node address 0 addresses all nodes
(broadcast).
11 bit identifier 2 byte of user data
0x00 cs Node ID
The following table provides an overview of all possible state transitions and the corresponding command
specifiers (cs). The diagram shown above, which illustrates the states, is part of the overview:
State transition Command Specifier cs Explanation
(1) -- The initialization state is reached
automatically at power-up
(2) -- After initialization the pre-
operational state is reached
automatically - this involves
sending the boot-up message.
(3), (6) cs = 1 = 0x01 Start_Remote_Node.
Starts the device, enables outputs
and starts the PDO transfer.
(4), (7) cs = 128 = 0x80 Enter_Pre-Operational.
Stops the PDO transmission, SDO
still active.
(5), (8) cs = 2 = 0x02 Stop_Remote_Node.
Outputs go into the fault state,
SDO and PDO switched off.
(9) cs = 129 = 0x81 Reset_Node.
Carries out a reset. All objects are
reset to their power-on defaults.
(10) cs = 130 = 0x82 Reset_Communication.
Carries out a reset of the
communication functions. Objects
0x1000 - 0x1FFF are reset to their
power-on defaults.
Sample 1
The following telegram puts all the modules in the network into the error state (outputs in a safe state):
11 bit identifier 2 byte of user data
0x00 0x02 0x00
Sample 2
The following telegram is used to reset (restart) node 17:
11 bit identifier 2 byte of user data
0x00 0x81 0x11

CANopen system overview
CXxxxx-M510/B51012 Version: 1.0
2.1.1 Boot-up message
After the initialization phase and the self-test the device sends the boot-up message, which is a CAN
message with a data byte (0) on the identifier of the guarding or heartbeat message:
CAN-ID = 0x700 + node ID.
In this way temporary failure of a module during operation (e.g. due to a voltage interruption), or a module
that is switched on at a later stage, can be reliably detected, even without Node Guarding. The sender can
be determined from the message identifier (see default identifier allocation).
It is also possible, with the aid of the boot-up message, to recognize the nodes present in the network at
start-up with a simple CAN monitor, without having to make write access to the bus (such as a scan of the
network by reading out parameter 0x1000).
Finally, the boot-up message communicates the end of the initialization phase. The device indicates that it
can now be configured or started.
Format of the Boot-up message
11 bit identifier 2 byte of user data
0x700 (=1792)+
node ID
0x00
2.1.2 Node Monitoring
The heartbeat and guarding mechanisms are available for monitoring CANopen device failures. These
mechanisms are particularly important for CANopen, since in the event-driven operating mode the devices
do not report on a regular basis. In the case of "guarding", the devices are cyclically interrogated about their
status by means of a data request telegram (remote frame), whereas with "heartbeat" the nodes transmit
their status on their own initiative.
Guarding: Node Guarding and Life Guarding
Node guarding is used to monitor the slaves, which themselves use life guarding to detect a faulty guarding
master.
Node guarding involves the master issuing request telegrams, referred to as remote frames (remote transmit
requests) to the guarding identifiers of the slaves to be monitored. The slaves respond with a guarding
message. The message contains the node state of the slave and toggle bit, which has to change after each
message. If the node state or the toggle bit do not match the values expected by the master or if there is a
general lack of response, the master assumes an error.

CANopen system overview
CXxxxx-M510/B510 13Version: 1.0
At the time of the first guarding message of the slave the toggle bit has the value 0. Subsequently, the toggle
bit alternates after each guarding message and enables lost messages to be detected. The remaining seven
bits contain the node state, thereby transferring the slave status to the master.
Node State Status
4 = 0x04 Stopped
5 = 0x05 Operational
127 = 0x7F Pre-Operational
Sample
The guarding message for node 27 (0x1B) must be requested by a remote frame having identifier 0x71B
(1819dec). If the node is Operational, the first data byte of the answer message alternates between 0x05 and
0x85, whereas in the Pre-Operational state it alternates between 0x7F and 0xFF.
Guard time and life time factor
If the master requests the guard messages in a strict cycle, the slave can detect the failure of the master. In
this case, if the slave fails to receive a message request from the master within the set Node Life Time (a
guarding error), the slave assumes that the master has failed (the watchdog function).
In this case the slave sets its outputs to error state, sends an emergency telegram and returns to pre-
operational state. After a guarding time-out the procedure can be triggered again with a new guarding
message.
The node life time is calculated based on the following parameters:
• guard time (object 0x100C) and
• life-time factor (object 0x100D)
Life time = guard time x life time factor
If one of the two parameters is 0 (default), the master is not monitored (no life guarding) (see: CAN node
[}36] tab).
Heartbeat: Node Monitoring without Remote Frame
If the heartbeat method is active, the devices automatically send their respective status messages cyclically.
In contrast to the guarding method, the heartbeat method does not involve sending of remote frames,
resulting in less bus load. The master also sends its heartbeat telegram cyclically, enabling the slaves to
detect a master failure (see: CAN node [}36] tab).
The toggle bit is not used with the heartbeat method, and the devices send their respective status cyclically.

CANopen system overview
CXxxxx-M510/B51014 Version: 1.0
2.1.3 Process Data Objects (PDO)
In many fieldbus systems the entire process image is continuously transferred - usually in a more or less
cyclic manner. CANopen is not limited to this communication principle, since with CANopen the process data
are transferred based on the producer/consumer model. It means that a device sends its process data
spontaneously (producer), while all other devices listen and use a CAN identifier to decide whether the
telegram is of interest for them, in which case they process it accordingly (consumer).
The process data in CANopen is divided into segments with a maximum of 8 bytes. These segments are
known as process data objects (PDOs). The process data objects (PDOs) each correspond to a CAN
telegram. They are allocated and prioritized based on a specific CAN identifier.
The process data objects (PDOs) are subdivided into receive PDOs (RxPDOs) and send PDOs (TxPDOs);
the ID is based on the device perspective. A device sends its input data with TxPDOs and receives the
output data in the RxPDOs.
This designation is retained in TwinCAT.
Communication parameters
The process data objects (PDOs) can be assigned different communication parameters, as required. Like all
CANopen parameters, these are also listed in the object directory of the device. The communication
parameters can be accessed via service data objects (SDOs).
The parameters for the receive PDOs are contained in index 0x1400 (RxPDO1) to 0x15FF (RxPDO512),
which means up to 512 RxPDOs can exist. In the same way, the entries for the transmit PDOs are located
from index 0x1800 (TxPDO1) to index 0x19FF (TxPDO512).
For each existing process data object (PDO) there is an associated communication parameter object.
TwinCAT automatically assigns the set parameters to the relevant object directory entries. These entries and
their significance for the communication of process data are explained below.
CAN identifier
The main communication parameter for process data objects (PDOs) is the CAN identifier (also referred to a
communication object identifier, COB ID). The CAN identifier is used to identify the CAN telegrams and
determines their priority for bus access. For each CAN telegram there can only be one sender (producer).
However, since CAN sends all messages based on the broadcast method, a telegram can be received by
any number of devices (consumers), as described. In other words, a device can make its input information
available to several devices at the same time, even without transfer by a logical master.
The CAN identifier is contained in subindex 1 of the communication parameter set. It is coded as a 32-bit
value in which the least significant 11 bits (bits 0...10) contain the CAN identifier itself. The 32-bit object data
width enables 29-bit CAN identifiers to be entered. The use of the 29-bit version is limited to special
applications and is therefore not supported by the Beckhoff CANopen devices. The highest bit (bit 31) can be
used to activate the process data object or to turn it off.
PDO linking
By default all devices (slaves) communicate with a central controller (master). By default no slave listens to
the process data objects (PDOs) and therefore the CAN identifiers of another slave.
Standard communication between several slaves and a master:

CANopen system overview
CXxxxx-M510/B510 15Version: 1.0
To exchange process data objects (SDOs) directly between the devices without a master, the CAN
identifiers have to be adjusted accordingly. The TxPDO identifiers of the producer must match the RxPDO
identifier of the consumer. This procedure is known as PDO linking. It permits, for sample, easy construction
of electronic drives in which several slave axes simultaneously listen to the actual value in the master axis
TxPDO.
Communication without master based on PDO linking:
PDO transmission types
CANopen offers following options for transferring process data objects (PDOs):
• Event driven
• By polling
• Synchronized
•Event driven:
If an input value changes, a device immediately transfers its process data objects (PDOs). This
enables optimum utilization of the transmission bandwidth, since only the change in the process image
is transferred, while the response time is short, since the devices do not wait for a query from a master
if the input values change.

CANopen system overview
CXxxxx-M510/B51016 Version: 1.0
As from CANopen Version 4 it is possible to combine the event driven type of communication with a
cyclic update. The process data objects (in this case the TxPDOs) are then transferred once a set time
(event timer) has elapsed. If an input value changes within the set time, the time (event timer) is reset.
With RxPDOs the set time (event timer) is used to monitor the arrival of the event-driven process data
objects (PDOs). A device switches to error state, if no process data objects (PDOs) arrived within the
set time.
•Polled:
The process data objects (PDOs) are polled through request telegrams (remote frames). In this way
the process data objects (PDOs) are transferred even if there is no change, for sample if a monitor or
diagnostic device is included in the network at runtime.
Function blocks with integrated full message filtering (FullCAN) usually respond to a request telegram
directly and immediately send the data contained in the corresponding send buffer. The application
must ensure that the data are continuously updated. CAN controllers with simple message filtering
(BasicCAN) on the other hand pass the request on to the application which can now compose the
telegram with the latest data. This does take longer, but does mean that the data is up-to-date.
Beckhoff use CAN controllers following the principle of Basic CAN.
Since this device behavior is usually not transparent to the user, and because there are CAN
controllers still in use that do not support remote frames at all, polled communication will only with
reservation be recommended for operative running.
•Synchronized
It is not only for drive applications that it is worthwhile to synchronize the determination of the input
information and the setting the outputs. For this purpose CANopen provides the SYNC object, a CAN
telegram of high priority but containing no user data, whose reception is used by the synchronized
users as a trigger for reading the inputs or for setting the outputs.
PDO transmission types: Parameterization
The PDO transmission type determines how the transfer of the process data objects (PDOs) is triggered and
how the received process data objects (PDOs) are treated:
Transmission
type
Cyclical Acyclical Synchronous Asynchronous
0 X X
1-240 X X
254, 255 X
The type of transmission is parameterized for RxPDOs in the objects at 0x1400ff, sub-index 2, and for
TxPDOs in the objects at 0x1800ff, sub-index 2. In TwinCAT the PDO transmission type is set on the PDO
tab under Transmission Type (see: PDO [}39] tab).
•Acyclic Synchronous:
PDOs of transmission type 0 function synchronously, but not cyclically. An RxPDO is only evaluated
after the next SYNC telegram. In this way, for instance, axis groups can be given new target positions
one after another, but these positions only become valid at the next SYNC - without the need to be
constantly outputting reference points.
In contrast, a TxPDO determines its input data after a SYNC telegram (synchronous process image)
and forwards its input data if the input data have changed.
Transmission type 0 therefore combines the send reason „synchronized“ with the send reason “event-
driven”.
•Cyclic Synchronous:
With transmission types 1-240 the PDO is sent cyclically after each n-th SYNC (n=1...240). In this way
it is possible to parameterise a fast cycle for digital inputs (n=1), for sample, while the data of the
analog inputs are transferred in a slower cycle (e.g. n=10). RxPDOs generally do not differentiate
between the transmission types 0...240. A received PDO is set to valid with the next SYNC telegram.

CANopen system overview
CXxxxx-M510/B510 17Version: 1.0
The cycle time (SYNC rate) can be monitored (object 0x1006), so that if the SYNC fails the device
reacts in accordance with the definition in the device profile, and switches, for sample, its outputs into
the fault state.
The SYNC telegram is coupled with the link task, so that new input data are available with each task
start. If a synchronous PDO fails to materialize, this is detected and reported to the application.
•Asynchronous:
The transmission types 254 + 255 are asynchronous or event-driven. In transmission type 254, the
event is specific to the manufacturer, whereas for type 255 it is defined in the device profile. In the
simplest case, the event is the change of an input value - this means that every change in the value is
transmitted. The asynchronous transmission type can be coupled with the event timer, thus also
providing input data when no event has just occurred. Once the set time has elapsed, this is interpreted
as an additional event, and the input data are sent.
PDO Mapping
PDO mapping refers to mapping of the application objects (real time data) from the object directory to the
process data objects. The CANopen device profile provide a default mapping for every device type, and this
is appropriate for most applications. Thus the default mapping for digital I/O simply represents the inputs and
outputs in their physical sequence in the transmit and receive process data objects.
The default PDOs for drives contain 2 bytes each of a control and status word and a set or actual value for
the relevant axis.
The current mapping can be read by means of corresponding entries in the object directory. These are
known as the mapping tables. The first location in the mapping table (sub-index 0) contains the number of
mapped objects that are listed after it. The tables are located in the object directory at index 0x1600ff for the
RxPDOs and at 0x1A00ff for the TxPDOs.
Digital and analog input/output modules: Read out the I/O number
The current number of digital and analog inputs and outputs can be determined or verified by reading out the
corresponding application objects in the object directory:

CANopen system overview
CXxxxx-M510/B51018 Version: 1.0
Parameter Object directory address
Number of digital input bytes Index 0x6000, sub-index 0
Number of digital output bytes Index 0x6200, sub-index 0
Number of analog inputs Index 0x6401, sub-index 0
Number of analog outputs Index 0x6411, sub-index 0
Variable mapping
As a rule, the default mapping of the process data objects already satisfies the requirements. For special
types of application the mapping can nevertheless be altered: the Beckhoff CANopen Bus Couplers, for
instance, thus support variable mapping, in which the application objects (input and output data) can be
freely allocated to the PDOs. The mapping tables must be configured for this: as from Version 4 of
CANopen, only the following procedure is permitted, and must be followed precisely:
1. First delete the PDO (set 0x1400ff, or 0x1800ff, sub-index 1, bit 31 to "1")
2. Set sub-index 0 in the mapping parameters (0x1600ff or 0x1A00ff) to "0"
3. Change mapping entries (0x1600ff or 0x1A00ff, SI 1..8)
4. Set sub-index 0 in the mapping parameters to the valid value. The device then checks the entries for
consistency.
5. Create PDO by entering the identifier (0x1400ff or 0x1800ff, sub-index 1).
Dummy Mapping
A further feature of CANopen is the mapping of placeholders, or dummy entries. The data type entries stored
in the object directory, which do not themselves have data, are used as placeholders. If such entries are
contained in the mapping table, the corresponding data from the device is not evaluated. In this way, for
instance, a number of drives can be supplied with new set values using a single CAN telegram, or outputs on
a number of nodes can be set simultaneously, even in event-driven mode.
Also see about this
2PDO Parameterization [}40]
2.1.4 Service Data Objects (SDO)
The parameters listed in the object directory are read and written by means of service data objects. These
SDOs are Multiplexed Domains, i.e. data structures of any size that have a multiplexer (address). The
multiplexer consists of a 16-bit index and an 8-bit sub-index that address the corresponding entries in the
object directory.

CANopen system overview
CXxxxx-M510/B510 19Version: 1.0
SDO protocol: access to the object directory
The CANopen Bus Couplers are servers for the SDO, which means that at the request of a client (e.g. of the
IPC or the PLC) they make data available (upload), or they receive data from the client (download). This
involves a handshake between the client and the server.
When the size of the parameter to be transferred is not more than 4 bytes, a single handshake is sufficient
(one telegram pair): For a download, the client sends the data together with its index and sub-index, and the
server confirms reception. For an upload, the client requests the data by transmitting the index and sub-
index of the desired parameter, and the server sends the parameter (including index and sub-index) in its
answer telegram.
The same pair of identifiers is used for both upload and download. The telegrams, which are always 8 bytes
long, encode the various services in the first data byte. All parameters with the exception of objects 1008h,
1009h and 100Ah (device name, hardware and software versions) are only at most 4 bytes long, so this
description is restricted to transmission in expedited transfer.
Protocol
The structure of the SDO telegrams is described below.
Client -> Server, Upload Request
11 bit
identifier
8 bytes of user data
0x600
(=1536de
z) + node
ID
0x40 Index0 Index1 SubIdx 0x00 0x00 0x00 0x00
Parameters Explanation
Index0 Index low byte (Unsigned16, LSB)
Index1 Index high byte (Unsigned16, MSB)
SubIdx Sub-index (Unsigned8)

CANopen system overview
CXxxxx-M510/B51020 Version: 1.0
Client -> Server, Upload Response
11 bit
identifier
8 bytes of user data
0x580
(=1408de
c) + node
ID
0x4x Index0 Index1 SubIdx Data0 Data1 Data2 Data3
Parameters Explanation
Index0 Index low byte (Unsigned16, LSB)
Index1 Index high byte (Unsigned16, MSB)
SubIdx Sub-index (Unsigned8)
Data0 Data low low byte (LLSB)
Data3 Data high high byte (MMSB)
Parameters whose data type is Unsigned8 are transmitted in byte D0, parameters whose type is Unsigned16
use D0 and D1.
The number of valid data bytes is coded as follows in the first CAN data byte (0x4x):
Number of param-
eter bytes
1234
First CAN data byte 0x4F 0x4B 0x47 0x43
Client -> Server, Download Request
11 bit
identifier
8 bytes of user data
0x600
(=1536de
c) + node
ID
0x22 Index0 Index1 SubIdx Data0 Data1 Data2 Data3
Parameters Explanation
Index0 Index low byte (Unsigned16, LSB)
Index1 Index high byte (Unsigned16, MSB)
SubIdx Sub-index (Unsigned8)
Data0 Data low low byte (LLSB)
Data3 Data high high byte (MMSB)
It is optionally possible to give the number of valid parameter data bytes in the first CAN data byte
Number of param-
eter bytes
1234
First CAN data byte 0x2F 0x2B 0x27 0x23
This is, however, not generally necessary, since only the less significant data bytes up to the length of the
object directory entry that is to be written are evaluated. A download of data up to 4 bytes in length can
therefore always be achieved in Beckhoff bus nodes with 22h in the first CAN data byte.