cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

cpc Will1/Will1-B Servo DriveCiA 301 CANopen
Communication Manual
Revision 1.0

1cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Table of Contents
Table of Contents ........................................................................................................... 2
1. About This Manual ................................................................................................. 5
1.1. Revision History ......................................................................................... 5
1.2. Disclaimer .................................................................................................. 6
1.3. Contact Us ................................................................................................. 7
2. Introduction............................................................................................................ 8
2.1. Abbreviations and Terms ......................................................................... 10
3. CANopen Basics .................................................................................................... 123.1. Physical Layer........................................................................................... 123.2. CAN-ID ..................................................................................................... 13
3.2.1. CANopen (Base) Frame Format ....................................................... 13
3.2.2. Generic pre-defined connection set ................................................ 15
3.2.3. Restricted CAN-IDs .......................................................................... 173.3. CANopen Device Model ........................................................................... 18
3.4. CANopen Application Layer ..................................................................... 19
3.4.1. Service Primitives ............................................................................ 19
3.4.2. Application Layer Services ............................................................... 20
3.5. Communication Protocol Sequences ....................................................... 22
3.5.1. General ........................................................................................... 22
3.5.2. Producer/consumer protocol .......................................................... 23
3.5.3. Client/server protocol ..................................................................... 24
3.6. Communication Objects........................................................................... 25
3.7. Object Dictionary ..................................................................................... 26
3.8. RTR – Remote Transmission Request ....................................................... 26
3.9. Inhibit Time ............................................................................................. 26
3.10. Data Types ............................................................................................... 27
3.10.1. Unsigned Integer ............................................................................. 28
3.10.2. Signed Integer ................................................................................. 29
3.10.3. Floating-Point Numbers .................................................................. 30
3.10.4. Visible String ................................................................................... 30
3.10.5. Time of Day ..................................................................................... 30
3.10.6. Domain ........................................................................................... 31
4. The Object Dictionary ........................................................................................... 31
4.1. Dictionary General Structure ................................................................... 31
4.2. Object Code Usage .................................................................................. 32
2

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.

4.3. Access Usage ........................................................................................... 33
4.4. Format of Object and Entry...................................................................... 34
Network Management (NMT)............................................................................... 35
5.1. NMT State Machine ................................................................................. 35
5.1.1. NMT State Transitions ..................................................................... 36
5.1.2. NMT States ..................................................................................... 36
5.2. NMT protocols ......................................................................................... 37
5.2.1. Node Control Protocols ................................................................... 37
5.2.1.1.

Protocol – start remote node ................................................................... 37

5.2.1.2.

Protocol – stop remote node .................................................................... 38

5.2.1.3.

Protocol – enter pre-operational .............................................................. 38

5.2.1.4.

Protocol – reset node ............................................................................... 39

5.2.1.5.

Protocol – reset communication .............................................................. 39

5.2.2. Error Control Protocol ..................................................................... 40
5.2.2.1.

Protocol – heartbeat ................................................................................. 40

5.2.3. Protocol Boot-up ............................................................................. 42
5.3. NMT States and Communication Object Relation .................................... 43
6. Service Data Objects (SDOs) ................................................................................. 44
6.1. SDO Services and Protocols ..................................................................... 45
6.1.1. SDO Download ................................................................................ 47
6.1.2. SDO Download Initiate .................................................................... 50
6.1.3. SDO Download Segment ................................................................. 52
6.1.4. SDO Upload..................................................................................... 54
6.1.5. SDO Upload Initiate......................................................................... 56
6.1.6. SDO Upload Segment ...................................................................... 58
6.1.7. SDO Abort Transfer ......................................................................... 60
7. Process Data Objects (PDOs)..................................................................................... 63
7.1. Transmission Modes ................................................................................... 64
7.2. Triggering Modes ........................................................................................ 65
7.2.1. Synchronously Triggered ................................................................. 65
7.2.2. Event-and timer-driven ................................................................... 65
8. Emergency (EMCY) ............................................................................................... 66
8.1. Emergency state transition ...................................................................... 67
8.2. Emergency Object Service and Protocol .................................................. 68
9. SYNC ..................................................................................................................... 69
9.1. SYNC Service and Protocol ....................................................................... 70
3

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

10. Time Stamp (TIME) ............................................................................................... 71
10.1. TIME Service and Protocol ....................................................................... 71
11. The EDS ................................................................................................................ 72
12. Communication Profile ......................................................................................... 73
Object 0x1000: Device type ............................................................................... 73
Object 0x1001: Error register ............................................................................. 74
Object 0x1002: Manufacturer status register..................................................... 75
Object 0x1003: Pre-defined error field .............................................................. 76
Object 0x1005: COB-ID SYNC message............................................................... 78
Object 0x1006: Communication cycle period..................................................... 80
Object 0x1008: Manufacturer device name ....................................................... 81
Object 0x1009: Manufacturer hardware version ............................................... 82
Object 0x100A: Manufacturer software version ................................................ 83
Object 0x1010: Store parameters ...................................................................... 84
Object 0x1011: Restore default parameters....................................................... 88
Object 0x1013: High resolution time stamp ....................................................... 92
Object 0x1014: COB-ID EMCY ............................................................................ 93
Object 0x1015: Inhibit time EMCY ..................................................................... 94
Object 0x1016: Consumer heartbeat time ......................................................... 95
Object 0x1017: Producer heartbeat time ........................................................... 97
Object 0x1018: Identity object........................................................................... 98
Object 0x1019: Synchronous counter overflow value ...................................... 101
Object 0x1021: Store EDS ................................................................................ 103
Object 0x1022: Store format............................................................................ 104
Object 0x1200: SDO server parameter............................................................. 105
Object 0x1400~0x1403: RPDO communication parameter .............................. 107
Object 0x1600~0x1603: RPDO mapping parameter ......................................... 110
Object 0x1800~0x1803: TPDO communication parameter .............................. 115
Object 0x1A00: TPDO mapping parameter ...................................................... 120
13. Initial CAN Communication Setup ....................................................................... 125

4cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

1. About This Manual
1.1. Revision History
Revision

Date

Description

Remarks

1.0

March, 2018

Initial release--5

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

1.2. Disclaimer
1. Information furnished by cpc is believed to be accurate and reliable. However, no
responsibility is assumed by cpc for its use, nor for any infringements of patents orother rights of third parties which may result from its use. cpc doesn’t grant any
license under its patent rights, nor the rights of others.
2. In addition, cpc assumes no responsibility for any errors that may appear in thisdocument and for any claims or damages arising from information contained inthis document.
3. The product specified in this document has been developed, produced, tested anddocumented in accordance with the relevant standards. cpc is not responsible fordamages, accidents, or injuries caused by any deviation from the configurationand installation described in this guide;
4. Furthermore, cpc is not responsible for the performance of new measurements orensuring that regulatory requirements are met.
5. The product specified in this document is not assumed to be used in criticalapplication including, but not limited to, medical equipment, transportation,
aerospace and nuclear instruments, undersea equipment, power plant equipment,
as well as disaster prevention and crime prevention equipment.
6. We reserve the right to modify our products, including its hardware and software
design, in order to improve its design and/or performance. The information in thisdocument is subject to change without notice and does not represent acommitment by cpc.
7. Specifications are subject to change without notice.
8. Performance specification beyond those specified by safety regulations areguaranteed by design and not subject to production test.
9. Customers should obtain the latest relevant information before placing orders
and should verify that such information is current and complete.
10. cpc assumes no liability for applications assistance or customer product design.
Customers are responsible for their products and applications using cpc
products.

6cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

1.3. Contact Us
Headquarters
Chieftek Precision Co., Ltd.
NO.3, Dali 1st Rd., Xinshi Dist., Southern Taiwan Science Park,
Tainan City. 741-45, Taiwan (R.O.C.) 3
TEL: +886-6-505-5858
FAX: +886-6-505-5959
Email : service@mail.chieftek.com

China
Chieftek Machinery Kunshan Co., Ltd.
No.1188, Hongqiao Rd, Kunshan, Jiangsu, P.R. China
Tel : +86-512-55252831
Fax : +86-512-55252851
Email : cn.service@mail.chieftek.com

Europecpc Europa GmbH
Industriepark 314, D-78244 Gottmadingen, Germany
Tel : +49-7731-59130-38
Fax : +49-7731-59130-28
Email : info@cpc-europa.deUSA
Chieftek Precision USA Co., Ltd.
2280 E. Locust Court. Ontario, CA 91761, USA
TEL: +1-909-773-1200
FAX: +1-909-773-1202
Email : info@usa.chieftek.com

7

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

2. Introduction
This manual repeats certain CiA standards and includes cpc-specific information. It
explains how to implement CiA 301 communication with cpc’s Will1/Will1-B servo
drive. Most of the cpc drive communication functionality is standard, based on CiA
301 CANopen, version 4.2.0.
CAN communication:
CAN is message based, prioritizing messages is hence necessary. CAN allows any
node to receive all transmitted messages, decide relevance and act (or ignore)accordingly. The CAN devices send/receive data across the CAN network in packets
called “frames”.
l
CAN Frame:ØAn entire CAN data transmission (also referred to as a CAN message)
consisting of CAN-ID, RTR, data length, and the actual data.
ØComes in two formats according to CiA 301:
- Standard addressing, using an 11-bit CAN-ID;- Extended addressing, using a 29-bit CAN-ID.
Note:
Extended addressing is not implemented.
l

CAN-ID:Ø
Consists of a 4-bit function code indicating the message’s priority (thelower the value, the higher the priority), and of a 7-bit Node-ID.
Ø
It is necessary that users (or master device) assign unique Node-ID foreach device respectively in the network to enable data transmission.
See further details about CAN-ID in chapter 3.2.

To set up Node-ID please refer to chapter 13 (Initial CAN Communication Setup);
To download EDS please refer to chapter 11 (The EDS).

8

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Note:
The listed functionalities below are not implemented in the cpc drives.
l
l
l
l
l

RTR (Remote Transmission Request)
Service SDO block transfer
Service node guarding
Service life guarding
Multiplex PDO (MPDO)andl

The following objects:
Object 0x1007: Synchronous window length
Object 0x100C: Guard time
Object 0x100D: Life time factor
Object 0x1012: COB-ID time stamp object
Object 0x1020: Verify configuration
Object 0x1023: OS commandObject 0x1024: OS command mode
Object 0x1025: OS debugger interface
Object 0x1026: OS prompt
Object 0x1027: Module list
Object 0x1028: Emergency consumer object
Object 0x1029: Error behavior object
Object 0x1280 to 0x12FF: SDO client parameter
Object 0x1FA0 to 0x1FCF: Object scanner list
Object 0x1FD0 to 0x1FFF: Object dispatching list

9

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

2.1. Abbreviations and Terms
Abbreviations

Definition

CAN

Controller area network

CAN base frame

message that contains up to 8 byte and is identified by 11
bits as defined in /ISO11898-1/

CAN extended
frame

message that contains up to 8 byte and is identified by 29
bits as defined in /ISO11898-1/

CAN-IDCAN identifier –identifier for CAN data.

COB

Communication object –identifier that contains the CAN-ID and additional control
bits.

COB-ID

COB identifier

CSDO

Client-SDO

EMCY(referring to Emergency Object)

EntityFSA

Logical device

particular thing, such as a person, place, process, concept,
association, or event.
Finite state automaton –model of computation consisting of a set of states, a start
state, an input alphabet, and a transition function that maps
input symbols and current states to a next state;computation begins in the start state with an input string; itchanges to new states depending on the transition function.
representation of a field device in terms of its objects andbehavior according to a field device model that describes
the device’s data and behavior as viewed through a network

LSB

Least significant bit/byte

MPDO

Multiplexed-PDO

MSB

Most significant bit/byte

NMT

Network management10

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Abbreviations

Definition

Node-ID

Node identifier –network-wide unique identifier for each CANopen device.

Objectentity with a well-defined boundary and identity that
encapsulates state and behavior

PDO

Process data object

PLS

Physical layer signaling

PMA

Physical medium attachment

RPDO

Receive-PDO

RTR

