Setup and configuration of a CANopen sub‐system

(1)

PRODUCT

APPLICATIONNOTE 174

01.10.2018 DFF-FO_0284 Seite 1 von 35

Setup and configuration of a CANopen sub‐system

Summary

This is a short introduction to the basics of CAN communication.

Chapter CAN‐Overview (page 2) summarizes the basics of CAN communication.

Chapter CANopen‐overview (page 10) presents the services defined in a CANopen environment. The typi‐

cal sequence of CAN messages during start and operation of a CANopen environment is shown.

The startup of a CANopen sub‐system is explained starting from page 25.

The last chapter – robust configuration (page 29) gives some advice about the robust configuration of CANopen and a CANopen servo‐drive.

Applies To

All FAULHABER MotionControllers and MotionControl Systems having a CANopen interface.

Glossary

CAN-controller The message frame is fixed and is generated by dedicated CAN controllers, which meanwhile are typically integral part of a µController. In the early days of CAN stand‐alone CAN‐controllers like the SJA 1000 have been combined with general‐

purpose controllers.

CANopen master In a CANopen system, there is typically exactly one CANopen master and several CANopen slaves.

The main task of the CANopen master is to monitor the network, configure the slaves if necessary and step through the different stages of the initialization.

Application master While the CANopen master is responsible for the communication according to the CANopen protocol the application master will be the one to really use the data and start any behavior of the slaves

node An otherwise unspecified device connected to a CAN. Could be a master or slave SOF Start Of Frame of a CAN message

Component A device within a machine. Could be a drive, a sensor, …

PLC The programmable logic controller. A component, which typically includes the application master and the CANopen master.

(2)

Faulhaber Product Application Note 174 Seite 2 von 35

Description

CAN Overview

BOSCH introduced Controller Area Network as an automotive network back in the middle of the eighties.

Messages are exchanged using a single pair of wires analog to a RS485 interface. The transmission of the bits is differential using the lines CANH and CANL. If there is no message present, the voltage levels on both lines should be around 2.5V. An active bit will result in a differential signal of typically 1V.

The physical interface of a CAN is a voltage signal. Therefore – as in a RS485 environment – a common ground (GND) is also required. The GND levels within a CAN must not exceed a level of ±2V.

Connection of two CAN nodes CAN – logical and electrical

CAN Frame

The message frame is fixed and is generated by dedicated CAN controllers, which meanwhile are typically integral part of a µController. In the early days of CAN stand‐alone CAN‐controllers like the SJA 1000 have been combined with general‐purpose controllers.

Arbitration field

As all the participants are connected in parallel, frames might collide if more than one controller starts a transmission after the minimum idle time of the bus.

CAN uses a specific bus access mechanism, called carrier‐sense multiple access with collision resolution (CSMA/CR). The access to the bus is granted based on the identifier of a message which is coded in the arbitration area of the CAN‐frame.

CANH

CANL

GND CAN_TX

CAN_RX

CAN_TX

CAN_RX

CANH

CANL

CAN_TX CAN_RX

SOF Arbitration Control Data CRC ACK EOF

Figure 1

Figure 2 CAN-Frame

(3)

The identifier field carries either 11 bits or 29 bits. In a CAN environment without any additional protocol definition messages are identified by their identifiers only. In CANopen environments 11 bits identifiers are used. This allows for 2048 different messages to be used. The identifier is used by the nodes to identify the message and by the CAN‐controllers to gain the bus access. The message having the lowest identifier will win the arbitration. During the arbitration several CAN controllers could write their message identifier to the bus. The message with the lowest identifier will be dominant; the other nodes will stop their access and will listen only. To avoid collisions every message, identified by a specific identifier, should be assigned to a single sender.

Data and Control

A CAN frame can have a payload of 0 to 8 bytes of data. The actual length is coded in the Control field. Of course, there has to be an agreement between the interacting nodes how to interpret the contents of the data part. This is one of the responsibilities of the CANopen protocol.

Remote Transfer

CAN offers a special request – response mechanism even at the very low level. There is a so called Remote Transfer Request (RTR) bit within the control field. It is used to send a request for s specific message. The message is identified by its message id. If this feature is used, the requesting node will send a message with the expected Id having the RTR bit set. The data length is 0. The node responsible for the message having this Id shall react be sending the requested message – and of course in case of the response there will be some data. The response itself is however outside the responsibility of the CAN controller itself and will typically be prepared by some kind of driver firmware.

CRC and ACK

A CAN message is protected by a CRC. Every CAN‐controller in a system will receive the frame and check the CRC. If the frame is received successfully the receiving nodes will write a dominant bit into the ACK field. Otherwise – if an error has been detected – the receiving controller will destroy the frame by sending dominant bits. These frames are called error frames. Monitoring tools will typically indicate the number of observed error frames. Standard CAN controllers will discard error frames automatically but will count their number.

A sending controller can therefore check, whether the frame has been transmitted successfully by reading the ACK field. If there is no dominant ACK it will re‐send the frame until it is acknowledged.

This is a very powerful mechanism. As all the nodes connected to a CAN sub‐system will listen and receive all the messages either all or no node will receive a message. If it has been disturbed, there will be no

Node A Node B Node C ... Node N

Figure 3 CAN as a network of equals

(4)

Faulhaber

acknowl mission

Termina Due to t fectly sy flections a linear placeme

Baud r

All node FAULHA Baud‐rat

100 80 50 25 12 5 2 1 Figure

Table 1

r Product Applic

edge and th can be assum

ation Resist this synchron ynched. This

s at the end CAN system ent and value

A C sh T

rates and

es in a CAN BER MotionC

te M

00 kbit/s 00 kbit/s 00 kbit/s 50 kbit/s 25 kbit/s 50 kbit/s 20 kbit/s 10 kBit/s

4 CAN fram

baud-rate

cation Note 174

he sender wi med as soon

tors

nization dow is done by a of the netwo m this would

e of the term As a first test AN_H and CA hould be app his is possibl

bus topol

sub‐system Controllers a MC V2.5



 mes

es supporte

ll resend it.

as the local

wn to the AC a re‐synchro ork have to b be a 120

mination resis t of a CAN s AN_L. If both t proximately le only when

ogy

have to use are:

MC V3.0



‐



 ed by FAUL

So – even w CAN contro

CK bit, the di onization dur

be avoided. T resistor at stors might h system you termination 60.

n the system

e the same p

LHABER C

without an ex ller signals th

fferent CAN ring the SOF Therefore, te each end of have to be o

might check resistors ar

is electricall

preconfigure

CANopen co

xplicit hands he message t

‐controllers F. To allow fo

ermination r f the networ ptimized ma k the resista e present, t

y switched o

d baud‐rate

ontrollers

shake the su to be sent.

must be mo or this synch resistors are

rk. In non‐lin anually.

ance measur the measure

off.

e. Supported

Seite 4 von 3

uccessful tran

ore or less pe hronization r

mandatory.

near CANs t

red between ed resistance

baud‐rates

35

ns‐

er‐

re‐

In the

n e

of

(5)

Faulhaber

Due to t speed th The theo more co be more checked

Conne

Differen CANope tools. Th Pin 2 3 7

The phy sion. The the symm

Monito

All CAN a monito Table 2

the bit‐length he maximum

oretical topo mplex. Ther e challenging

during com

In m m In C as T

ectors and

t devices m n standard C he minimum

Signal CAN_L GND CAN_H

sical layer of e signal lines metry. CAN g

oring

nodes in a s oring node, t 2 Default pi

cation Note 174

h, the allowa m length of th

ology is a lin e are branch g to find an missioning. I n a simple C more comple modular syste

n these case AN sub‐syste s well. Some here is no tr

d wiring

ight offer di CiA 102 [1]

wiring here Desc CAN CAN CAN

f the CAN us s within a CA ground is als

ub‐system a typically a PC in-out of a

able length o he CAN is 30m

ear system w hes and tree

appropriate Ideally there CAN sub‐syst

x situations w em has to be

s CAN repea ems to a sin e of these dev

ansport laye

fferent CAN specifies a 9 is:

cription _L bus line ( ground _H bus line (

ses a differe AN cable the so necessary

re electrical C connected CAN (D-su

of a CAN sub m.

with all the structures.

e terminatio e should not

tem all nod when differe e designed.

aters can be ngle CAN. Th vices are eve er defined fo

N connector 9 pin D‐Sub

dominant lo (dominant h

ential transm erefore have to have a co

ly connected to the CAN u ub 9)

b‐system dep

nodes conne In these mor on. Generally be error fram es are conn ent parts of a

e used to co ese repeate en offering li r a CAN syste

types, depe connector w

ow) igh)

mission to inc e to be in a ommon GND

d in parallel.

using a stand

pends on the

ected in para re complex s y, the rate o mes at all.

ected to the a machine ha

nnect differe rs can provid mited routin em.

nding on the which is typ

crease the ro twisted pair D potential fo

Therefore, i dard CAN‐to‐

e baud‐rate.

allel. Practic systems, it m

of error fram

e same GND ave to be co

ent, electric de a galvani ng functiona

eir sizes and pically used f

obustness of r configuratio or the transc

it is always p

‐USB conver

Seite 5 von 3

At the highe

cal systems a might therefo mes has to

D. There are nnected or a

al separated c decoupling lity.

d housing. T for monitori

f the transm on to preser

eivers.

possible to a ter.

35

est

are ore be

e a

d g

The ng

mis‐

rve

dd

(6)

Faulhaber

There is ware de



 S



Even if i generally nectors existing Figure

a variety of livered toget Logging the t Sending a CA Filtering the

T co T

t is possible y is a good in parallel. T system.

Node

5 Adding a

cation Note 174

f CAN monito ther with the traffic & sav AN message traffic to all

he FAULHAB onverter too he supporte

 IXXAT

 Peak

 ESD

 EMS

e to add a PC idea to have These cables

A

a monitor n

oring and an e CAN‐to‐US

e the log to a manually ow for a mo

BER Motion o.

d solutions a T

C via a CAN‐

e access to a are handy i

Node B

node to the

nalyzing tool B converter.

a text based

re focused a

Manager ca

are:

‐to‐USB conv a pre‐config if you need t e CAN

s available. T . Required fu

file

analysis of a s

an be conne

verter, some ured CAN ca to connect y

CAN USB

Typically, the unctions are:

single contro

ected to a C

e pre‐requisi able having d your PC or an

...

ere is simple :

oller

CAN using a

ites might b different 9‐p ny additiona

Node

Seite 6 von 3

e monitor so

CAN to USB

e necessary.

pin D‐Sub co al node into

N

35

oft‐

B

. It on‐

an

(7)

Figure 6 Test equipment for a CAN environment

(8)

Communication Patterns

While CAN itself does only describe the physical layer and the coding and handling of the messages itself, higher layer protocols such as CANopen use additional patterns to implement their services.

Client – Server

In a client‐server pattern there is one server which does offer services (such as controlling a motor) or data (such as an actual position) and there is a client which wants to use the services, read the data or change any settings of the server.

The communication is initiated by the client, which sends a request to the server. The server might re‐

spond in different ways – moving something, … . But at least the request is acknowledged by a response.

The response might be on the quality of a simple "ok" or might transmit a requested value.

In the CANopen environment the client server pattern is used to read and write any of the drives parame‐

ters – the SDO service (see page 14).

Publisher ‐ Subscriber

Client Server

Request

Response

Publisher Subscriber

Message

Subscriber Subscriber Broker

Message

Figure 7

Figure 8

(9)

In a publisher –subscriber pattern the publisher provides some data, cyclically or in reaction to a specific event. In an IoT environment the publisher itself would be logged into a broker and send the data to the broker, where any number of subscribers could be logged in and read the data. Additional measures might be necessary to ensure the successful transmission.

Producer ‐ Consumer

In a CAN system publishing this is much simpler. A producer can send a set of values packed into a mes‐

sage. The quality of transmission is guaranteed by the basic CAN mechanisms. Due to the structure of the CAN, all the connected nodes can decide, whether to use it or to ignore it.

The only prerequisite then is, all the listening nodes – the consumers ‐ have to be aware of the structure of the data coded into the message.

In a CANopen environment the producer – consumer pattern is used during the active operation of the system to exchange the process image using the PDO service (see page 16). The process image is the set of predefined parameters to be used to control the application.

Producer Subscriber

Message

Subscriber Consumer

Figure 9

(10)

CANopen Overview

Master and Slaves

CAN is a peer‐to‐peer solution – no roles are defined. CANopen is an industrial application of the CAN.

Industry comes with hierarchy. Here there are defined roles – one of the nodes is the master.

In a CANopen system there is typically exactly one CANopen master and several CANopen slaves (Figure 10). The slaves are identified by a node address within a range of 1…127. The node address 255 indicates an unconfigured slave which will only start its services, when a valid node address is assigned.

The main task of the CANopen master is to monitor the network, configure the slaves if necessary and step through the different stages of the initialization.

After the initialization, the master will typically be the node to generate the cyclic SYNCH signal which starts the repeating communication cycles.

Additionally the master might also incorporate an application specific master – which in most cases is a PLC. While the CANopen master is responsible for the communication according to the CANopen protocol the application master will be the one to really use the data and start any behavior of the slaves.

The slaves might be different devices – here motor controllers – but could also be sensor‐nodes or general I/Os. Before these slaves start their operation, their communication functions have to be started by the CANopen master. The services of the Network Management (NMT) are used here.

Communication Services

The CANopen communication services and mechanisms are defined in the CiA 301 standard [2].

The common functions and parameters of a servo‐drive are defined in the CiA 402 standard [4], while a general purpose I/O module is defined in the CiA 401 standard [3].

Within a CANopen environment the CAN‐message‐Ids of certain services are referred as COB‐Ids.

Master

Slave A (Address 5)

Slave B (Address 7)

Slave N (Address 30) ...

Figure 10

(11)

NMT – Start the communication and supervise the stability

The NMT services are used to detect newly started slaves, to start the communication of a slave and to supervise their state.

Initialization (0x00)

During the reset or boot of a slave the slave will internally be in the Initialization state. After the basic ini‐

tialization is finished it will change into the pre‐operational state of the communication.

A boot message is sent by the slave during this transition.

Pre‐Operational (0x7F)

A slave being in the pre‐operational state is ready to be configured. SDO service to read and write parame‐

ters is supported. The drive function of a CANopen operated servo drive will however refuse to be enabled unless the communication state is switched to the operational state.

Operational (0x05)

When in operational state the PDO mechanism to exchange the process image – the actual‐ and target‐

values is enabled. The drive function of a CANopen operated servo drive can now be enabled.

Stopped (0x04)

In stopped state of the communication no access to the parameters is possible. No SDO service is available in this state.

Initialization (0x00)

Pre‐Operational (0x7F)

Stopped (0x04)

Operational (0x05)

(1) (2)

(3)

(boot) (3)

Figure 11 NMT state machine

(12)

NMT Identifiers and commands

Basically there are two CAN messages or message ranges used by the NMT.

COB‐Id Description

0x000 Used by the CANopen master to switch the slaves between their communication states.

The NMT message is a CAN message having a length of two data bytes:

command address

If an address in the range of 1 … 127 is used, a single node is addressed. An ad‐

dress of 0 will be executed by all nodes.

The complete set of commands can be found in the FAULHABER CANopen man‐

ual. The main commands found in CANopen logs are:

0x01: start node (1)

0x80: switch to pre‐operational (2) 0x81: reset node (3)

0x700 + Node‐Id Used by the slaves to indicate their communication state

This is a message having a length of one data byte where the actual communica‐

tion state is transmitted. It is used either as a boot message, during node guard‐

ing or within the heartbeat protocol.

NMT state

Guarding or Heartbeat

There are two alterative mechanisms to supervise the communication state of the slaves.

Node‐Guarding is triggered by the CANopen master. It's using a client‐server pattern.

Parameters at each slave are the guarding time and the life‐time‐factor.

The master will send a guarding request after the configured guarding time, which the slave has to answer with its actual communication state as a payload.

The details are a little more complex as the request is done using a remote‐transfer‐request. A request and response share the same identifier. Additionally the MSB of the node state has to be toggled at each re‐

sponse.

In a log this would be:

 701 RTR

 701 05 // state is operational

…

 701 RTR

 701 85 //still operational but with a toggled MSB Table 3 NMT messages and commands

(13)

Faulhaber

 701 R

 701 0

… If there The life‐t lost.

Heartbe used ide The hea defined the appl

C

Bootup

NMT

Figure

RTR

05

is no respon time factor d

eat messages entifier is the rtbeat cycle period eithe ication (slav

H su

CANopen Master

p

12

cation Note 174

//still op

nse to the re defines the m

s are sent by e same as for can be conf er the maste e side) or try

Heartbeat and ub‐systems t

Boot 1 By tran

NMT 2 by Byte Byte cont

erational bu

quest, the m maximum nu

the master r the node gu figured for b er or the slav y to restart th

d node‐guar the message

tup message at yte data: 0x00 nsmitted once af

T Message at CA yte data

e 1: command e 2: adressed no trols the NMT st

ut again with

master will se umber of ret

or the slave uarding. So it both directio

ve will consi he slave (ma

ding use a lo s might not

0x700 + NodeId fter the start of

AN Id 0x00

ode or 0 (broadc tate machine of

a toggled M

end a next r tries before t

as a simple t's either no ns. If no hea der the com aster side).

ow prio mess be transmitt

d

the controller

ast)

f the connected

MSB

equest after the commun

indication – de guarding artbeat mess mmunication

sage identifie ted due to ar

CANop Driv

drives

r the next gu nication is co

no request or heartbea sage is recei to be lost a

er. In highly rbitration los

pen e

Seite 13 von 3

uarding perio nsidered to

necessary. T t.

ved within t and might st

utilized CAN sses.

35

od.

be

The

the op

(14)

SDO – Read and write parameters of a CANopen slave

In a CANopen servo‐drive all the parameters of the system are collected in a so called object dictionary (OD). Whatever sub‐function is addressed; they all have their parameters collected there. So the OD is the collection of all parameters, references, control inputs and actual values of the drive.

Any access to the application is routed via one of the parameters collected in the OD. Consequently the parameters are referred as objects. The basic operation here is a read‐ or write‐access to the parameters collected here – read object and write object. So basically to interact with such a drive will result in a se‐

quence of read and write commands such as:

 Set Target Velocity to xxxx

 Read Actual Velocity

 …

I/O and HW Driver - +

ObjectDictionary

Device Control

Error Handling Drive Diagnostics

Feedback Control

Commincation Interfaces Local Scripting

Figure 13 Overview over the major software parts of a FAULHABER MotionController

(15)

All parameters/objects are identified by a 16 bit index – the parameter number and a 8 bit sub‐index, al‐

lowing for structured parameters.

Simple Parameter Structured Parameter

Idx Sub Parameter

0x607A 00 Target Position

0x60FF 00 Target Velocity

0x2311 00 Digital I/O entries 01 Logical Input State

02 Physical Input State

03 Output State

The mechanism used for this simple sequential access is the Service‐Data‐Object (SDO). SDO is a client server type of communication where the master – PC or PLC – is sending a request to read or write a single parameter to the client. The drive is the server. It will execute this read or write and will answer with a response.

There is one dedicated COB‐Id per node for the request (0x600 + NodeId) and one for the response of the drive (0x580 + NodeId).

So the benefit of the SDO transfer is, after having received the response the automation master will have a confirmation of the executed parameter access. The drawback is, it will take some time. So if for example a target value will have to be updated, it's a little more complex than writing the updated value to a direct output of the PLC.

The SDO mechanism is typically used during the preoperational state of the NMT to configure a drive or adjust the drive's communication settings.

1 The CiA defined ranges for the parameters of a CANopen node. The range 0x1xxx is reserved for communication related parameters out of the CiA 301 standard. The parameters starting from 0x6000 are reserved for the device profile. CiA 402 defines the servo‐drive profile and its parameters. The parameter range in between (0x2000 … 0x5FFF) is reserved for manufacturer specific parameters like I/O configuration or control parameters.

Table 4¹

(16)

Industrial CANopen PLCs or gateways used as the master of a local CANopen sub‐system will typically offer to write the communication settings of all services (PDO, SYNCH, Node‐Guarding) before starting the node into the operational state.

PDO ‐ exchange the process image

The Process Data Object (PDO) service is used to exchange the process image after the initial configuration is done and the slaves have been switched into the operational state of the communication. The PDO ser‐

vice is available in operational state only.

Where the SDO can address a random but single parameter with each access, a message used as a PDO can combine different values into a single message – provided the data‐length will fit into the 8 byte limit of a single CAN message.

So it is possible to combine the parameter controlword (16‐bit), used to control the main behavior of a CANopen servo‐drive the selected mode of operation (8‐bit) and any of the target values like the target‐

position (32‐bit) or the target‐speed (32‐bit) in a single message.

PDOs are distinguished between the one to be received by a node (RxPDOs) and the ones to be sent by a node (TxPDOs).

CANopen Master

CANopen Drive

read or write access to any parameter at 0x600 + NodeId transmission of the command + address of the parameter + write data (max 4 byte)

SDO response at 0x580 + NodeId transmission of max 4 byte of read data

SDO OD

CMD Idx Sub Data

Figure 14

(17)

RxPDOs of a CANopen servo‐drive TxPDOs of a CANopen servo‐drive

PDOs are implemented using the Producer‐Consumer pattern. So each node sends its PDOs, the others can be consumers and receive and process the data. There is no explicit handshake implemented by the com‐

munication service itself. However, being in a CAN environment, we can at least assume the message to be received as soon as we were able to send it. A PDO is therefore very close to the original intention of raw CAN. A challenge of course is: as there is no information within the CAN message itself, which parameters are combined, the producer and the consumers need to have a sort of agreement, which combination is to be expected at which message identifier. Every PDO has its own message Id by which it will be identified by the consumers.

The agreement about the payload is called PDO mapping. This is a set of parameters stored at each CAN‐

node which describes the mapping of parameters into the supported PDOs per direction.

In the example above the mapping would be:

CW Op TargetPosition TargetVelocity Profile Velocity

Profile Acceleration Profile Deceleration

Rx 0x200 + NodeId

0x300 + NodeId

0x400 + NodeId

SW Op

Actual Postion Actual Velocity

Tx

0x180 + NodeId

0x280 + NodeId

Figure 15

(18)

Faulhaber

RxPDO 1

 0

 0 RxPDO2

 0

 0 RxPDO3

 0

 0 RxPDO4



As every system i Figure and alte

1 (0x200 + No 0x60FF.00 – 0x6081.00 – (0x300 + No 0x6083.00 – 0x6084.00 – (0x400 + No 0x6040.00 – 0x6060.00 – 0x607A.00 – (0x500 + No Not used

T

T o p If fu e Ty

y node has it is the autom 16 Examp ernatively

cation Note 174

odeId) 32 Bit – 32 Bit odeId) – 32 bit – 32 bit odeId) – 16 bit – 8 bit – 32 bit odeId)

The length of

he mapping

he mapping f the commu orarily no lo f a PDO has t urther updat rs is update ypically PDO

ts own set o mation maste

le mapping in Profile V

f a PDO depe actual leng Receivers w

information

information unication. Ot nger have a o be remapp tes. Only afte it may be act O mapping is

f PDOs and er. The peer

g of a CAN Velocity Mo

Tx

ends on the gth of a PDO ill usually ch

n is a part of t the 0x1xx

of a PDO m therwise the

common un ped it has to er the mappi tivated again static a soon

COB‐Ids the nodes will n Nopen serv ode

xPDO 1 (0x18

 0x604

 0x606 xPDO2 (0x28

 0x606

 0x606 xPDO3 (0x38

 Not us

xPDO4 (0x48

 Not us

number of b can be in be eck for the c

the commun xx paramete

ust not be ch e producer an derstanding

be set into a ing informat n.

n as the pre‐

typical cons not process vo-drive op

80 + NodeId) 1.00 – 16 bit 1.00 – 8 bit 0 + NodeId) 4.00 – 32 bit C.00 – 32 bit 0 + NodeId) sed

0 + NodeId) sed

ytes used in etween 1 and correct lengt

nication relat er range.

hanged durin nd the consu of the coded an invalid sta

ion of the pr

operational

sumer of a T the PDOs of perated in ) t

t t

the data sec d 8 bytes.

th of a PDO.

ted paramet

ng the opera umers will at

d informatio ate first whic roducer and

state is left.

TxPDO in suc f the other n

Profile Po

Seite 18 von 3

ction. So the

ters stored in

ational state least tem‐

on.

ch prevents all consum‐

ch an CAN su nodes, as th osition Mod

35

e

n

ub‐

eir de

(19)

Faulhaber

RxPDOs tomation ter whic

If a direc modified

Therefor configur

(A

Figure

are configur n master via h then conne

ct peer‐to‐pe d, to be able

re, even if a ration.

If ad ti N N ti N ti

Slave A Address 2)

Rx: x02 Tx: x82

Slave A Address 2)