Remote transmission request

SDO

Service data object

SSDO

Server-SDO

SYNC

Synchronization object

TPDO

Transmit-PDO

11cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3. CANopen Basics
This chapter explains, in general, those CANopen communication features mostrelated to the cpc driver.

3.1. Physical Layer
CAN is a serial communication standard in which the transferred data is coded aselectrical pulses on a two-wire communication line.

12

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.2. CAN-ID
3.2.1.

CANopen (Base) Frame Format

The format of a CANopen message is shown as below. The most relevant fields tousers are: Identifier (i.e. CAN-ID), RTR, Data length code, and Data field.
<CANopen Frame in Format>

Explanation:
Field nameStart-of-frame (SOF)
Identifier (= CAN-ID)
Remote transmission
request (RTR)
Identifier extension bit(IDE)
Reserved bit (r0)Data length code (DLC)
Data field
CRC
CRC delimiter
ACK slot
ACK delimiterEnd-of-frame (EOF)

Length(bits)
1
11
1
1
1

PurposeDenotes the start of frame transmission
A unique identifier which also represents the message priority
Must be dominant (0) for data frames and recessive (1) for
remote request frames.
Must be dominant (0) for base frame format with 11-bit
identifiers
Reserved bit. Must be dominant (0), but accepted as either
dominant or recessive.
Number of bytes of data (0–8 bytes)

4
0–64
Data to be transmitted (length in bytes dictated by DLC field)(0-8 bytes)
15
Cyclic redundancy check1
Must be recessive (1)Transmitter sends recessive (1) and any receiver can assert a1dominant (0)1Must be recessive (1)7Must be recessive (1)13cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Note:l
In CANopen, the 11-bit CAN-ID is split into two parts:
Øa 4-bit function code, andØ
a 7-bit CANopen node ID. The 7-bit size limits the number of devices
on a CANopen network to 127 nodes.
l
The COB-ID is composed of the CAN-ID bits and additional control bits.

14

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.2.2.

Generic pre-defined connection set

In order to reduce configuration effort for simple networks a CAN-ID allocation
scheme is defined. These CAN-IDs are available in the NMT state Pre-operational
directly after the NMT state Initialisation (if no modifications have been stored).
The objects SYNC, TIME, EMCY write and PDO can be deleted and re-created with
new CAN-IDs when a master device designates new CAN-IDs to them.
The CAN-ID-allocation scheme:lConsists ofØ
a 4-bit functional code, which determines the object priority, andØ
a 7-bit Node-ID, which allows to distinguish between CANopen devices ofthe same functionality.
This scheme allows a peer-to-peer communication between a single master
CANopen device and up to 127 NMT slave CANopen devices.
<CAN-ID-allocation scheme for the generic pre-defined connection>
bit 109

8

7

6Function code
MSB
l

l

5
4
CAN-ID3

2

1

0

Node-ID
LSB

Supports the broadcasting of non-confirmed NMT, SYNC and TIME messages.
Broadcasting is indicated by a Node-ID of zero.
The generic pre-defined connection set supports: one EMCY object, one SDO,
maximum 4 RPDOs and 4 TPDOs, and the NMT objects.

15

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

The two tables below show the supported objects and their allocated CAN-IDs.
<Broadcast objects of the generic pre-defined connection set>
COB Type

Function code
(bit 7-10 of CAN-ID)

resulting CAN-ID

NMT

0000b

0 (000h)

SYNC

0001b

128 (080h)

TIME

0010b

256 (100h)<Peer-to-peer objects of the generic pre-defined connection set>
COB Type

Function code
(bit 7-10 of CAN-ID)

resulting CAN-IDs

EMCY

0000b

129 (081h) – 255 (0FFh)

PDO1 (tx)0011b385 (181h) – 511 (1FFh)

PDO1 (rx)0100b513 (201h) – 639 (27Fh)

PDO2 (tx)0101b641 (281h) – 767 (2FFh)

PDO2 (rx)0110b769 (301h) – 895 (37Fh)

PDO3 (tx)0111b897 (381h) – 1023 (3FFh)

PDO3 (rx)1000b1025 (401h) – 1151 (47Fh)

PDO4 (tx)1001b1153 (481h) – 1279 (4FFh)

PDO4 (rx)1010b1281 (501h) – 1407 (57Fh)

SDO (tx)

1011b

1409 (581h) – 1535 (5FFh)

SDO (rx)

1100b

1537 (601h) – 1663 (67Fh)

NMT error control

1110b

1793 (701h) – 1919 (77Fh)

16

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.2.3.

Restricted CAN-IDs

Any CAN-ID listed below is of restricted use and cannot be used by configurable
communication objects, neither by SYNC, TIME, EMCY, and SDO.
<Restricted CAN-IDs>
CAN-IDs

used by COB

0 (000h)NMT

1 (001h) – 127 (07Fh)

reserved

257 (101h) – 384 (180h)

reserved

1409 (581h) – 1535 (5FFh)default SDO (tx)1537 (601h) – 1663 (67Fh)

default SDO (rx)1760 (6E0h) – 1791 (6FFh)reserved

1793 (701h) – 1919 (77Fh)

NMT Error Control

2020 (780h) – 2047 (7FFh)reserved

17

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.3. CANopen Device ModelA CANopen device is structured as the diagram below.
Communication

Object Dictionary

Application
objectState MachineComm.
objectComm.
objectComm.
objectEntry 1
Entry 2…
Entry NComm.
objectllApplication
objectApplication
objectApplication
objectNetworklApplication

Process

Communication – This function unit provides the communication objects
and the proper 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 behavior 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.

18

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.4. CANopen Application Layer
The application layer is an abstraction layer.
ldescribes a concept to configure and communicate real-time data as well as themechanisms for synchronization between CANopen devices.
l
specifies the shared communications protocols and interface methods used byhosts in a communications network.

3.4.1.

Service Primitives

Service primitives are the methods by which the application and the application
layer interact. There are 4 types:
Service Typeissued by:to the:Behavior

Requestapplication

application layer

To request a service

Indication

application layer

Application

To report an internal
event detected by theapplication layer, OR toindicate that a service
is requested.

Response

application

application layer

To respond to apreviously received
indication.

Confirmation

application layer

application

To report the result ofa previously issued
request.

19

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.4.2.

Application Layer Services<Application Layer Services>

Application X

Application X

requestindication
Local service

Provider-initiatedservice

Application X

Application A,B,C ...

requestindication

Application X
requestindication

confirmation

indication
Unconfirmed service

Application Y
indication
response

Confirmed service

An application layer service defines the primitives that are exchanged between theapplication layer and the co-operating applications for a particular service of aservice object.
The application layer services supported by CANopen are shown as the picture
above. See explanations on next page.

20

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

l

l

l

l

A local service involves only the local service object. The application issues arequest to its local service object that executes the requested service without
communicating with (a) peer service object(s).
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.
An unconfirmed service involves one or more peer service objects. The
application issues a request to its local service object. This request is transferredto the peer service object(s) that each passes it to their application as anindication. The result is not confirmed back.
A confirmed service involves 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 otherapplication issues a response that is transferred to the originating service object
that passes it as a confirmation to the requesting application.

Note:
Unconfirmed and confirmed services are collectively called remote services.

21

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.5. Communication Protocol Sequences
3.5.1.

GeneralThe communication protocol defines:l
The principles of each communication protocol, andl
The available modes of message transmission triggering.
ØØ

There are 2 types of communication protocol models:- Producer/Consumer protocol (see chapter 3.5.2.)
And subcategory Master/Slave protocol
Client/Server protocol (see sub-clause 3.5.3.)

The CANopen communication protocol supports the transmission ofsynchronous message – transmitted at the pre-defined timing
event-driven message – transmitted at any time.
(See Chapters 7.1 and 7.2).
Through the synchronous message transmission, it is possible to acquireand activate data via network wide coordination22

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.5.2.

Producer/consumer protocol

The producer/consumer protocol involves one producer and several consumers.
This model is featured with an unconfirmed protocol requested by the producer.
Any CANopen device can be the request producer, the rest devices (consumers)
can choose to enable/disable the message. For example, services using thisproducer/consumer protocol: PDO and EMCY.

Producer

Consumers
indication

requestdata

indication
indication

Producer/Consumer communication protocol

There is a subcategory under the producer/consumer category – Master/slave
protocol: At any time, there is exactly one CANopen device serving as a master. Allother CANopen devices in the network are considered as slaves. The masterinitiates a request and the salves will respond (if the protocol requires this behavior).
Note:
Some services can be initiated only by Master device, such as SYNC, TIME, and NMT
state services.

23

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.5.3.

Client/server protocol

This is a communication protocol used between a single client and a single server.
A client issues a request (upload/download) hence triggering the server to executea certain task. After completing the task, the server answers the request.

ClientServerrequestdata

confirmationdata

indication
response

Client/server communication protocol

24

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.6. Communication Objects
The data-byte units transported through a CAN network are called communication
objects (COBs). The cpc Will1/Will1-B servo drive uses the following COB types:
COB Type

Description

Service Data Object (SDO)

SDO messages are used to manipulate OD objects
according to their IDs.
The server receives the SDO, which specifies in its
message which object is to be dealt with.
Large data set can be transferred using a chain ofsegmented SDO messages.

Process Data Object (PDO)

PDO messages are used to manipulate OD
objects without explicit reference to the object
identifier, which is possible if there is an a-priori
convention concerning the OD item referenced.
Such conventions are called “PDO mappings”;
these are actually OD objects themselves andmay be defined and manipulated using an SDO.

Emergency (EMCY)

Emergency messages are used by the servo
drives to warn of an exception. The EMCY is the
only COB type that a servo drive may transmit
without first being explicitly asked. EMCY objects
are similar to servo drive “interrupts”: theyeliminate the need to poll the servo drive
continuously for the emergency status.

Network Management (NMT)

NMT objects are used by CAN clients to initializea servo drive as a server.

25

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.7. Object Dictionary
The object dictionary is a collection of objects accessible via the network in anordered predefined fashion. Each object within the object dictionary is addressedusing a 16-bit index and an 8-bit sub-index. See further details in chapter 4.

3.8. RTR – Remote Transmission Request
The RTR function is not implemented in cpc drives.

3.9. Inhibit TimeThe inhibit time for a given message type is the minimum time that must elapse
from the message is first transmitted until the time that it is transmitted again.
The purpose of inhibit time is to prevent that the communication objects with lower
priority are cut out from net source by those with higher priority. Configuring inhibit
time avoids the possibility that the lower-priority communication objects being notable to transmit messages.

26

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.10. Data Types
To be able to exchange meaningful data across the network, it is necessary that theformat of this data and its meaning is known by the producer and consumer(s). This
specification models this by the concept of data types.
The encoding rules define the representation of values of data types and thetransfer syntax for the representations. Values are represented as bit sequences.
Bit sequences are transferred in sequences of octets (bytes). For numerical datatypes the encoding is little endian.
There are also some general “extended” data types such as “Visible String” or “Timeof Day” for example (see chapter 3.10.4. and chapter 3.10.5.).
In the following sections, we will describe Unsigned integer, Signed integer, Floatingpoint numbers, Visible string, and Time of day.

27

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.10.1.

Unsigned Integer

Data of UNSIGNEDn has values in the non-negative integers. The value range is 0, …,
2n-1. The data is shown as bit sequences of length n.
For example:
The value 276 = 114h (supposed with UNSIGNED16 data type format), 114h istransferred in two octets across the bus, first 14h and then 01h.

0 1 1 4 hex

Value 276
0000

0001

Second octeth( 01 )

0001

0100 binFirst octet( 14h )

<Transfer syntax for data type UNSIGNEDn>
octet number
UNSINGED8UNSINGED16
UNSINGED32
UNSINGED64

1
2
3
4
5
6
7
8
b7…b0
b7…b0 b15…b8
b7…b0 b15…b8 b23…b16 b31…b24
b7…b0 b15…b8 b23…b16 b31…b24 b39…b32 b47…b40 b55…b48 b63…b56

28

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.10.2.

Signed Integer

Data of INTEGERn has values in the integers.
The value range is from -2n-1 to 2n-1-1, including 0.
The data is represented as bit sequences of length n.
For example:
The value -276 = FEECh (supposed with SIGNED16 data type format), FEECh istransferred in two octets across the bus, first ECh and then FEh.

F E E C hex

Value -276
1111

1110

Second octeth( FE )

1110

1100 binFirst octet( ECh )

<Transfer syntax for data type INTEGERn>octet number
UNSINGED8UNSINGED16
UNSINGED32
UNSINGED64

1
2
3
4
5
6
7
8
b7…b0
b7…b0 b15…b8
b7…b0 b15…b8 b23…b16 b31…b24
b7…b0 b15…b8 b23…b16 b31…b24 b39…b32 b47…b40 b55…b48 b63…b56

29

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.10.3.

Floating-Point Numbers

Data of basic data types REAL32 and REAL64 have values in the real numbers.
The data type REAL32 is represented as bit sequence of length 32. The encoding ofvalues follows /IEEE754/.
The data type REAL64 is represented as bit sequence of length 64. The encoding ofvalues follows /IEEE754/.

3.10.4.

Visible String

The data type VISIBLE_STRINGlength is defined below. The admissible values of dataof type VISIBLE_CHAR are 0h and the range from 20h to 7Eh. The data areinterpreted as ISO 646-1973(E) 7-bit coded characters. length is the length of thevisible string.
UNSIGNED8VISIBLE_CHAR
ARRAY [ length ] OF VISIBLE_CHAR VISIBLE_STRINGlength
There is no 0h necessary to terminate the string.

3.10.5.

Time of Day

The data type TIME_OF_DAY represents absolute time.
It follows from the definition and the encoding rules that TIME_OF_DAY isrepresented as bit sequence of length 48.
Component ms is the time in milliseconds after midnight. Component days is thenumber of days since January 1, 1984.
STRUCT OF
UNSIGNED28 ms,
VOID4 reserved,
UNSIGNED16 days
TIME_OF_DAY
30

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

3.10.6.

Domain
Domains are used to transfer an arbitrary large block of data from a client to aserver and vice versa.

4. The Object Dictionary
4.1. Dictionary General Structure
The overall layout of the standard object dictionary is shown in the table below.
<Object Dictionary Structure>
Index

Object0x1000 - 0x1FFF

Communication profile area
- contains the communication specific parameters.
- common to all CANopen devices.

0x2000 – 0x5FFF

Manufacturer-specific profile area.
(manufacturer-specific functionality.)

0x6000 – 0x67FF

Standardized profile area 1st logical device

31cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

4.2. Object Code Usage“Object code” represents what kind of object is at that specific index within theobject dictionary.
Object code Object kindDescription

00h

NULL

An object with no data fields.

02h

DOMAIN

Large variable amount of data;
e.g. executable program code05h

DEFTYPE

Denotes a data type;e.g. INTERGER8, DOMAIN, and FLOAT.

07h

VAR

A single value;e.g. an UNSIGNED8, a FLOAT, or an INTERGER8.

08h

ARRAY

A multiple data field object where each data field isa simple variable of the SAME basic data type e.g.
array of UNSIGNED16 etc.
l
Its sub-index 0 is of UNSIGNED8 and therefore
not part of the ARRAY data.

09hRECORD

A multiple data field object where the data fields
may be any combination of simple variables.
l
Its sub-index 0 is of UNSIGNED8 and sub-index
255 is of UNSIGNED32 and therefore not partof the RECORD data.

32

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

4.3. Access Usage
The “attribute” in the table below defines the access rights of a particular object.
The view point is from network into CANopen device.
Note:
Even with READ or WRITE access right, some objects cannot be configured during
motor on.
<Access attributes for data objects>
Attribute

Description

rw

read and write accesswo

write only accessroread only access

const

read only access, value is constant.
The value may change in NMT state Initialisation.
The value won’t change in the NMT states preoperation, operational and stopped.

33

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

4.4. Format of Object and Entry
The formats of object description and entry description are as follows.
<Format of Object Description>
Object description
Index

Profile index number

Name

Name of object

Object code

Variable classification(i.e., NULL, DOMAIN, DEFTYPE, VAR, ARRAY, and RECORD)

Data type

Data type classification<Format of Entry Description>

Entry description
Sub-index

Number of the sub- being described

Description

Descriptive name of the sub-index (field only used for arrays,
records and structures)

AccessRead only (ro) or read/write (rw) or write only (wo) or const (c)PDO mapping

defines if this object should be mapped to a PDO. Description:
Default:

Object is part of the default mapping (see device
profile or application profile).

TPDO:

Object can be mapped into a TPDO and cannot bemapped into a RPDO.

RPDO:

Object can be mapped into a RPDO and cannot not
be mapped into a TPDO.

No:

Object should not be mapped into a PDO.

Value range

range of possible values, or name of data type for full range

Default value

No:

No default value applicable.

Profile-specific:

Default value of an object should be definedin a profile.

Value:

default value of an object after CANopen
device initialisation34

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5. Network Management (NMT)The network management (NMT) is CANopen device oriented and follows a masterslave structure. All CANopen devices are regarded as NMT slaves.
An NMT slave is uniquely identified in the network by its Node-ID, a value in therange of [1 to 127].

5.1. NMT State Machine
The diagram below shows the mechanism of NMT state machine. See the tablebelow for further description of transitions.
<NMT state diagram of a CANopen device>
Power on or hardware reset(1)
Initialisation
(2)

(14)

(11)

Pre-operational
(13)
(12)

(4)

(5)

(3)
(4), (7)(5), (8)(6)(9), (10), (11)(12), (13), (14)(10)
Stopped

(6)

(3)

(8)

Operational

(1)
(2)

(7)

(9)

At Power on the NMT state initialization is entered
NMT state Initialization is finished, then enter NMT state Preoperational automatically
NMT service start remote node indication or by local control
NMT service enter pre-operational indication
NMT service stop remote node indication
NMT service start remote node indication
NMT service reset node indication
NMT service reset communication indication35

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.1.1.

NMT State Transitions

NMT state transitions are caused by:lReceipt of an NMT service used for node control services.
l
Hardware reset, orlnode control services locally initiated by application events, defined by device
profiles and application profiles

5.1.2.

NMT States

State

Description

InitializationlPre-operational

l

l
l
l

Operationall

StoppedllServo drive is not ready, or it is booting. Drive will not
respond to communication and will not transmit anything.
CANopen devices enter this NMT state Pre-operational
directly after finishing the CANopen devices initialization.
PDOs do NOT exist; PDO communication is NOT allowed.
Communication via SDOs is allowed.
Via SDOs, CANopen device is parameterized and
CAN-IDs are allocated.
All communication objects are active.
By switching a CANopen device into this NMT state
Stopped, it is forced to stop the communication
altogether (except heartbeat, if active).
If there are EMCY messages triggered in this NMT state,
they will be pending.
The most recent active EMCY reason will be transmitted
after the CANopen device transits into another NMT state.
Note: The error history can be read by accessing the object
1003h.

36

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.2. NMT protocols
5.2.1.
5.2.1.1.

Node Control Protocols
Protocol – start remote node

The protocol as depicted in the figure below is used to implement the NMT service– start remote node.

NMT master

NMT slave

requestCAN-ID = 0
byte

0

1

cs = 1 Node-ID

cs: NMT command specifier
1: start37

indication
indication
indication

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.2.1.2.

Protocol – stop remote node

The protocol as depicted in the figure below is used to implement the NMT service– stop remote node.

NMT master

NMT slave

requestCAN-ID = 0
byte

0

1

cs = 2 Node-ID

cs: NMT command specifier
2 stop5.2.1.3.

indication
indication
indication

Protocol – enter pre-operational

The protocol as depicted in the figure below is used to implement the NMT service– enter pre-operational.

NMT master

NMT slave

requestCAN-ID = 0
byte

0
1
cs = 128 Node-ID

cs: NMT command specifier
128: enter pre-operational

38

indication
indication
indication

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.2.1.4.

Protocol – reset node

The protocol as depicted in the figure below is used to implement the NMT service– reset node.

NMT master

NMT slave

requestCAN-ID = 0
byte

0
1
cs = 129 Node-ID

cs: NMT command specifier
129: reset node

5.2.1.5.

indication
indication
indication

Protocol – reset communication

The protocol as depicted in the figure below is used to implement the NMT service– reset communication.

NMT master

NMT slave

requestCAN-ID = 0
byte

0
1
cs = 130 Node-ID

cs: NMT command specifier
130 reset communication

39

indication
indication
indication

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.2.2.

Error Control Protocol

The cpc Will1/Will1-B drives implement the heartbeat protocol for error control.

5.2.2.1.

Protocol – heartbeat

A heartbeat producer transmits a heartbeat message cyclically. One or moreheartbeat consumer receives the indication. The relationship between producer
and consumer is configurable via the object dictionary.
llHeartbeat consumer time
The heartbeat consumer guards the reception of the heartbeat within theheartbeat consumer time.
If the heartbeat is not received within the heartbeat consumer time, aheartbeat error event will be generated.
Heartbeat producer time
If the heartbeat producer time is configured on a CANopen device the heartbeat
protocol begins immediately.
If a CANopen device starts with a value for the heartbeat producer time unequal
to 0, the heartbeat protocol starts on the transition from the NMT state
Initialization to the NMT state Preoperational. In this case the boot-up message
is regarded as first heartbeat message.

See protocol as depicted on next page.

40

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual<Heartbeat protocol>

CAN-ID = 1792 + Node-ID
byte
bit

7
r=0

0

6...0
s

indication
indication
indication

request
byte
bit

7
r=0

indication

0

6...0
s

indication
indication

Hearbeat
consumer time

Hearbeat
producer time

requestHeartbeatconsumer

Hearbeat
consumer time

HeartbeatproducerHeartbeat error
event

r: reserved (always 0)
s: the state of the heartbeat producer
0:
4:
5:
127:

Boot-up
StoppedOperational
Pre-operational

41

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.2.3.

Protocol Boot-up

The protocol Boot-up depicted in the figure below is used to signify that a NMT slave
has entered the NMT state Pre-operational after the NMT state Initialization. This
protocol uses the same CAN-ID as the heartbeat protocol.

<Boot-up protocol>

Boot-upproducerrequestBoot-upconsumerCAN-ID = 1792 + Node-ID
byte

0

0

One data bye is transmitted with value 042

indication

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

5.3. NMT States and Communication Object
Relation
The table below indicates the relation between NMT states and communication
objects.
The services of the communication objects can only be executed if the CANopen
devices are in the suitable NMT states. See the table below:<NMT states and executable communication objects>
ObjectState

Pre-operational

Operational

Stopped

PDO

-

V

-

SDO

V

V

-

SYNC

V

V

-

TIME

V

V

-

EMCY

V

V

-

Node control anderror control

V

V

V

*V: executable43cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6. Service Data Objects (SDOs)
A SDO provides direct access to object entries of a CANopen device's object
dictionary.
As these object entries may contain data of arbitrary size and data type. SDOs canbe used to transfer multiple data sets (each containing an arbitrary large amount ofdata) from a client to a server and vice versa.
Basically, an SDO is transferred as a sequence of segments.
Prior to transferring the segments, there is an initialization phase where client andserver prepare themselves for transferring the segments. For SDOs, it is also possible
to transfer a data set of up to four bytes during the initialization phase. Thismechanism is called SDO expedited transfer.
lll

Always the client initiates an SDO transfer for any type of transfer.
The owner of the accessed object dictionary is the server of the SDO.
Either the client or the server may take the initiative to abort the transfer of an
SDO.

44

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1. SDO Services and Protocols
The model for the SDO communication is the Client/Server model as described inchapter 3.5.3.
Features:- SDO number

SDO number [1] for every user type on the local device.

- User type“client” or “server”.

- Mux data typeMultiplexer contains index and sub-index of type
STRUCTURE OF UNSIGNED16, UNSIGNED8;
The index specifies an object of the CANopen device's
object dictionary, the sub-index specifies a component ofa CANopen device's object dictionary object.

- Transfer type