Rx: x02 Tx: x82

17 Default

cation Note 174

red for a diff a the CANope ects the diffe

eer commun to directly p

peer‐to‐pee

f a peer‐to‐p djusted. So i on could be Node 2: defau Node 3: one o fier assigned Node 4: one o

fier assigned

M

Rx₄: 2

PDO COB-

ferent COB‐

en master (F erent parts o

nication is to process a me

er exchange

eer exchang f the nodes :

ult identifiers of the RxPDO d to RxPDO4

of the RxPDO d to RxPDO2

Master

Slave B (Address 3)

Master

Slave B (Address 3) 282

-Id within a

Id. The same Figure 17). S of informatio

o be used, th essage sent b

would be po

ge shall be us 3 and 4 sha

s – here TxP Os has to list

would no lo Os has to list would no lo

Rx: x03 Tx: x83

Rx: x03 Tx: x83 R

a CANopen

e applies for So it is usual on together t

e default CO by a peer‐nod

ossible it typ

sed, the iden ll receive the

DO2 @ 0x28 ten to Node onger be 0x50

ten to Node onger be 0x20

Slave C (Address

Slave C (Address x₂: 282

n subsyste

r RxPDOs. Th ly a virtual 1 to create a sy

OB‐Ids of som de ().

pically is not

ntifiers used e 2^nd TxPDO

82

2: e.g. RxPD 03 but 0x282

2: e.g. RxPD 04 but 0x282

4) Rx: x04 Tx: x84

m.

hey will be s 1:1 connectio

ynchronized

me ot the PD

used and re

for the PDO of node 2 th

DO4. Therefo 2.

DO2. Therefo 2.

Seite 19 von 3

sent by the a on to the ma

behavior.

DOs have to

equires manu

Os have to be he configura‐

ore, the iden‐

35

au‐

as‐

be

ual

e

‐

(20)

Faulhaber

SYNCH

The typi zero leng The SYN pending PDOs ca called th Type

1 … 2 2 2

The tran

Event‐T

The even 255 – as vidually A PDO h word an

EMCY –

The EMC a high pr The leng CANope For a FA the CAN Table 5

– trigger t

cal data exc gth synch me NCH interval

on the num an be configu he transmissi

Descri 0 PDO w 240 PDO w 253 The PD 255 PDO w

nsmission typ

T o ch M th

Timer – an

nt‐timer of a synchronous

for each TxP having a tran d then cyclic

– in case of

CY Object is a rio COB‐Id (0 gth of an EM

n standards AULHABER M open device 5 PDO trans

cation Note 174

he exchan

change withi essage (defa has to be c ber of nodes ured to be t ion type hav

ption will be transm will be transm DO will only b will be transm

pe of each PD ransmission f the PDO on hanged.

Masters on th he contents.

alternativ

a PDO can be s transfer. Us PDO.

nsmission‐typ cally at every

f a problem

a simple met 0x80 + NodeI MCY is 8 byt and a FAULH MotionContro es. By defaul smission ty

ge

n a CANope ault Id: 0x80) onfigured at s.

transferred e ing values of

mitted after a mitted every

be sent, if a r mitted only o

DO is a next type 255: as nly if the stat

he other han

e method

e used to cy sing the eve

pe of 255 an y event‐time

m

thod to indic Id). So every

es. The cont HABER specif oller when or t the Motion ypes

en sub‐system ) which will t t the CANop