According to the length of data to transfer:
Expedited.
Normal (segmented) for up to 4 bytes.
Normal (segmented) for more than 4 data bytes.

- Data type

According to the referenced index and sub-index

45cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

The following services can be applied onto an SDO depending on the application
requirements:l
SDO download, which is subdivided intoØ
SDO download initiateØSDO download segmentl
SDO upload, which is subdivided intoØ
SDO upload initiateØ
SDO upload segmentl
SDO abort transfer
SDO expedited transfer is supported.
SDO segmented transfer is supported since objects larger than 4 Bytes aresupported.

46

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.1.

SDO Download

The client is using the service SDO download for transferring data from the client tothe server (owner of the object dictionary). The data, the multiplexer (index and
sub-index) of the data set, and its size are indicated to the server.
The SDO download containsl
the SDO download initiate service, andlthe SDO download segment services, including:Ø
normal download (data length > 4 bytes)
Ø
expedited download (data length within 4 byes)
SDOs are downloaded as a sequence of one or several “SDO download segment”
services preceded by an “SDO download initiate” service.
The protocol depicted on next page is used to implement the “SDO download”
service.

47

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual<Protocol - SDO download (normal / expedited)>e – download type
0: normal
1: expeditedt – toggle bit (only used by SDO normal download)c – completion (only used by SDO normal download)
0: downloading
1: successful completion of download

The SDO download sequence will be terminated by following occasions:a. An SDO download initiate request/indication with the e-bit set to 1 followed by
an SDO download initiate response/confirm, indicating the successful
completion of an expedited download sequence.
b. An SDO download segment response/confirm with the c-bit set to 1, indicating
the successful completion of a normal download sequence.
c. An SDO abort transfer request/indication, indicating the unsuccessful
completion of the download sequence.
d. A new SDO download initiate request/indication, indicating the unsuccessful
completion of the download sequence and the start of a new SDO download
sequence.
48

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Toggle bit failure
If in the download of two consecutive segments, the toggle bit does not alter, thecontent of the last segment will be ignored.
If such an error occurs to the application (client or server), the application will decideto abort the download – if it being the case, the user will need to send the message
all over (from the beginning of message) again.

49

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.2.

SDO Download Initiate

The client requests the server (i.e., owner of the object dictionary) to prepare
downloading of data by using the “SDO download initiate” service.
Besides, optionally the number of data bytes is indicated to the server. See theprotocol explanations below.
< Protocol - SDO download initiate >ClientrequestServer0byte
bit 7…5
CCS = 1

3…2

1

0

x

n

e

s

0

byte

confirmation

1

4

bit 7…5
SCS = 3

3

4

m

1

7

3

4

7

4…0
x

m

reserved

where:
ccs

Client command specifier
1: initiate download request.

scs

Server command specifier
3: initiate download responsenNumber of bytes in [d] that do not contain data.
Bytes [8-n, 7] do not contain data.
n = 0 if no segment size is indicated.

eTransfer type
0: normal transfer
1: expedited transfersSize indicator
0: Data set size is not indicated
1: Data set size is indicated50

indicationd (data)

responsecpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualmMultiplexor. Represents index/sub-index of the data to betransferred by SDO.

d

Data.
e = 0, s = 0: d is reserved for future use.
e = 0, s = 1: d contains number of bytes to be downloaded.
Byte 4 contains LSB and byte 7 contains MSB.
e = 1, s = 1: d contains data of length 4-n to be downloaded.
The encoding depends on the type of data referenced byindex and sub-index.
e = 1, s = 0: d contains an unspecified number of bytes to be
downloaded.

x

Not used; always 0.

reserved

Reserved for future use; always 0.

51cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.3.

SDO Download Segment

This protocol is used to implement the Download SDO Segment service.
The client transfers the segmented data to the server by using the SDO download
service. The segment data and optionally its size are indicated to the server.
The “continue parameter (c)” indicates the server whether there are still moresegments to be downloaded or that this is the last segment to be downloaded.
< Protocol - SDO download segment >Where:
ccs

Client command specifier
0: download segment request.

scs

Server command specifier
1: download segment response.

seg-data

Maximum 7 bytes of segment data can be downloaded.
The encoding depends on the type of the data referenced byindex and sub-index.

nNumber of bytes in [d] that do not contain segment data.
Bytes [8-n, 7] do not contain segment data.
n = 0 if no segment size is indicated.

cWhether there are more segments to be downloaded:
0: more segments to be downloaded.
1: no more segments to be downloaded.
52

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manualt

Toggle bit, which alternates for each subsequent segment that is
downloaded. The first segment has the toggle-bit set to 0. The
toggle bit is equal for the request and the response message.

x

Not used; always 0.

reserved

Reserved for future use; always 0.

53

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.4.

SDO Upload

The client is using the service SDO upload for transferring the data from the server(owner of the object dictionary) to the client. The multiplexer (index and sub-index)
of the data set is indicated to the server. The SDO upload consists of at least the SDO
upload initiate service and optional of SDO upload segment services (data length >4 bytes).
< Protocol – SDO upload >e – upload type
0: normal
1: expeditedt – toggle bit (only used by SDO normal upload)c – completion (only used by SDO normal upload)
0: downloading
1: successful completion of upload
This protocol (specified in the diagram above) is used to implement the SDO upload
service. SDOs are uploaded as a sequence of several SDO upload segment services
preceded by an “SDO upload initiate” service.
54

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

The SDO upload sequence will be terminated by following occasions:a. An SDO upload initiate response/confirm with the e-bit set to 1, indicating the
successful completion of an expedited upload sequence.
b. An SDO upload segment response/confirm with the c-bit set to 1, indicating the
successful completion of a normal upload sequence.
c. An SDO abort transfer request/indication, indicating the unsuccessful
completion of the upload sequence.
d. A new SDO upload initiate request/indication, indicating the unsuccessful
completion of the upload sequence and the start of a new sequence.
Toggle bit failure:
If in the upload of two consecutive segments the toggle bit does not alter, thecontent of the last segment will be ignored.
If such an error is reported to the application (server to client), the application will
decide to abort the upload.

55

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.5.

SDO Upload Initiate

The client requests the server to prepare the data for uploading by using the SDO
upload initiate service. The multiplexer (index and sub-index) of the data set whose
upload is initiated is indicated to the server.
The protocol as depicted in the diagram below is used to implement the “SDO
upload initiate” service.

ClientrequestServer0byte
bit 7…5
CCS = 2x

bit 7…5
SCS = 2

3

4

m

0

byte

confirmation

1

7

indication

4…0

1

4

3…2

1

0

x

n

e

s

d (data)3m4

7d (data)

Where:
ccs

Client command specifier
2: initiate upload request.

scs

Server command specifier
2: initiate upload responsenNumber of bytes in [d] that do not contain data.
Bytes [8-n, 7] do not contain segment data.
n = 0 if no segment size is indicated.

eTransfer type
0: normal transfer
1: expedited transfersSize indicator
0: data set size is not indicated
1: data set size is indicated56

responsecpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualmMultiplexer – representing the index/sub-index of the data to betransferred by the SDO.

d

Data.
e = 0, s = 0: d is reserved for future use.
e = 0, s = 1: d contains the number of bytes to be uploaded.
Byte 4 contains LSB and byte 7 contains MSB.
e = 1, s = 1: d contains data of length 4-n to be downloaded. The
encoding depends on the type of data referenced by index and
sub-index.
e = 1, s = 0: d contains an unspecified number of bytes to be
uploaded.

x

Not used, always 0.

Reserved

Reserved for future use, always 0.

57

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.6.

SDO Upload Segment

The client requests the server to supply the data of the next segment by using the
SDO upload segment service. The continue parameter ([c]) indicates the client
whether there are still more segments to be uploaded or that this was the last
segment to be uploaded.
Note:
One SDO can only have at most one SDO upload segment service.
The protocol as depicted in the diagram below is used to implement the “SDO
upload segment” service.

ClientrequestServer0byte
bit 7…5
CCS = 3

3…0tx

bit 7…5
SCS = 07

indication
reserved0

byte

confirmation

1

4

1

4

3…1

0

t

n

c

7

response

seg-data

Where:
ccs

Client command specifier
3: upload segment request

scs

Server command specifier
0: upload segment responsetToggle bit, which alternates for each subsequent segment that is
downloaded. The first segment has the toggle-bit set to 0. The
toggle bit is equal for the request and the response message.
58

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualcTransfer type
0: more segments to be uploaded
1: no more segments to be uploaded

seg-data

Maximum seven bytes of segment data uploaded. Encoding
depends on type of data referenced by index and sub-index.

nNumber of bytes in seg-data that do not contain segment data.
Bytes [8-n, 7] do not contain segment data. n = 0 if no segment size
is indicated.

x

Not used, always 0.

reserved

Reserved for future use, always 0.

59cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

6.1.7.

SDO Abort Transfer

The SDO abort transfer service aborts the SDO upload service or SDO download
service of an SDO referenced by its number. The reason is indicated (in byte 4 to 7,
see Table <SDO Abort Codes> on next page).
The service is unconfirmed. Both the client and the server of an SDO may executethe 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.
The protocol as depicted in the diagram below is used to implement the “SDO aborttransfer” service.

Client/Server

Server/Client

request0byte
bit 7…5
CS = 4

1

3

4

7

4…0
x

m

d (data)indication

Where:
cs

Command specifier
4: abort transfer requestX

Not used, always 0.

mMultiplexer – representing the index and sub-index of the SDO.

d

Contains a 4-byte abort code about the reason for the abort.

60

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual<SDO Abort Codes>
Abort code

Description

0x0503 0000

Toggle bit not alternated

0x0504 0000

SDO protocol timed out

0x0504 0001

Client/server command specifier not valid or unknown

0x0504 0002

Invalid block size (block mode only)

0x0504 0003

Invalid sequence number (block mode only)

0x0504 0005

Out of memory

0x0601 0000

Unsupported access to an object

0x0601 0001

Attempt to read a write only object

0x0601 0002

Attempt to write a read only object

0x0602 0000

Object does not exist in the object dictionary

0x0604 0041

Object cannot be mapped to the PDO

0x0604 0042

The number and length of the objects to be mapped would exceed
PDO length

0x0604 0043

General parameter incompatibility reason

0x0604 0047

General internal incompatibility in the device

0x0606 0000

Access failed due to a hardware error

0x0607 0010

Data type does not match, length of service parameter does not
match

0x0607 0012

Data type does not match, length of service parameter too high0x0607 0013

Data type does not match, length of service parameter too low

0x0609 0011

Sub-index does not exist

0x0609 0030

Invalid value for parameter (download only)

0x0609 0031

Value of parameter written too high (download only)

0x0609 0032

Value of parameter written too low (download only)

0x0609 0036

Maximum value is less than minimum value

0x060A 0023 Resource not available: SDO connection
0x0800 0000

General error

0x0800 0020

Data cannot be transferred or stored to the application

0x0800 0021

Data cannot be transferred or stored to the application because of
local control
61

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Abort code

Description

0x0800 0022

Data cannot be transferred or stored to the application because of
the present device state0x0800 0023

Object dictionary dynamic generation fails or no object dictionary ispresent (e.g. object dictionary is generated from file and generation
fails because of a file error)

0x0800 0024

No data available

62

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

7. Process Data Objects (PDOs)
The real-time data transfer is performed by means of "Process Data Objects(PDO)". The transfer of PDO is performed with no protocol overhead.
The PDO corresponds to objects in the 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 object
dictionary.
There are two kinds of use for PDO: data transmission “Transmit-PDO (TPDO)” andthe data reception “Receive-PDO (RPDO)”.
l
CANopen devices supporting TPDO are called PDO producer;
CANopen devices supporting RPDO are called PDO consumer.
ll

PDO are described by these two parameters:
Ø PDO communication parameter - describes the communication capabilitiesof the PDO.
Ø PDO mapping parameter - contains information about the contents of the
PDO.
The structure of PDO communication as well as mapping parameter are
explained in chapter 12 – Objects 0x1400, 0x1600, 0x1800, and 0x1A00.
For each PDO the pair of communication and mapping parameter is mandatory.

63

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

7.1. Transmission Modes
The following transmission modes are distinguished:lSynchronous transmissionlEvent-driven transmission (also “Value-change” for TPDOs, see chapter 7.2.2.)
In order to synchronize CANopen devices, a synchronization object (SYNC) istransmitted periodically by a synchronization application. The SYNC object isrepresented by a pre-defined communication object (see chapter 9). The diagram
below shows the principle of synchronous and event-driven transmission.
<Synchronous and event-driven transmission>
Synchronous
window length

Synchronous
window lengthTime

Sync object

Actuation bas ed on the l ast
received synchronous RPDO at
next sync object

Objects mapped into synchronous RPDO
Event-driven PDOllSynchronous PDOs are transmitted within a pre-defined time-window
immediately after the SYNC object.
Event-driven PDOs are transmitted at any time.

64

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

The transmission type parameter of a PDO specifies the transmission mode as wellas the triggering mode.
l
TPDO:
Ø
For synchronous TPDOs the transmission type also specifies thetransmission rate in form of a factor based on the basic SYNC object
transmission period.
The transmission type 1 means that the message is transmitted withevery SYNC object. A transmission type of n means that the message
is transmitted with every n-th SYNC object. (See chapter 12 – Object
0x1800, sub-index 0x02).
ØEvent-driven TPDOs are transmitted without any relation to the SYNC
object.
l
RPDO:
The data of synchronous RPDOs received after the occurrence of the SYNC object
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 event-driven RPDOs is passed directly to the application.

7.2. Triggering Modes
7.2.1.

Synchronously Triggered

Message transmission is triggered by the occurrence of the SYNC object.
The trigger condition is the number of Sync and optionally an internal event.

7.2.2.

Event-and timer-driven

Message transmission is either triggered by:l
The occurrence of an application-specific event specified in the device profile,application profile or manufacturer-specific, orlA specified time (event-time) which has elapsed without occurrence of an event.
65

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

8. Emergency (EMCY)
Emergency objects are triggered by the occurrence of a CANopen device internal
error situation and are transmitted from an emergency producer on the CANopen
device. Emergency objects are suitable for interrupt type error alerts.
An emergency object is transmitted only once per 'error event'. No further
emergency object is transmitted as long as no new errors occur on a CANopen
device.
Through this specification, error code register is specified as described in chapter 12– Object 0x1001 (Error register). Meanwhile, cpc emergency error codes are definedin the document: cpc Will1/Will1-B Series Installation Guide, see section of
Maintenance/Troubleshoot.

66

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

8.1. Emergency state transition
A CANopen device is in either “error free” or “error occurred” state. (See the figure
below).
<Emergency state transition diagram>start
0
Error free1

4

2
Error occurred

5

3

start

0. After initialization, if no error is detected then the CANopen device enters theerror free state. No error message is sent.
1. The CANopen device detects an internal error indicated in the first three bytesof the emergency message (error code and error register) è The CANopen
device enters the error state.
An emergency object with the appropriate error code and error register istransmitted. The error code is filled in at the location of object 1003h (predefined error field).
2. One, but not all, error reasons is gone è An emergency message containing
error code 0000h (Error reset) is transmitted (meaning the ‘gone’ error reason
is cleared) together with the remaining errors in the error register and in the
manufacturer-specific error field.
3. A new error occurs on the CANopen device è The CANopen device remains inerror state and transmits an emergency object with the appropriate error code.
The new error code is filled in at the top of the array of error codes (1003h).
(oldest error - highest sub-index, see object 1003h).
4. All errors are repaired è The CANopen device enters the error free state andtransmits an emergency object with the error code ‘reset error / no error'.
5. Reset or power-off.
67

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

8.2. Emergency Object Service and Protocol
The emergency object follows the producer/consumer as described in chapter 3.5.2.
The service is unconfirmed; there are zero or more consumers for EMCY.
The EMCY object has exactly one producer.

EMCY producer
requestEMCY consumers
0 1 2 3
eec

er

msef

7

indication
indication
indicationllleec: Emergency error code (see Will1/Will1-B Series Installation Guide)er:Error register (see object 0x1001)
msef: Manufacturer-specific error code (see Will1/Will1-B Series Installation
Guide)

68cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

9. SYNC
This SYNC provides the basic network synchronization mechanism.
The SYNC producer broadcasts the synchronization object periodically.
lll

The time period between the SYNCs is specified by the standard parameter“communication cycle period” (see chapter 12 – Object 0x1006), which may be
written by a configuration tool to the CANopen devices during the boot-up
process. There may be a time jitter in transmission by the SYNC producer
corresponding approximately to the latency due to some other message beingtransmitted just before the SYNC.
The optional parameter counter is used to define an explicit relationshipbetween the current SYNC cycle and PDO transmission (see PDO
communication parameter SYNC start value at chapter 12 – Object 0x1800, subindex 0x02).
In order to guarantee timely access to the network, the SYNC is given a very highpriority CAN-ID (see chapter 12 – Object 0x1005: COB-ID SYNC message).
CANopen devices that operate synchronously may use the SYNC object tosynchronize their own timing with that of the synchronization object producer.
The details of this synchronization are application-specific and do not fall within
the scope of this specification.

69

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

9.1. SYNC Service and Protocol
The SYNC transmission follows the producer/consumer push model.
There is exactly one producer of SYNC and zero or more consumers of SYNC.
The service is unconfirmed. Data type is UNSIGNED8.
The optional parameter counter
The optional parameter counter is incremented by 1 with every transmission. The
maximum counter value is the current value as defined in the “synchronous counter
overflow value” (see chapter 12 – Object 0x1019). Once the maximum value isreached, the counter will be set to 1 with the next transmission.
The initial value of the counter after the NMT service boot-up is 1. The value of thecounter will be reset to 1 if the CANopen device transits from the NMT state stopped
into the NMT state pre-operational or into the NMT state operational.

The protocol depicted as below is used to implement the service of SYNC write.
< Protocol – SYNC write>

SYNC producer

SYNC consumer

requestbyte

0 ≦ Length ≦ 1

CounterCounter: 1 byte of a counter70

indication
indication
indication

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

10. Time Stamp (TIME)The TIME producer broadcasts the time stamp object. This TIME provides the simple
network clock. There may be a time jitter in transmission by the TIME producer
corresponding approximately to the latency due to some other message beingtransmitted just before the TIME. In order to guarantee timely access to the network
the TIME is given a very high priority CAN-ID. CANopen devices that operate a local
clock may use the TIME object to adjust their own time base to that of the timestamp object producer. The details of this mechanism are implementation specificand do not fall within the scope of this specification.

10.1. TIME Service and Protocol
The time stamp object transmission follows the producer/consumer model.
There is exactly one producer of a TIME and zero or more consumers of a TIME.
The service is unconfirmed. Data type is TIME_OF_DATThe protocol depicted as below is used to implement the service of TIME write.
< Protocol –TIME write>

TIME producer

TIME consumer

requestbyte 05Time stamp

Time stamp:
6 bytes of the time stamp object

71

indication
indication
indication

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

11. The EDS
The EDS can be downloaded via SDO segmented transfer. The device which requests
the file reads the Object 0x1021 (Store EDS; see chapter 12) to make the drive keeptransferring data until the drive responds with a message saying no more data fortransfer; in this case the EDS is successfully downloaded to the requesting device
and can be saved to a file.
To download EDS via cpc GUI software, please follow the steps below:
1. Go to Settings > Fieldbus section in the GUI.
2. Click “download” button beside the field Download EDS file.

3. A window will then pop out asking users to allocate a place in the computer tosave the downloaded EDS.

72

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

12. Communication Profile
Object 0x1000: Device typeThis object contains information about the device type and functionality.
It is comprised of a 16-bit field that describes the device profile used, and a second
16-bit field that gives additional information about optional functionality of thedevice.

31llAdditional
information

16 15
0
Device profile
numberObject description
Index

1000

Name

Device typeObject code

Variable

Data type

UINT32

Entry description
Sub-index

0x00

AccessC

PDO mapping

No

Value range

Not applicable. (0x00420192)

Default value

0x00420192

Units

No

73

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1001: Error register
This object provides error information. The CANopen device maps internal errors
into this object. It is a part of an emergency object.
l

Bit definition (M for mandatory, O for optional)
Bit

M/O

Meaning

0

M

Generic error

1O

Current

2O

Voltage

3O

Temperature

4

O

Communication error (overrun, error state)

5O

Device profile specific

6O

Reserved (always 0)

7

O

Reserved

If a bit is set to one, the specific corresponding error has occurred. The only
mandatory bit is bit 0 (generic error) which is signals at any kind of error.
ll

Object description
Index

1001

Name

Error register

Object code

Variable

Data type

UINT8

Entry description
Sub-index

0x00

AccessRO

PDO mapping

No

Value range

0~7

Default value

No

Units

No
74

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1002: Manufacturer status register
This object provides a common status register for manufacturer-specific purposes.
In this specification, only the size and the location of this object are defined.
lValue definition
Bit#

Meaning

0~15

Same as object 0x6041 of DS402

16

External Enable digital input state

17

Motor On flag state

18

Phase Find operation completed successfully

19Home position has been established20

Error Mapping function is active

21

Auxiliary Command is added to internal commands

22~23
24
25~31
l

l

Reserved
Motor is stationary, functionally equivalent to “Speed isequal to 0” Statusword bit during Profile Velocity mode
Reserved

Object description
Index

1002

Name

Manufacturer status register

Object code

Variable

Data type

UINT32

Entry description
Sub-index

0x00

AccessRO

PDO mapping

No

Value range

See value definition

Default value

No

Units

No
75

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1003: Pre-defined error field
This object shows the errors that have occurred on the CANopen device and havebeen signaled via the Emergency object. In doing so, it provides an error history.
lValue definitionØ
The object entry at sub-index 0x00 contains the actual number of the errorsthat are recorded in this array starting at sub-index 0x01.
Note:
If no error is present, the value of sub-index 0x00 is 0 and a read access to
sub-index 0x01 will be responded with an SDO abort message (abort code:
0800 0024h).
ØØØEvery NEW error is stored at sub-index 0x01;
older errors will be moved to the next higher sub-index.
Writing value 0 to sub-index 0x00 will delete the entire history (empties thisarray). In this case, other values than 0 are not allowed and will result in an
abort message (error code: 0609 0031h).
The error numbers are of type Usigned32 and are composed of a 16-bit
error code which is contained in the lower 2 bytes (LSB).

31

16 15
0x000076

0Error codecpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1003

Name

Pre-defined error fieldObject code

Array

Data type

UINT32

Entry description
Sub-index

0x00

Description

Number of error

AccessRW

PDO mapping

No

Value range

UINT8

Default value

No

Units

No

Sub-index

0x01, 0x02, … 0x0F, and 0x10.

Description

Standard error field

AccessRO

PDO mapping

No

Value range

UINT32

Default value

No

Units

No

77

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1005: COB-ID SYNC message
This object defined the configured C0B-ID of the SYNC object.
Also, it defines whether the CANopen device generates the SYNC.

lValue definition< Structure of SYNC COB-ID >
31

30

29

X

gen. frame(0/1) (0)

28

11 10

0

0x00000
11-bit CAN-ID
29-bit CAN-ID of the extended frame< Description of SYNC COB-ID >ØØ

Bit(s)

Value

Description

X

X

Do not care

gen.

0
1

CANopen device does NOT generate SYNC message.
CANopen device generates SYNC message.

frame

0*
1

11-bit CAN-ID valid (CAN base frame) *This bit is always 0.

11-bit CAN-ID

X

11-bit CAN-ID of the CAN base frame

29-bit CAN-ID valid (CAN extended frame)

Bit 29 (frame) is not changeable, it’s always 0.
gen.:Enable SYNC function.
If a CANopen device is not able to generate SYNC message, an attempt
to set bit 30 (gen) to 1 will be responded with the SDO abort transfer
service (abort code: 0x0609 0030).

78

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualØll

The first transmission of SYNC object starts within 1 sync cycle after setting
bit 30 to 1.
By setting bit 30 to 1b while the synchronous counter overflow value isgreater than 0 the first SYNC message starts with the counter reset to 1 (i.e.
counting from 1). While the object exists (bit 30 = 1b) it is not allowed tochange the bits 0 to 29.

Object description
Index

1005

Name

COB-ID SYNC message

Object code

Variable

Data type

UINT32

Entry description
Sub-index

0x00

AccessRW

PDO mapping

No

Value range

0 ~ 0x800007FF

Default value

0x80

Units

No

79

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1006: Communication cycle period
This object shows the communication cycle period. This object defines the time
length of the SYNC cycle.
lValue definition
The value is given in multiple of μsec.
If the value is set to 0x0000 0000 the transmission of SYNC messages isdisabled.
By changing the value from 0000 0000h and the synchronous counter
overflow value is greater than 0 the first SYNC message starts with thecounter value reset to 1.
The transmission of SYNC messages starts within one communication cycle
period (as given by the value) after object 0x1006 is set to the new value.

ll

Object description
Index

1006

Name

Communication cycle period

Object code

Variable

Data type

UINT32

Entry description
Sub-index

0x00

AccessRW

PDO mapping

No

Value range

0 ~ 240

Default value

0x0
μsec

Units

80

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1008: Manufacturer device name
This object shows the device name given by cpc.
lllValue definition
For example, the values may show as Will1-8/230, Will1-B9/230-E, and soon.
Object description
Index

1008

Name

Manufacturer device nameObject code

Variable

Data type

Visible string

Entry description
Sub-index

0x00

AccessC

PDO mapping

No

Value range

Visible string

Default value

Same as the name string shown in cpc UI > Setting >Information > Model.

Units

No

81

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1009: Manufacturer hardware version
This object provides the description of cpc hardware version, such as “00.100”.
ll

Object description
Index

1009

Name

Manufacturer hardware version

Object code

Variable

Data type

Visible string

Entry description
Sub-index

0x00

AccessC

PDO mapping

No

Value range

Visible string

Default value

Same as the name string shown in cpc UI > Setting >Information > Hardware Revision

Units

No

82

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x100A: Manufacturer software version
This object provides the cpc software version description.
ll

Object description
Index

100A

Name

Manufacturer software version

Object code

Variable

Data type

Visible string

Entry description
Sub-index

0x00

AccessC

PDO mapping

No

Value range

Visible string

Default value

Same as the name string shown in cpc UI > Setting >Information > Firmware Revision.

Units

No

83

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1010: Store parameters
This object controls the saving function of parameter in non-volatile memory.
lValue definition
By read access, this object provides information about its saving capacity,using:
ØSub-index 0x00: The largest supported sub-index.
ØSub-index 0x01: Save all parameters.
ØSub-index 0x02: Save Communication related parameters(index from 0x1000 to 0x1FFF).
Ø
Sub-index 0x03: Save Application related parameters(index from 0x6000 to 0x9FFF).
Ø
Sub-index 0x04: Save RS232 parameters.
ØSub-index 0x05: Save Virtual machine program.
Ø
Sub-index 0x06: Save Error-mapping data.

In order to avoid unexpected storage (of parameters), storage is only
executed when a specific signature – save – is written to the appropriate
sub-index.
< Signature of storage write access >Signature MSB
LSB
hex
Ø

e

v

a

s

0x65

0x76

0x61

0x73

Once receiving the correct signature in the appropriate sub-index:
The CANopen device saves the parameter and confirms the SDO
transmission (SDO download initiate response).
For example:
By writing “save” to sub-Index 0x02, the communication
parameters (Object 1000h to 1FFFh) are stored.
84

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

If storing the parameter failed, the CANopen device responds with the
SDO abort transfer service (abort code: 0x0606 0000).
ØØ

Once receiving a wrong signature:
The CANopen device refuses to store and responds with the SDO
abort transfer service (abort code: 0x0800 0022).
On read access to the appropriate sub-index, the CANopen device
provides information about its storage functionality using thefollowing format:< Structure of storage and read access >31

2

reserved(0x0000 0000)

1

0

auto
(0)

cmd
(1)

auto = 0:
cpc CANopen drive does not automatically save parameters.
cmd = 1:
cpc CANopen drive can save parameters on command.
For example:
By reading data of an object entry sub-index 0x02, the cpc driverprovides the value “0x0000 0001” as its information of saving
functionalitylObject description
Index

1010

Name

Store parameters

Object code

Array

Data type

UINT3285

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manuall

Entry description (0x00 ~ 0x06)
Sub-index

0x00

Description

Largest supported sub-index

AccessC

PDO mapping

No

Value range

0x01 ~ 0x7F

Default value

6 (as of firmware version 0.7.15)

Sub-index

0x01

Description

Save all parameters

AccessRW

PDO mapping

No

Value range

See <Signature of storage write access>Default value

1. See <Structure of storage and read access>Sub-index

0x02

Description

Save communication parameters

AccessRW

PDO mapping

No

Value range

See <Signature of storage write access>Default value

1. See <Structure of storage and read access>Sub-index

0x03

Description

Save application related parameters

AccessRW

PDO mapping

No

Value range

See <Signature of storage write access>Default value

1. See <Structure of storage and read access>86cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Sub-index

0x04

Description

Save RS232 parameters

AccessRW

PDO mapping

No

Value range

See <Signature of storage write access>Default value

1. See <Structure of storage and read access>Sub-index

0x05

Description

Save virtual machine program

AccessRW

PDO mapping

No

Value range

See <Signature of storage write access>Default value

1. See <Structure of storage and read access>Sub-index

0x06

Description

Save error mapping data

AccessRW

PDO mapping

No

Value range

See <Signature of storage write access>Default value

1. See <Structure of storage and read access>87cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1011: Restore default parameters
With this object, the default values cab be restored.
lValue definition
By read access, this object provides information about its capability torestore these values, using:ØSub-index 0x00: The largest supported sub-index.
ØSub-index 0x01: Restore all parameters.
ØSub-index 0x02: Restore Communication related parameters(index from 0x1000 to 0x1FFF).
Ø
Sub-index 0x03: Restore Application related parameters(index from 0x6000 to 0x9FFF).
Ø
Sub-index 0x04: Restore RS232 parameters.
ØSub-index 0x05: Restore Virtual machine program.
Ø
Sub-index 0x06: Restore Error-mapping data.

In order to avoid unexpected restoring (of parameter default values),
restoring is only executed when a specific signature – load – is written to
the appropriate sub-index.
< Signature of restore default write access >Signature MSB
LSB
hex
Ø

s

a

o

L

0x64

0x61

0x6F

0x6C

Once receiving the correct signature in the appropriate sub-index:
The CANopen device restores the parameter and confirms the SDO
transmission (SDO download initiate response).
For example:
By writing “load” to sub-Index 0x02, the default values ofcommunication parameters (Object 1000h to 1FFFh) are restored.
88cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

If restoring the default values failed, the CANopen device respondswith the SDO abort transfer service (abort code: 0x0606 0000).
ØØØOnce receiving a wrong signature:
The CANopen device refuses to restore and responds with the SDO
abort transfer service (abort code: 0x0800 0022).
The default values are set as valid after the CANopen device is resetor power cycled.
On read access to the appropriate sub-index, the CANopen device
provides information about its default value restoring capability using
the following format:< Structure of restore default read access >31

1

reserved(0x0000 0000)

0

cmd
(1)

cmd = 1:
cpc CANopen drive restores parameters.
For example:
By reading data of an object entry sub-index 0x02, the cpc
driver provides the value “0x0000 0001” as its information ofrestoring capability.
lObject description
Index

1011

Name

Restore default parameters

Object code

Array

Data type

UINT3289

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manuall

Entry description (0x00 ~ 0x06)
Sub-index

0x00

Description

Largest supported sub-index

AccessC

PDO mapping

No

Value range

0x01 ~ 0x7F

Default value

6 (as of firmware version 0.7.15)

Sub-index

0x01

Description

Restore all parameters’ default values

AccessRW

PDO mapping

No

Value range

See <Signature of restore default write access>Default value

1. See <Structure of restore default read access>Sub-index

0x02

Description

Restore communication parameters’ default values

AccessRW

PDO mapping

No

Value range

See <Signature of restore default write access>Default value

1. See <Structure of restore default read access>Sub-index

0x03

Description

Restore application parameters’ default values

AccessRW

PDO mapping

No

Value range

See <Signature of restore default write access>Default value

1. See <Structure of restore default read access>90

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Sub-index

0x04

Description

Restore RS232 parameters’ default values

AccessRW

PDO mapping

No

Value range

See <Signature of restore default write access>Default value

1. See <Structure of restore default read access>Sub-index

0x05

Description

Restore virtual machine program

AccessRW

PDO mapping

No

Value range

See <Signature of restore default write access>Default value

1. See <Structure of restore default read access>Sub-index

0x06

Description

Restore error mapping data

AccessRW

PDO mapping

No

Value range

See <Signature of restore default write access>Default value

1. See <Structure of restore default read access>91

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1013: High resolution time stampThis object contains a time stamp with a 1-microsecond (1 μsec) resolution.
ll

Object description
Index

1013

Name

High resolution time stamp

Object code

Variable

Data type

UINT32

Entry description
Sub-index

0x00

AccessRW

PDO mapping

Yes

Value range

UINT32

Default value

0
1 μsecUnits

92cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1014: COB-ID EMCYThis object shows the COB-ID for the EMCY write service.
lValue definition< Structure of the EMCY COB-ID >
31

30

29

valid
(0/1)

0

frame
(0)

28

11 10

0x0 0000011-bit CAN-ID< Description of the EMCY COB-ID >Bit(s)

Value

Description

valid

0
1

EMCY exists / is valid

30

0Reserved (always 0)

frame

0*
1

11-bit CAN-ID valid (CAN base frame) *This bit is always 0.

EMCY does not exist / is not valid

29-bit CAN-ID valid (CAN extended frame)

11-bit CAN-ID
X
11-bit CAN-ID of the CAN base frameØ
Bits 29 and 30 are not changeable, they are always 0.
ØWhile the object exists (bit 31 = 1b), it is not allowed to change the bits
0~29.
l

l

Object description
Index

1014

Name

COB-ID EMCY

Object code

Variable

Data type

UINT32

Entry description
Sub-index

0x00

AccessRO

PDO mapping

No

Value range

NODE-ID+0x80 ~ NODE-ID+0x80000080

Default value

NODE-ID+0x80
93

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1015: Inhibit time EMCYThis object indicates the configured inhibit time for the EMCY message.
An error will result in an EMCY message; if several errors occur within a short periodof time this object is used to be the interval time between each EMCY message
transmission.
lllValue definition
This object is given in multiples of 100 um; value 0 will disable the inhibit
time.
Object description
Index

1015

Name

Inhibit time EMCY

Object code

Variable

Data type

UINT16

Entry description
Sub-index

0x00

AccessRW

PDO mapping

No

Value range

UINT16

Default value

0
100 μsec

Units

94

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1016: Consumer heartbeat time
The consumer heartbeat time defines the expected heartbeat cycle time therefore
has to be greater than the corresponding producer heartbeat cycle time (Object
0x1017) configured on the device producing this heartbeat.
Note:
Monitoring of the producer heartbeat will start after the first heartbeat isreceived.
Before receipt of the first heartbeat, the status of the heartbeat producer is
unknown.

lValue definition
31

Ø

Ø
Ø

Reserved
(0)

24 23

16 15
Node-ID

0Heartbeat time

If the heartbeat time is 0 or the Node-ID is 0 or greater than 127 thecorresponding object entry is not used.
The heartbeat time duration is given in multiples of 1ms.
Trying to configure several heartbeat times unequal 0 for the same
Node-ID the CANopen device will respond with the SDO abort transfer
service (abort code: 0604 0043h).

95

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1016

Name

Consumer heartbeat time

Object code

Array

Data type

UINT32

Entry description
Sub-index

0x00

Description

Largest supported sub-index

AccessC

PDO mapping

No

Value range

0x01 ~ 0x7F

Default value