either cyclica f 0, 1 … 240,

a SYNCH, but 1 … 240 cycl related remo on a change –

parameter t synch – devic tus word (0x

nd will typica

of cyclic ex

yclically send ent‐timer the

nd a event‐ti r cycle perio

cate errors o y node has its tents is mixe fic error wor r whether to nContoller w

m is cyclic o rigger the ex pen master.

ally or in cas 253 or 255.

t only if chan le

ote transfer – depending

hat needs to ce profile de x6041.00) is m

lly send thei

xchange

d a PDO whic e update‐rat

imer > 0 wil od.

occurred with s own EMCY ed between rd.

o send an EM will trigger an

ne. The CAN xchange cycl

Typical valu

se of change

nged request has

on the devic

o be configur pendent – w mapped to th

r asynch PDO

ch is configu e of the PDO

l be updated

hin the devic message.

standard er

MCY message n EMCY at e

Nopen maste es.

es are 10ms

ed contents.

been receive ce profile.

red for each will trigger a t

he PDO and

Os at every c

red to a tran Os can be co

d at changes

ce. It is a sing

rror words,

e can be con every detecte

Seite 20 von 3

er will create

s … 200ms d

The setting

ed

PDO.

transmission has

change of

nsmission ty onfigured in

s of the statu

gle message