4 (as of firmware version 0.7.15)

Sub-index

0x01 ~ 0x04

Description

Consumer heartbeat time 1, 2,3 and 4

AccessRW

PDO mapping

No

Value range

UINT32

Default value

096cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1017: Producer heartbeat time
The producer heartbeat time defines the configured cycle time (duration) of theheartbeat.

l

l

l

Value definition
This object is given in multiples of 1 ms.
Value 0 will disable the producer heartbeat.
Object description
Index

1017

Name

Producer heartbeat time

Object code

Variable

Data type

UINT16

Entry description
Sub-index

0x00

AccessRW

PDO mapping

No

Value range

UINT16

Default value

0

Units

1 ms

97

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1018: Identity object
This object indicates the general identification information of CANopen device.
The master device needs this object to differentiate CANopen slave devices so as tolater on assign a NODE-ID for each slave.

lValue definitionØ
Sub-index 0x01 contains the unique value that is assigned by CiA to eachmanufacturer of a CANopen device. cpc’s vendor ID value is 0x000003F5.
ØSub-index 0x02 contains the unique value that identifies a specific typeof CANopen devices.
Ø
Sub-index 03h contains the major revision number and the minor
revision number of the revision of the CANopen device (see <Structureof revision number>).
<Structure of revision number>
31
16 15
0
Minor revision number
Major revision number--

The major revision number identifies a specific CANopen behavior.
That means if the CANopen functionality is different, the majorrevision number will be incremented.
The minor revision number identifies different versions of
CANopen device with the same CANopen behavior.

98

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1018

Name

Identity object

Object code

RecordData type

Identity

Entry description
Sub-index

0x00

Description

Number of entries

AccessRO

PDO mapping

No

Value range

4

Default value

4

Sub-index

0x01

Description

Vendor-ID

AccessRO

PDO mapping

No

Value range

UINT32

Default value

0x000003F5

Sub-index

0x02

Description

Product code

AccessRO

PDO mapping

No

Value range

UINT32

Default value

199cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Sub-index

0x03

Description

Revision number

AccessRO

PDO mapping

No

Value range

UINT32

Default value

1

Sub-index

0x04

Description

Serial number

AccessRO

PDO mapping

No

Value range

UINT32

Default value

Unique to each drive100cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1019: Synchronous counter overflow
valueThis object indicates the configured highest value the synchronous counter supports.
This object needs to be implemented by the producer and the consumer.
If the value is greater than 1, the SYNC message data length is 1 byte. (See value
definition chart)
The SYNC consumer ignores the value of SYNC message.
The SYNC consumer cares only about:(1) Receipt of SYNC message, and(2) Data length of a received SYNC message
If isn’t 1 byte, an EMCY message (error code: 0x8240 - unexpected
SYNC data length) will be transmitted by a SYNC consumer.

lValue definition
Value

Description

0

The SYNC message is transmitted as a CAN message
which carries no data (data length = 0).

1

Reserved (it’s meaningless to set value to 1)

2 ~ 240

The SYNC message is transmitted as a CAN message ofdata length 1.

241 ~ 255

Reserved

The counter value keeps incremented up to the overflow value and then wraps
to value 1.
The overflow value used has to be the Least Common Multiple of all the TPDO
transmission types (1 < n < 240) used.

101cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1019

Name

Synchronous counter overflow value

Object code

VAR

Data type

UINT8

Entry description
Sub-index

0x00

AccessRW

PDO mapping

No

Value range

UINT8

Default value

0102cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1021: Store EDS
This object indicates the downloaded EDS file itself.
When this object is read, the drive’s firmware uploads the EDS file via network to
the device requesting for EDS file.
The Electronic Data Sheet (EDS) is an object directory that contains numerous
objects describing the functions and properties of a CANopen device. It assists
CANopen configuration personnel in determining which objects a CAN slave
supports. Also, it is used by network configuration tools to help you identify devices
and easily command them on a network.
The EDS file format is standardized and specified by CiA, enabling all participants of
CANopen systems to read and process the complete and correct device descriptions.

llObject description
Index

1021

Name

Store EDS

Object code

VAR

Data type

DomainEntry description
Sub-index

0x00

AccessRO

PDO mapping

No

Value range

A text file

Default value

No

103

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1022: Store format
Object 0x1022 defines whether the EDS can be compressed or not, which must
be 0, for No compression.

l

l

l

Value definition
This object is given in multiples of 100 um; value 0 will disable the inhibit
time.
<Values for EDS store format>
Value

Description

0x00/ISO10646/, not compressed

Object description
Index

1022

Name

Store format

Object code

Variable

Data type

UINT8

Entry description
Sub-index

0x00

AccessRO

PDO mapping

No

Value range

UINT8

Default value

0104cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1200: SDO server parameter
This object describes the properties of SDO server.
The cpc driver supports one server only.
lValue definition
The number of supported sub-index entries in the SDO object record isspecified by sub-index 0x00.
The values of sub-index 0x01 and 0x02 specify the COB-ID for this SDO.
< Structure of SDO Server COB-ID >
31

30

29

valid
(0)

dyn
(0)

frame
(0)

28

11 10

0

0x0 0000
11-bit CAN-ID
29-bit CAN-ID of the extended frame< Description of SDO Server COB-ID >Bit(s)

Value

valid

0

SDO exists / is valid / is enabled. *This bit is always 0.

0Value is assigned statically. *This bit is always 0.

1

Value is assigned dynamically.

0*

11-bit CAN-ID valid (CAN base frame) *This bit is always 0.

129-bit CAN-ID valid (CAN extended frame)

29-bit CAN-ID

X

29-bit CAN-ID of the CAN extended frame

11-bit CAN-ID

X

11-bit CAN-ID of the CAN base frame

dyn
frame

Description

An SDO exists only if the bit valid (bit 31) of BOTH sub-index 0x01 and 0x02
is set to 0.
The bit dyn (bit 30) of sub-index 0x01 and 0x02 in cpc driver is always 0,
meaning that the values of all sub-indexes of this object are stored in nonvolatile memory.
105

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1200

Name

SDO server parameter

Object code

Variable

Data type

SDO parameter record

Entry description
Sub-index

0x00

Description

Largest supported sub-index

AccessC

PDO mapping

No

Value range

2

Default value

2

Sub-index

0x01

Description

COB-ID client to server (rx)AccessC

PDO mapping

No

Value range

See value definition

Default value

CAN-ID: 0x0600 + Node-ID
frame: 0dyn:0valid: 0

Sub-index

0x02

Description

COB-ID client to server (tx)

AccessRO

PDO mapping

No

Value range

See value definition

Default value

CAN-ID: 0x0580 + Node-ID
frame: 0dyn:0valid: 0106

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1400~0x1403: RPDO communication
parameterThis object describes the communication parameters (i.e., to receive or not) of the
PDOs the CANopen device is able to receive.

lValue definitionØ
Sub-index 0x00 indicates the number of valid object entries within therecord; the minimum value is 2.
Ø
Sub-index 0x01 indicated the COB-ID of the RPDO.
<Structure of RPDO COB-ID>
31

30

29

28

Valid
(0/1)

reserved
(x)

frame
(0)

11 10

0

0x0 0000
11-bit CAN-ID
29-bit CAN-ID of the extended frame<Description of RPDO COB-ID>
Bit(s)

Value

Description

0

PDO exists / is valid / is enabled.

1

PDO doesn’t exist / is not valid.

X

Do not care0*11-bit CAN-ID valid (CAN base frame) *This bit is always 0.

129-bit CAN-ID valid (CAN extended frame)

29-bit CAN-ID

X

29-bit CAN-ID of the CAN extended frame

11-bit CAN-ID

X

11-bit CAN-ID of the CAN base frame

valid
reserved
frame

107

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualØ

Sub-index 0x02 defines the reception character of the RPDO (see<Description of RPDO transmission type>). An SDO abort transfer
service (abort code: 0x0609 0030) will be issued if trying to change thevalue of the transmission type to a not supported value.
<Description of RPDO transmission type>

-

-

Value

Description

0x00 ~ 0xF0Synchronous

0xF1 ~ 0xFD

Reserved

0xFE ~ 0xFF

Event-driven

Synchronous:
The CANopen device activates the received data at thereceipt of next SYNC (see figure below)
Event-driven:
The PDO may be received at any time.
The CANopen device activates the received data immediately.
<Bus synchronization and actuation>
Synchronous
window length

Synchronous
window length

Time
Actuation bas ed on the l ast
received synchronous RPDO at
next sync object

Sync object

Objects mapped into synchronous RPDO
Event-driven PDO
108

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1400 ~ 1403

Name

RPDO communication parameter

Object code

RecordData type

PDO communication parameter record

Entry description
0x14000x14010x1402Sub-index
Description
Access
PDO mapping
Value range
Default value

0x00
Largest supported sub-index
C
No
2
2

Sub-index
Description
Access
PDO mapping
Value range

0x01
COB-ID used by RPDO
RWNo
See value definition
Node-ID +Node-ID +0x80000300 0x80000400

Default value

Node-ID +0x00000200

0x02
Transmission type
RW
No
See value definitionFF

Sub-index
Description
Access
PDO mapping
Value range
Default value109

0x1403Node-ID +0x80000500

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1600~0x1603: RPDO mapping parameter
This object defines the contents (i.e., what to receive) of the PDOs that the CANopen
device is able to receive.

lValue definition
Sub-index 0x00 contains the number of valid object entries within the
mapping record.
<Value of RPDO mapping sub-index 0x00>
Value

Meaning

0x00

Mapping disabled

0x01

Sub-index 0x01 valid

0x02

Sub-index 0x01 and 0x02 valid

0x03

Sub-index 0x01 to 0x03 valid

0x04

Sub-index 0x01 to 0x04 valid

0x05~ 0xFF Reserved

The number of valid object entries is the number of the application object
that is received with the corresponding RPDO.
Received RPDO
Object A Object G ……

Object 0x1600 (RPDO mapping parameter)
Object E

Index

0x1600

number of application objects ( xN )Sub

Object contents

0x00

0x0N

0x01

0x2000-0x01

0x08

...

0x2003-0x03

0x10

0x0N

0x2003-0x01

0x08

number of valid object entries ( =N )110

lengthMappedapplication
objectscpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Sub-indexes 0x01 to 0x04 contain the information of the mapped
application objects. The mapped application objects describe thecontent of the PDO by their index, sub-index, and length (See <The
structure of RPDO mapping> and <The Principle of RPDO mapping>).
The length indicates the length of the application object in bits.
<The structure of RPDO mapping>
31

16 15

Index

8

Sub-index

70

LengthMSB

LSB

Trying to change the value of an object entry to a not-supported value will
be responded with the SDO abort transfer service. Possible causes for a
not-supported value would be:- Mapping (index and sub-index) of a non-existing application
object.
- Wrong length of the mapped application object.
- Wrong length of the PDO.
Dummy mapping:
When there is a need to fill up the length of a RPDO (so as to fit theaccording TPDO) or there is no proper application object, the index and
sub-index will refer to a simple data type as shown in the chart below.
<Data type for dummy mapping>
Index

ObjectName

0x0002DEFTYPE

Integer8

0x0003DEFTYPE

Integer16

0x0004DEFTYPE

Integer32

0x0005DEFTYPE

Unsigned8

0x0006DEFTYPE

Unsigned16

0x0007DEFTYPE

Unsigned32

0x0008DEFTYPE

Real32111

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Remapping procedure:
Used when users need to configure a mapping different from the default
This procedure can take place during the NMT state Pre-operational andduring the NMT state Operational:
1. Destroy RPDO by setting bit valid to 1b of sub-index 0x01 of theaccording RPDO communication parameter (i.e., Object
0x1400~0x1403).
2. Disable mapping by setting sub-index 0x00 of Object 0x1600 to 0.
3. Modify mapping by changing the values of the corresponding subindices.
4. Enable mapping by setting sub-index 0x00 of Object 0x1600 to thenumber of mapped objects.
5. Create RPDO by setting bit valid to 0b of sub-index 0x01 of theaccording RPDO communication parameter.

If during step 3 the CANopen device detects that index and sub-index of
the mapped object does not exist or the object cannot be mapped, the
CANopen device will respond with the SDO abort transfer service (abort
code: 0604 0041h).
If during step 4 the CANopen device detects that the RPDO mapping is not
valid or not possible, the CANopen device will respond with the SDO aborttransfer service (abort code: 0604 0041h).
If the CANopen device receives a PDO which is with more data bytes thanthe mapped data is (length), then the CANopen device will use the firstdata bytes up to the length.

112

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual<The Principle of RPDO mapping>
Received RPDO
ObjectA

ObjectG

Object Dictionary
ObjectE

Object

D

Index

Sub

Object contents

0x16000x00

0x04

0x16000x01

0x2006-0x01

0x08

0x16000x02

0x2011-0x03

0x10

0x16000x03

0x2011-0x01

0x04

0x16000x04

0x2010-0x00

0x04

0x20060x00

0x02

0x20060x01

Object A

0x2006

0x02

Object B

0x2007

0x00

Object C

0x2010

0x00

Object D

0x2011

0x00

0x03

0x2011

0x01

Object E

0x2011

0x02

Object F

0x2011

0x03

Object G(See Object description and Entry description on subsequent pages)

113cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1600 ~ 1603

Name

RPDO mapping parameter

Object code

RecordData type

RPDO mapping parameter record

Entry description
0x16000x16010x16020x1603Sub-index
Description
Access
PDO mapping
Value range
Default value

0x00
Number of mapped application objects in PDO
RWNo
See value definition
1220Sub-index
Description
Access
PDO mapping
Value range
Default value

0x01

Sub-index
Description
Access
PDO mapping
Value range
Default value
Sub-index
Description
Access
PDO mapping
Value range
Default value
Sub-index
Description
Access
PDO mapping
Value range
Default value

1st application object
RW
No
See value definition
0x60400010 0x60400010 0x60400010

0

0x02

0

2nd application object
RW
No
See value definition
0x607A0020 0x60FF0020

00x03
3rd application object
RW
No
See value definition
0
0

0

0

0x04
4th application object
RW
No
See value definition
0
0

0
114

0

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1800~0x1803: TPDO communication
parameterThis object describes the communication parameters of the PDOs the CANopen
device is able to transmit.

lValue definition
Sub-index 0x00 indicates the number of valid object entries within therecord. Its value is 5 since inhibit time and event timer are supported.
<Structure of TPDO COB-ID>
31

30

29

valid
(0/1)

RTR
(1)

frame
(0)

28

11 10

0

0x0 0000
11-bit CAN-ID
29-bit CAN-ID<Description of TPDO COB-ID>
Bit(s)

Value

Description

0

PDO exists / is valid / is enabled.

1

PDO doesn’t exist / is not valid.

1

No RTR allowed on this PDO. *This bit is always 1.

0*11-bit CAN-ID valid (CAN base frame) *This bit is always 0.

129-bit CAN-ID valid (CAN extended frame)

29-bit CAN-ID

X

29-bit CAN-ID of the CAN extended frame

11-bit CAN-ID

X

11-bit CAN-ID of the CAN base frame

valid
RTR
frame

The bit valid (bit 31) is to enable/disable a TPDO in the NMT state
Operational.
115

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

The cpc driver supports the CAN base frame type only and do not support
RTRs; an attempt to set bit 29 (frame) to 1b or bit 30 (RTR) to 0b is
responded with the SDO abort transfer service (abort code: 0609 0030h).
It is not allowed to change bit from 0 to 29 (frame) while the PDO exists
and is valid (bit 31 = 0b).
CANopen devices supporting the enabling (bit 31 = 0b) and disabling (bit31 = 1b) of a TPDO only shall respond with the SDO abort transfer service(abort code: 0x0601 0000) on an attempt to change the values from bit 0
to bit 30.

Sub-index 0x02 defines the transmission character of the TPDO (see Table<Description of TPDO transmission type>). An SDO abort transfer service(abort code: 0x0609 0030) will be issued if trying to change the value ofthe transmission type to a not supported value.
<Description of TPDO transmission type>

-

Value

Description

0x00

Synchronous

0x01

Synchronous (cyclic every sync)

0x02

Synchronous (cyclic every 2nd sync)

0x03

Synchronous (cyclic every 3rd sync)

……

……

0xF0

Synchronous (cyclic every 240th sync)

0x00F1 ~ 0x00FD

Reserved

0x00FE ~ 0x00FF

Value-change

Synchronous:
The PDO is transmitted after the SYNC.
The CANopen device starts sampling data at receipt of SYNC.
Value 0x00 and 0x01: transmit PDO after receipt of SYNC.
116

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual-

Value-change:
The PDO is transmitted at any time when there is change of value
in CANopen device.
Synchronous
window length

Synchronous
window length

Sampling is executed
immediately at receiptof the sync object

Time

Sync object
Objects mapped into synchronous TPDO
Value-change PDO

Sub-index 0x03 defines the Inhibit Time.
The time is the minimum interval time for PDO transmission if thetransmission type is set to 0xFE and 0xFF.
The value is given in multiple of 100 us. Value 0 will disable inhibit time.
When PDO exists (bit 31 of sub-index 0x01 is set to 0), the value of inhibit
time cannot be changed.

Sub-index 0x04 is reserved. It should not be used.
Any read or write access to this entry will lead to SDO abort transfer service(abort code: 0x0609 0011).

117

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Sub-index 0x05 contains the event-timer.
The time is the maximum interval time for PDO transmission if thetransmission type is set to 0xFE and 0xFF. The value is given in multiple of
1 ms. Value 0 will disable the event-timer.
llObject description
Index

1800 ~ 1803

Name

TPDO communication parameter

Object code

RecordData type

PDO communication parameter record

Entry description
0x18000x18010x1802Sub-index

0x00

Description

Largest supported sub-index

AccessC

PDO mapping

No

Value range

2~5

Default value

5

Sub-index

0x01

Description

COB-ID used by TPDO

AccessRW

PDO mapping

No

Value range

See value definition

Default value

0x1803Node-ID +Node-ID +Node-ID +Node-ID +0x40000180

0x40000280

0x40000380

0x40000480

Sub-index

0x02

Description

Transmission type

AccessRW

PDO mapping

No

Value range

See value definition

Default value

0x00FF118

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

0x18000x18010x1802Sub-index

0x03

Description

Inhibit time

AccessRW

PDO mapping

No

Value range

See value definition

Default value0

Sub-index

0x04

Description

Compatibility entry

AccessRW

PDO mapping

No

Value range

See value definition

Default value0

Sub-index

0x05

Description

Event timer

AccessRW

PDO mapping

No

Value range

See value definition

Default value

0x0064119

0x1803

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Object 0x1A00: TPDO mapping parameter
This object contains the contents (i.e., what to transmit) of the PDOs that the
CANopen device is able to transmit.

lValue definition
Sub-index 0x00 contains the number of valid object entries within the
mapping record.
<Value of RPDO mapping sub-index 0x00>
Value

Meaning

0x00

Mapping disabled

0x01

Sub-index 0x01 valid

0x02

Sub-index 0x01 and 0x02 valid

0x03

Sub-index 0x01 to 0x03 valid

0x04

Sub-index 0x01 to 0x04 valid

0x05~ 0xFF Reserved

The number of valid object entries is the number of the application object
that is transmitted with the corresponding TPDO.
Object 0x1A00 (TPDO mapping parameter)
Index

0x1A000x1600TPDO (to be transmitted)
Object A Object G ……

Sub

Object contents

0x00

0x0N

0x01

0x2000-0x01

0x08

...

0x2003-0x03

0x10

0x0N

0x2003-0x01

0x08

Object E

lengthMappedapplication
objects

number of valid object entries ( =N )120

number of application objects ( xN )

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Sub-indexes 0x01 to 0x04 contain the information of the mapped
application objects. The mapped application objects describe the content
of the PDO by their index, sub-index, and length. (See <The structure of
TPDO mapping> and <The Principle of TPDO mapping>).
The length indicates the length of the application object in bits.
<The structure of RPDO mapping>
31

16 15

Index

8

Sub-index

MSB

7

0

LengthLSB

Trying to change the value of an object entry to a not-supported value will
be responded with the SDO abort transfer service. Possible causes for a
not-supported value would be:- Mapping (index and sub-index) of a non-existing application
object.
- Wrong length of the mapped application object.
- Wrong length of the PDO.

121

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

Remapping procedure:
Used when users need to configure a mapping different from the default.
This procedure can take place during the NMT state Pre-operational andduring the NMT state Operational:
1. Destroy TPDO by setting bit valid to 1b of sub-index 0x01 of theaccording TPDO communication parameter (i.e., Object
0x1800~0x1803).
2. Disable mapping by setting sub-index 0x00 of Object 0x1A00 to 0.
3. Modify mapping by changing the values of the corresponding subindices.
4. Enable mapping by setting sub-index 0x00 of Object 0x1A00 to thenumber of mapped objects.
5. Create TPDO by setting bit valid to 0b of sub-index 0x01 of theaccording TPDO communication parameter.

If during step 3 the CANopen device detects that index and sub-index of
the mapped object does not exist or the object cannot be mapped, the
CANopen device will respond with the SDO abort transfer service (abort
code: 0604 0041h).
If during step 4 the CANopen device detects that the RPDO mapping is not
valid or not possible, the CANopen device will respond with the SDO aborttransfer service (abort code: 0604 0041h).

122cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual<The Principle of TPDO mapping>>
Object Dictionary
Index

Sub

Object contents

0x1A000x00

0x04

0x1A000x01

0x2006-0x01

0x08

0x1A000x02

0x2011-0x03

0x10

0x1A000x03

0x2011-0x01

0x04

0x1A000x04

0x2010-0x00

0x04

0x20060x00

0x02

0x20060x01

Object A

0x2006

0x02

Object B

0x2007

0x00

Object C

0x2010

0x00

Object D

0x2011

0x00

0x03

0x2011

0x01

Object E

0x2011

0x02

Object F

0x2011

0x03

Object G

TPDO
ObjectA

ObjectG(See Object description and Entry description on subsequent pages)

123

ObjectE

ObjectDcpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication ManualllObject description
Index

1A00 ~ 1A03

Name

TPDO mapping parameter

Object code

RecordData type

PDO mapping parameter record

Entry description
0x1A00

0x1A01

0x1A02

0x1A03Sub-index
Description
Access
PDO mapping
Value range
Default value

0x00
Number of mapped application objects in TPDO
RW
No
See value definition
1222

Sub-index
Description
Access
PDO mapping
Value range
Default value

0x01

Sub-index
Description
Access
PDO mapping
Value range
Default value
Sub-index
Description
Access
PDO mapping
Value range
Default value
Sub-index
Description
Access
PDO mapping
Value range
Default value

1st application object
RW
No
See value definition
0x60410010 0x60410010 0x60410010 0x60410010
0x02

0

2nd application object
RW
No
See value definition
0x60640020 0x606C0020 0x606C0020
0x03
3rd application object
RW
No
See value definition
0
0

0

0

0x04
th

4 application object
RW
No
See value definition
0
0

0
124

0

cpc Will1/Will1-B Servo Drive – CiA 301 CANopen Communication Manual

13. Initial CAN Communication Setup
In order to program the communication parameters, communication must first be
established with the servo drive (*note), so that the RS-232 communication channel,
which is always active, can be used. After RS-232 channel is set up, use the cpc GUI(graphic user interface) software to configure baud rate and Node-ID as described
as below.
1. Follow the manual of cpc GUI user guide to install the software.
2. Go to the Settings > Fieldbus section in the GUI and configure the parametersof “Persistent Node-ID” and “Persistent Baud Code”.

llPersistent Node-ID: ranges from 1 to 127.
Persistent Baud Code: select the preferred desired baud rate.

3. Click “Save Node-ID” button to save settings.
The panel on the right side shows the content of Object 0x1018. The masterdevice needs this information to differentiate from salve devices.
*Note: Users can also set up baud rate and Node-ID according to the methods
stated in CiA DS305.
End of Document125