defined in t

nfigured with ed error. If t

35

e a

de‐

g is

n

ype di‐

us‐

at

the

hin the

(21)

Faulhaber

error is t will be se

Pre‐def

Some of ing a bas message This assi

2 Whethe fer.

CAN

Figure right.

transient – l ent, if the er

W m sy P

fined conn

f the services sic Id and the es to be rece

gnment of C

er an error sh

CiA 3

NMT Guarding

SD

PDO

E

18 A CANo

cation Note 174

ike an over t rror is gone a Within a PLC e messages. Th

ystem and it LC program,

ection set

s above do h e NodeId. Th ived by a CA COB‐Ids is cal

all trigger a E

301 CANopen State Machine

DO

1 - PDO4

E MCY Ha

open drive.

temperature again².

environment e PLC progra s specific ser mapping th

have a fixed C he Ids are ass AN controller lled predefin

MCY or not ca

ObjectDictionary

Error andling

CiA

Control Wo

Status Wor

M n*, Pos*

n, Pos S

. All the se

e ‐ a first EM

t there is usu am usually ha rvices. So if t

e internal er

COB‐Id assig signed in a w r.

ned connecti

an be configu

A 402 Drive State Machine

ord

rd Motor Control

State Machine

ervices on t

MCY will signa

ually no dire as no direct the device st rror register

ned to it, so way which all

on set.

ured. By defau

Moto

the left of t

al the error a

ct access to t awareness o ate has to be to one of the

me are locat ows for hard

ult, all errors a

or

the OD, the

and a second

the contents of the CANop e monitored e PDOs migh

ted in an Id r dware (HW)

are activated e drive beh

Seite 21 von 3

d empty EM

s of EMCY pen sub‐

d out of a ht be easier.

range, comb filtering of t

for EMCY tra havior on th

35

CY

in‐

he

ns‐

he

(22)

Service 2¹⁰ 2⁹ 2⁸ 2⁷ 2⁶ 2⁵ 2⁴ 2³ 2² 2¹ 2⁰

NMT (0) 0 0 0 0 0

SYNCH (0x80) 0 0 0 1 0

EMCY (0x80 + Id) 0 0 0 1 NodeId

TxPDO1 (0x180 + Id) 0 0 1 1 NodeId

RxPDO1 (0x200 + Id) 0 1 0 0 NodeId

TxPDO2 (0x280 + Id) 0 1 0 1 NodeId

RxPDO2 (0x300 + Id) 0 1 1 0 NodeId

TxPDO3 (0x380 + Id) 0 1 0 1 NodeId

RxPDO3 (0x400 + Id) 0 1 1 0 NodeId

TxPDO4 (0x480 + Id) 0 1 0 1 NodeId

RxPDO4 (0x500 + Id) 0 1 1 0 NodeId

SDO Request (0x600 + Id) 1 1 0 0 NodeId

SDO Response (0x580 + Id) 1 0 1 1 NodeId

Guarding (0x700 + Id) 1 1 1 0 NodeId

LSS Request 1 1 1 0xE5

LSS Response 1 1 1 0xE4

Handling of COB-Ids when NodeId is changed

Some of the message‐Ids used for the CANopen services can be configured freely – others are fixed. The COB‐Id of the configurable Ids is stored in the 0x1xxx parameter range of the OD. E.g. 0x183 for the TxPDO1 of node 3.

When the NodeId of a CANopen slave is changed, the handling of the adjustable COB‐Ids could either be:

 Adjust all the COB‐Ids to fit to the new Node‐Id

 Don't adjust the COB‐Ids

Table 6 Ranges for the COB-Ids according to the predefined connection set

(23)

Faulhaber

This cou FAULHA unconfig The FAU troller is

LSS – co

Layer Se viously u switches LSS can ured can complet by the m It might deal with To use t the setti

EDS‐Fil

The capa distribut together rameter [2311s Parame Object DataTy Access PDOMap

The .eds ration. W the value Table 7

ld either be BER MotionC gured to any ULHABER Mo

changed wi

onfigure th

etting Service unconfigured s to adjust th be used wit n be identifi ely unconfig master to cre be easier to h the serial n the LSS pleas

ngs.

T co

e

abilities of a ted together r with the FA s as well as t sub1]

eterName=

tType=7 ype=0x000 sType=RO pping=1

s file can be Without an im

e ranges.

7 Example o

cation Note 174

done by a m Controllers w

valid NodeId tionManage thin the rang

he NodeId

es (LSS) can b d node or to hese settings hin a sub‐sy ed by its ide gured device ate a copy o o configure t number of th se refer to [5

he FAULHAB ontroller to t

CANopen de r with the d AULHABER M their propert

=Digital 05

imported int mported .ed of an entry

master (Motio will adjust th

d 1 … 127.

r will offer to ge of valid Id

and baud‐

be used to in change thes s.

ystem. Even entification s e into an exis f the previou the NodeId a he device.

5] for implem

BER Motion the required

evice are sum evice. The l Motion Mana

ties and – if a

input log

to CANopen s file the ma y in a .eds f

onManager) e COB‐Id by

o change the ds.

‐rate

nitially config se settings. F

if there are settings and sting sub‐sys us one.

and baud‐rat

mentation d

Manager ca d values.

mmarized in atest .eds fi ager. The .ed applicable –

gical sta

n masters, w aster will not file - here o

or by the sla firmware, w

e COB‐Ids of

gure the Nod FAULHABER

several unco ultimately i stem. The co

te in a 1:1 co

details or use

n be used to

an Electron ile of FAULH ds file contai

their default

ate

hich will use t be able to object 0x23

ave itself.

when the Nod

the PDOs, w

deId and the MotionCont

onfigured no ts serial num onfiguration

onfiguration

e one of the

o set the No

ic DataSheet HABER Motio

ins a comple t values.

e the informa display the p 311.01

deId is chang

when the Nod

e baud‐rate o tollers do no

odes the one mber. This a

could then

though wit

e PC‐based to

odeId and ba

t (.eds) file w onController ete list of all

ation to assi parameter n

Seite 23 von 3

ged from 255

deId of a con

of either a pr ot use any HW

e to be conf llows to add

be automat

hout having

ools to chan

aud‐rate of a

which usually r is distribut

supported p

st the config ames or che

35

5 –

n‐

re‐

W‐

fig‐

d a ed

to

nge

a

y is ed pa‐

gu‐

eck

(24)

CANopen communication cycles

After the configuration of the nodes the CANopen master will switch the nodes to their operational state using the NMT. The SYNCH service will be started and driven by the SYNCH the cyclic exchange of the pro‐

cess image will start.

The type of communication has to match the requirements of the application. In a CAN sub‐system of ser‐

vo‐drives the drives are usually operated using the Profile Position Mode (PP) which will move from A to B autonomously after having received the start command. In such an environment the master will send a new target position only if required and will start the movement with a single access to the drives control‐

word. As such a move might take several 10ms to multiple 100ms the commands from the master can be sent on demand – asynchronously.

If Cyclic Synchronous Position mode (CSP) is used, the target position should be updated in short cycles, so most likely the target will be sent synchronously. While CSP is active there is no interaction with the con‐

trolword – so a PDO having the controlword only, might stay in asynchronous configuration.

The actual values of the drives however are often used to monitor the drive behavior and are typically updated cyclically every communication cycle.

So the master uses PDOs configured for asynchronous transmission while the drives will send their PDOs cyclically. The synch interval length depends on the number of nodes connected to the sub‐system, the baud‐rate and the number of messages that have to exchanged.

Typical values are 10ms (a few nodes only) to 50ms or more.

In addition to the process data, there might be occasional requests for a SDO service when a specific pa‐

rameter of one of the slaves has to be changed.

The guarding‐ or heartbeat‐interval is usually a multiple of the synch interval. This is again depending on the needs of the application. A failed guarding might for example disable a drive, as the connection to the master is lost. So the selection of the guarding‐interval might be related to the physical risk of the move‐

ment.

SYNCH SYNCH SYNCH

synch PDOs synch PDOs EM synch PDOs

CY asynch

PDOs

Figure 19 Communication cycles of a CANopen sub-system

(25)

Startup of a CANopen sub‐system

If a CAN node or a sub‐system does not behave as expected a check of the communication might be nec‐

essary. Different phases can be identified. During the following description, we assume all nodes are con‐

figured and have a unique NodeId and their baud‐rate is configured to be identic to the one of the master.

Boot-Msg

After a node s powered up it will send its boot‐msg. This will happen independently from the state of the complete sub‐system.

Example: node 3 is sending its boot‐msg:

Id Data Description

…

703 00 The 7xx indicates the message as one of out of the guarding messages. The 0 denotes the boot‐msg.

Here we do see a message within the range of the guarding and boot messages. These messages do have a single data byte, which contains the state of the communication stack. The boot‐message is sent when entering the pre‐operational state. The state (init) is coded by the 0.

Configuration via SDO

After a new drive is identified by its boot‐message, the CANopen master will configure the slave. This is an optional step. Typical parameters are at least the communication settings like guarding interval and the PDO settings (mappings & transmission types).

Additionally applications specific configurations can be added for many industrial masters. Some imple‐

mentations will even keep a copy of the complete drive configuration within the master. In such a case even an exchange of a component will be supported.

Example: node 3 is configured via SDO after having sent its boot‐message:

…

703 00 The boot‐message

603 xx 00 14 00 dd dd dd dd xx contains the SDO request command 00 14 00 is the OD entry 0x1400.00 dd contains the data to we written 583 yy 00 14 00 rr rr rr rr yy contains the SDO response code

Guarding Guarding

SDO Request & Response

Figure 20 Mix of PDO-cycles, SDO and node-guarding

(26)

00 14 00 is the OD entry 0x1400.00 rr contains the response data 603

583

xx ii ii ss dd dd dd dd yy ii ii ss rr rr rr rr

will be repeated several times until the complete config‐

uration is written.

ii ii is the index of the accessed object, ss the sub‐index

Start via NMT

After the node is configured – that is after the CANopen master successfully wrote the entire stored con‐

figuration via SDO – it will start the cyclic data exchange. This could be done for the complete network, usually it is done on a per node base. For the node 3 the message would be

…

603 583

xx ii ii ss dd dd dd dd yy ii ii ss rr rr rr rr

will be repeated several times until the complete config‐

uration is written.

ii ii is the index of the accessed object, ss the sub‐index

0 01 03 NMT command to start node 3

Cyclic data exchange

After at least a first node is switched into the operational state the communication cycles as in Figure 19 are started by the master by sending a first SYNCH message. When receiving the first SYNCH, all the nodes will send their PDOs according to their configuration. At this start of the communication all the asynch PDOs are sent too, to create an initial valid process image.

In a sub‐system having the nodes 2, 3 and 4 with a configuration according to Figure 16 we might see something like:

…

80 SYNCH

182 40 00 01

Disabled drives OpMode = PP

183 40 00 01

184 40 00 01

202 00 00 00 00 B8 0B 00 00 TargetSpeed = 0 ProfileSpeed = 3000 203 00 00 00 00 B8 0B 00 00 TargetSpeed = 0 ProfileSpeed = 3000 204 00 00 00 00 B8 0B 00 00 TargetSpeed = 0 ProfileSpeed = 3000 282 34 12 00 00 00 00 00 00 ActPos = 0x1234 ActSpeed = 0 283 78 56 00 00 FF FF FF FF ActPos = 0x5678 ActSpeed = ‐1 284 FC FF FF FF 00 00 00 00 ActPos = ‐4 ActSpeed = 0 302 4D 1C 00 00 C4 09 00 00 Acceleration = 7500 Deceleration = 2500 303 4D 1C 00 00 C4 09 00 00 Acceleration = 7500 Deceleration = 2500 304 4D 1C 00 00 C4 09 00 00 Acceleration = 7500 Deceleration = 2500

(27)

Faulhaber

402 403 404 80 182 183 184 282 283 284 83

80 182 183 184 602 282 582 283 284

…

Therefor and ther A first ch reports a

00 00 0 00 00 0 00 00 0

40 00 0 40 00 0 40 00 0 30 12 0 78 56 0 02 00 0 EC EC E

40 00 0 40 00 0 40 00 0 xx ii i 34 12 0 yy ii i 78 56 0 FC FF F

…

re, besides t re might be a heck might b any error fra

If C A b

It ra In ti If fr m a

cation Note 174

01 00 00 01 00 00 01 00 00 01 01 01 00 00 FE 00 00 FF 00 00 02 ER FF FF

01 01 01 ii ss dd 00 00 00 ii ss rr 00 00 FF FF FF 00

he SYNCH an additional SD be whether a ames.

f not all the e ANopen mas Alternatively

e transferred

t's very likely ate of error n a limited n on is correct f there are d rames is som might differ s

nd no avalan

00 00 00 00 00 00

FF FF FF FF FF FF 00 00 00 00 00 00

dd dd dd 00 00 00 rr rr rr FF FF FF 00 00 00

nd the PDOs DO services – all the expec

expected PD ster might re check wheth d.

y to see som messages sh etwork ther t.

different com metimes obs

slightly. This nches of erro

Shut com SYNCH Disabled F ActPos F ActPos 0 ActPos 0 EMCY m

bit erro (FF).

SYNCH Disabled d SDO req 0 ActPos r SDO res F ActPos 0 ActPos

s we will see – started by t cted PDOs ha

DOs are foun eport missing

her the com

me error fram hould be ver re should no

mponents co served. In th can be tole ors occur.

tdown mmand

d drives

= 0x1230

= 0x5678

= 0x0002 message hav or register (E

d drives quest for nod

= 0x1234 sponse for no

= 0x5678

= ‐4

an occasion the applicati ave been tra

d, check the g PDOs too.

mmunication

mes, when th ry small com

t be any err

onnected to his case the rated, if the

OpMode =

OpMode = P Ac Ac Ac ving the 16‐b R) and the F

OpMode = P de 2

Ac ode 2

Ac Ac

nal EMCY dep on master v nsmitted and

eir configured

cycle is long

he system is pared to the or frames if

a sub‐system timing of th

rate of erro

= PP

Targ Targ Targ

PP ctSpeed = ‐2 ctSpeed = 0 ctSpeed = 2 bit error cod FAULHABER

PP ctSpeed = 0 ctSpeed = ‐1 ctSpeed = 0

pending on t via the CANo

d whether th

d transmissi

g enough for

started up.

e undisturbe the wiring a

m a certain he different or frames is s

Seite 27 von 3

getPos = 0 getPos = 0 getPos = 0

de (EC), the error registe

the drive sta pen master.

he logging to

on type. The

r all PDOs to

Later on the ed messages

and termina‐

rate of error components still very low

35

8 er

ate

ool

e

o

e .

‐

r s w

(28)

CANopen Master

CANopen Drive

SYNCH telegram at 0x80 no data included

cyclic transmssion by the master

SYNCH

CANopen Nodes

CANopen Drive

CAN telegram with a preconfigred set of variables multible PDOs can be configured per node

main focus: exchange of references and actual values during runtime

TxPDO 1 x Producer 0 ... n x Consumer

OD CANopen

Nodes

CANopen Node

CANopen Drive RxPDO

1 x Producer 0 ... n x Consumer

CAN telegram with a preconfigred set of variables OD

multible PDOs can be configured per node

main focus: exchange of references and actual values during runtime

Figure 21 Services in operational state of the communication