04-68280A Manual Digsy Chapter K Communication via CANopen

Manual digsy®

Chapter K Communication via CANopen

Drawing Number: 04 - 68 280 000/A Issued: 14.10.02 Stored: 14.10.02 Version: 1.0.0 File name: 04-68280 Manual Communication via CANopen Prepared by: Ralf Neuber

This manual was prepared with great care. The details and data in this document are regularly checked and updated and are at any time subject to change without notice. Nevertheless, INTER CONTROL does not assume liability for the correctness of the details/data in this document, since, despite great effort, mistakes cannot always be completely ruled out. In addition, INTER CONTROL reserves the right to make at any time technical changes to the product, which can also result in deviations from the contents of this document. The document includes information that enjoys protection of copyright. No part of this publication may be reproduced and/or translated into other languages without the prior written permission of INTER CONTROL. Of course, any ideas and suggestions regarding amendments, or notes concerning mistakes in this document are welcome. Please refer to INTER CONTROL.

INTER CONTROL Hermann Köhler Elektrik GmbH & Co. KG Schafhofstraße 30 D-90411 Nürnberg Germany Tel.: Fax: E-mail: Internet:

++49 911 9522-5 ++49 911 9522-857 [email protected] http://www.intercontrol.de

K Communication via CANopen

Manual digsy®

Table of Contents K

Communication via CANopen ..................................................................................................K-5 K.1 Fundamentals ...................................................................................................................K-5 K.1.1 Data exchange principle ............................................................................................K-6 K.1.2 CANopen ...................................................................................................................K-7 K.1.2.1 Object directory ......................................................................................................K-7 K.1.2.2 CANopen-communication: .....................................................................................K-7 K.1.2.3 NMT .......................................................................................................................K-8 K.1.2.3.1 Nodeguarding ................................................................................................K-10 K.1.2.3.2 Heartbeat .......................................................................................................K-11 K.2 CANopen-Interfaces of digsy®compact / digsy®CGM ..............................................................K-12 K.2.1 Object directory........................................................................................................K-12 K.2.1.1 Object directory digsy®compact E (4885.27.102/202/302) .......................................K-12 K.2.1.1.1 Allocation of the network variables ................................................................K-23 K.2.1.2 Object directory digsy®CGM ....................................................................................K-25 K.2.1.2.1 Allocation of the network variables ................................................................K-36 K.2.1.3 Differences between digsy®compact and digsy®CGM ..................................................K-37 K.2.2 Default settings in digsy®compact / digsy®CGM ...............................................................K-38 K.2.2.1 Default PDOs / Default PDO-Mapping.................................................................K-38 K.2.2.2 NMT-values..........................................................................................................K-38 K.2.3 Function blocks and functions under PROSYD 1131..............................................K-39 K.2.3.1 Introduction ..........................................................................................................K-39 K.2.3.2 Initialization of the CAN-bus and setup of objects ...............................................K-40 K.2.3.2.1 CM_Init(): Setting up a CANopen-node.........................................................K-40 K.2.3.2.2 COPINIT(): Setting up a CANopen-node – DcP/DcE-compatible .................K-42 K.2.3.2.3 COBADD() : Setting up a new entry in the object directory:..........................K-43 K.2.3.2.4 CM_AddNode(): Setting up the node list .......................................................K-45 K.2.3.2.5 CM_Reset():CM_Reset(): Resetting the network settings of the control unitK-47 K.2.3.3 NMT and guarding mechanisms ..........................................................................K-48 K.2.3.3.1 CM_SetNodeState(): Setting the node state .................................................K-48 K.2.3.3.2 CM_GetNodeState(): Reading the node state of a slave ..............................K-50 K.2.3.3.3 CM_StartStopGuarding(): Starting or stopping the network guarding...........K-51 K.2.3.3.4 : CM_Guarding(): Heartbeat and guarding mechanism ................................K-53 K.2.3.4 Functions and function blocks for SDO-transfer ..................................................K-55 K.2.3.4.1 SDOADD(): Setting up SDO-channels ..........................................................K-55 K.2.3.4.2 CM_SDO_RW(): Executing an SDO-transfer................................................K-56 K.2.3.4.3 SDOTRANS(): Executing an SDO-transfer –VERSION in DcP ....................K-59 K.2.3.4.4 CM_DCFTrans( ): SDO-transfer of groups....................................................K-61 K.2.3.5 Functions for PDO-transfer ..................................................................................K-63 K.2.3.5.1 CM_PDO_Sync():SYNC-object output ..........................................................K-63 K.2.4 Error codes of the CANopen-functions or CANopen-function-blocks .....................K-64 K.2.4.1 Error of the CM-functions and CM-function-blocks..............................................K-64 K.2.5 CAN-variables in data structures or in the control configuration .............................K-66 K.2.5.1 digsy®compact E .......................................................................................................K-66 K.2.5.2 digsy®CGM ..............................................................................................................K-67 K.2.6 Summary .................................................................................................................K-68 K.3 SDO-Transfer..................................................................................................................K-69 K.3.1 Basics ......................................................................................................................K-69 K.3.1.1 Segmented SDO-transfer ....................................................................................K-69

04 - 68 280 000/A Version 1.0.0

Page K-2

K Communication via CANopen

Manual digsy®

K.3.1.2 Expedited SDO download....................................................................................K-71 K.3.1.3 Block transfer .......................................................................................................K-71 K.3.2 SDO-transfer in the case of digsy®compact E/ digsy®CGM..............................................K-71 K.3.2.1 SDOADD() ...........................................................................................................K-71 K.3.2.2 CM_SDO_RW() ...................................................................................................K-72 K.3.2.3 CM_DCFTrans()...................................................................................................K-73 K.4 Mapping and COP-ID-setup in digsy®compact / digsy®CGM...................................................K-75 K.4.1 Basics ......................................................................................................................K-75 K.4.1.1 General ................................................................................................................K-75 K.4.1.2 Basic information on digsy®compact E/ digsy®CGM.....................................................K-77 K.4.1.2.1 Structure of the Config-objects for an SDO-transfer to the CANopen-nodesK-77 K.4.1.2.2 COB-Identifier-setup ......................................................................................K-77 K.4.1.2.3 Re-mapping process......................................................................................K-77 K.4.2 Setting up the COB-Ids............................................................................................K-78 K.4.3 Mapping in digsy®compact E/ digsy®CGM ........................................................................K-80 K.4.4 Mapping of slaves – in this case with DIGSYcompact ............................................K-84 K.4.5 Mapping of slaves – in this case with CGC .............................................................K-86 K.4.6 Mapping of slaves – in this case standardized nodes acc. to DS301 .....................K-89 K.5 Sequencer for setting up a CANopen-network with digsy®compact -/ digsy®CGM as a manager K-90 K.5.1 Steps of the runup sequencer .................................................................................K-90 K.5.2 Keeping to the times between the individual steps .................................................K-91 K.6 PDO-Transfer..................................................................................................................K-94 K.6.1 PDO: Transfer of values in the REAL-format ..........................................................K-94 K.7 NMT Guarding mechanisms ...........................................................................................K-95 K.7.1 Bootup process........................................................................................................K-95 K.7.2 Nodeguarding ..........................................................................................................K-95 K.7.3 Heartbeat .................................................................................................................K-96 K.8 Error Handling.................................................................................................................K-99 K.8.1 Introduction ..............................................................................................................K-99 K.8.2 Functionalities regarding the emergency-objects in digsy®compact E / digsy®CGM .....K-100 K.8.2.1 Basic user-functions regarding the error memory..............................................K-100 K.8.2.1.1 GetNextError(): Inquiring the error memory.................................................K-100 K.8.2.1.2 GetNextErrorTS(): Inquiring the error memory with time indication ............K-101 K.8.2.1.3 SetNextError(): Generating an error / a message .......................................K-101 K.8.2.1.4 Emergency-variables in data structures or of the adjustable control configuration .................................................................................................................K-102 K.8.2.2 Reading-out an emergency message ................................................................K-103 K.8.2.3 Generating emergency messages .....................................................................K-104 K.9 Example Project............................................................................................................K-106 K.9.1 Task definition........................................................................................................K-106 K.9.2 Implementation of the CANopen-slave-nodes.......................................................K-107 K.9.2.1 CAN-Initialization................................................................................................K-107 K.9.2.2 PDO-Setup.........................................................................................................K-108 K.9.2.3 Guarding mechanism.........................................................................................K-109 K.9.2.4 SDO-transfer ......................................................................................................K-110 K.9.2.5 Error evaluation in slave-node implementations................................................K-110 K.9.3 Implementation of the CANopen-manager............................................................K-111 K.9.3.1 CAN-Initialization................................................................................................K-111 K.9.3.2 PDO-Setup.........................................................................................................K-112 K.9.3.3 Guarding mechanism.........................................................................................K-112 K.9.3.4 Runup sequencer for setting up the network .....................................................K-115 K.9.3.4.1 Setting up node 3, optionally node 5 ...........................................................K-115 K.9.3.4.2 Individual setup of the node 5......................................................................K-116 K.9.3.5 Network management........................................................................................K-117 K.9.3.6 Error evaluation in the CANopen-manager-implementation..............................K-117

04 - 68 280 000/A Version 1.0.0

Page K-3

K Communication via CANopen

Manual digsy®

K.10 Technical Data and Important Additions.......................................................................K-120 K.10.1 Technical data .......................................................................................................K-120 K.10.2 Storage processes in FLASH-memory in the case of digsy®compact E/ digsy®CGM ....K-120 K.11 Appendix .......................................................................................................................K-121 K.11.1 List of illustrations: .................................................................................................K-121 K.11.2 List of tables:..........................................................................................................K-123 K.11.3 Bibliography ...........................................................................................................K-124 K.12 Notes.............................................................................................................................K-125

04 - 68 280 000/A Version 1.0.0

Page K-4

K Communication via CANopen

K

Manual digsy®

COMMUNICATION VIA CANOPEN

K.1 Fundamentals Apart from some general words about CAN and CANopen this functional description basically covers the features of the devices of the digsyoutdoor electronics-family and their handling. It is not meant to give a general description of the features of the CAN-bus or of CANopen. Basic information on the subjects CAN-bus and CANopen may be found under http://www.cancia.de (CiA - CAN in Automation e.V., CAN-Nutzerorganisation (user organization)) or in the appropriate technical literature.

NOTE:

To understand this functional description it is indispensable to have a basic knowledge of the subjects CAN-bus and CANopen.

NOTE:

The CANopen-functionality described in this manual is based on the CANopen Draft Standard DS301, V4.01, which is available from „CiA CAN in Automation e.V.“

CAN stands for „Controller Area Network“ and was originally developed by the companies Bosch and Intel as a bus system for vehicles. Meanwhile, however, CAN proved to be very good as a field bus in automation technology applications, too. As virtually all field buses CAN too is based on the OSI 7-layer model. CAN is only standardized for the OSI-layers 1 and 2 in the ISO 11898. The "missing" user layer is defined by the layer 7 protocols DeviceNet, J1939, SDS, CAL and CANopen that are based on CAN. The CAN-bus is a serial bus system in the case of which all the connected stations have equal rights, i.e., each control unit (CAN-node) is both able to transmit and to receive. Therefore, the connected control units can „talk to each other“ and exchange information via cables. Due to the linear structure of the network the bus system continues to be fully available for all the other stations if one station fails. The following figure shows a schematic diagram of a CAN-network:

Device 1

Device 2

Device 3

Device n

CAN

CAN

CAN

CAN

120Ω

120Ω

Figure K.1 Schematic device connection on the CAN-bus With the lines CAN-High and CAN-Low the CAN-bus represents a two-wire-solution. The realizable bus length depends on the chosen transmission rate. To avoid reflections of the bus levels, each of

04 - 68 280 000/A Version 1.0.0

Page K-5

K Communication via CANopen

Manual digsy®

the bus ends is terminated with a terminating resistor of R=120Ω. The length of the tap lines to the individual participants must not exceed a length of l=30cm.

K.1.1 Data exchange principle The CAN-bus represents a multi-master-system. With regard to their content and priority, the messages on the CAN-bus are clearly identified by a so-called identifier (in the arbitration field, see Figure K.2). Stations on a CAN-Bus are able to transmit messages at any time. If two or more stations start to send messages at the same time, the message with the highest priority gets the transmission right after a nondestructive arbitration process. Messages deferred by this arbitration process are automatically repeated.

Arbitration Field S O F

11- bzw. 29-Bit Identifier

Control Field R T R

I D E

Data Field

CRC Field

0...8 Bytes

15-Bit CRC

Ackn. Field

End of Frame

R 0 DLC

Figure K.2 Structure of a CAN-message CAN-messages comprise up to 8 bytes of user data. They can be received and evaluated by each of the stations. For this, however, both the producers and the consumers of a message require the same information about the quality and the contents of the message. This information is to be communicated to the individual stations of a CAN-network by means of a configuration process.

04 - 68 280 000/A Version 1.0.0

Page K-6

K Communication via CANopen

Manual digsy®

K.1.2 CANopen CANopen is an open protocol standard for the CAN-communication in automation engineering. It was standardized by the association „CAN in Automation“ (CiA). The protocol uses the CAN-bus as a transmission medium and defines an application-layer (corresponds with OSI-layer 7) with the following features: • • • • • • •

network management object directory default settings for the allocation of identifiers data transmission objects for process and configuration data network guarding error messages and function profiles

Task definition:- to be able to operate CANopen-components of different producers on one bus. This functional description is based on CANopen according to Draft Standard DS301, V4.01.

K.1.2.1 Object directory All the variables and parameters of a CANopen-device, which are important for the CANcommunication, are put together in the object directory. The object directory contains entries which are mandatory and others that are freely definable. The entries are clearly identified by a number, the so-called index, and besides they are addressable, too. They may contain simple data types, e.g., bytes, integers, long integers, .. and complex data types such as arrays, too. The structure of the object directory, the allocation of the index numbers as well as some mandatory entries are defined in the CANopen device profiles.

NOTE:

In the case of the products digsy®compact and digsy®CGM the CANopenconfiguration, i.e., the change of entries in the object directory, is to be carried out from the application program.

K.1.2.2 CANopen-communication: The data exchange in CANopen is effected in the form of messages by means of which the user data are transmitted. In this connection, one distinguishes between service data objects (SDO), which are used for the transmission of the service data from and to the object directory or for the non-time-critical transmission of data (even those exceeding a data length of 8 bytes), and process data objects (PDO), which are used for the exchange of the current process states. In addition, messages for the network management (NMT) and for error messages (emergencies) can be defined as well. By means of SDOs it is possible to access all the entries in the object directory. In practice, SDOs are mainly used for initialization and configuration purposes during the run-up of the CAN-bus. An SDO can always access only one object of the object directory. SDOs represent a logic peer-topeer connection between two stations in the form of an acknowledged service.

04 - 68 280 000/A Version 1.0.0

Page K-7

K Communication via CANopen

Manual digsy®

A PDO can transport a maximum of 8 bytes of data. The data contents of a PDO can be composed of various objects from the object directory. The compilation of various data in a PDO is also referred to as PDO-mapping.

PDO (Process Data Object)

SDO (Service Data Object)

- real-time data - message is not answered (faster transfer) - high-priority identifiers - synchronous and asynchronous transfer possible - max. 8 bytes / message - prearranged data format

- system parameter - message is answered (slower transfer) - low-priority identifiers - only asynchronous transfer - data spread over several messages - index-addressable data

Table K.1 Communication types in the case of CANopen Exclusively for the network management CANopen dispenses with the multi-master-capability of the CAN-bus. For this, a station in the CAN-network takes on the tasks of the network management. These tasks comprise, e.g., defined starts and stops of the network or individual stations of the network and the network guarding. All the other stations in the CAN-network are to be implemented as so-called slaves. For the network management and network guarding, for error messages and other services in CANopen there are predefined logic communication objects: -

for the boot-up (start of the network after switch-on), starting, stopping, resetting one or all stations in the network, for node guarding and life guarding or heartbeat for guarding the network, for the synchronization of messages or of stations in the network, for emergency messages.

These objects are firmly defined in CANopen and have global news broadcasting characteristics.

K.1.2.3 NMT A CANopen-node can take the following states: Node state 1 (INIT) 4 (STOPPED or. PREPARED) 5 (OPERATIONAL) 127 (PREOPERATIONAL)

SDO-Transfer not possible not possible possible possible

PDO-Transfer not possible not possible possible not possible

NMT not possible possible possible possible

Table K.2 Network states and how they differ Possible state changes are indicated in Figure K.3:

04 - 68 280 000/A Version 1.0.0

Page K-8

Special features boot- up message

automatically after Init

K Communication via CANopen

Manual digsy®

Initialization Reset Application

Reset Communication

power on Init

Preoperational Stopped

Operational

Figure K.3 NMT-states After switching the network on (Power on) a network participant goes through an initialization stage (Init). Afterwards it sends a so-called boot-up message on the bus. The other network participants, especially the CANopen-manager, automatically change to the Preoperational state. All the following state changes are effected by order of the network master. In general, a network slave is configured in the Preoperational state. That means that the CANopen-Manager, via SDO-communication, makes adjustments with regard to the input/output configuration, the PDO-communication and the network guarding. When the configuration stage is finished, the CANopen-Manager switches the network slave over to the Operational state. Guarding mechanisms: In CANopen there are 2 types of network guarding: • •

Nodeguard Heartbeat

04 - 68 280 000/A Version 1.0.0

Page K-9

K Communication via CANopen

K.1.2.3.1

Manual digsy®

Nodeguarding

The NMT-master cyclically sends a guard request to an NMT-slave-node with a time interval of tGUARD. This slave node answers the master with its current node state. If the NMT-master, after nLIFETIME-requests, receives no answer, the nodeguarding will deactivate itself and an error handling has to be effected. Relevant entries in the object directory: 16#100C => Guarding time tGUARD [WORD] 16#100D => Life-time-factor nLIFETIME [BYTE]

NMT-Master

NMT-Slave 700 h + Node – ID

( request )

700 h + Node - ID

( response )

tGUARD

Figure K.4 Nodeguard principle

04 - 68 280 000/A Version 1.0.0

Page K-10

K Communication via CANopen

K.1.2.3.2

Manual digsy®

Heartbeat

The heartbeat-producer (this may be the NMT-master or an NMT-slave) cyclically transmits its current node state without request at a time interval of tHEARTBEAT. The heartbeat-consumer (this may be the NMT-master or an NMT-slave, too) receives this node state and can react to it. If, after tHB-Consum, no heartbeat follows, the heartbeat guarding in the heartbeat-consumer will be deactivated and an error handling has to be effected. In this connection, the heartbeat-consumertime should be an integer multiple of the heartbeat-producer-time tHEARTBEAT. Relevant entries in the object directory: 16#1017 => Heartbeat-producer-time tHEARTBEAT [WORD] 16#1016 => Heartbeat-consumer-value (16#rrnncccc with rr(reserved), nn(Node-Id), cccc(tHB-Consum) ) Heartbeatproducer

Heartbeatconsumer

700 h + Node–ID (produce)

tHEARTBEAT 700 h + Node–ID (produce)

Figure K.5 Heartbeat principle

04 - 68 280 000/A Version 1.0.0

Page K-11

K Communication via CANopen

Manual digsy®

K.2 CANopen-Interfaces of digsy®compact / digsy®CGM K.2.1 Object directory K.2.1.1 Object directory digsy®compact E (4885.27.102/202/302) Index

SubIndex

Object

Name

Type/ Value Range

Attrib.

Category1

Default Value

Detailed Description

Communication Profile Area (CANopen Communication Characteristics Area) 1000h

VAR

Device type

UNSIGNED32

ro

M

1001h

VAR

Error register

UNSIGNED8

ro

M

16#0195 0

1005h

0

VAR

COB-ID SYNC message

UNSIGNED32

rw

O

16#40000080

1006h

0

VAR

Communication cycle period

UNSIGNED32

rw

O

0

1007h

0

VAR

Synchronous windows length

UNSIGNED32

rw

O

0

1008h

0

VAR

Manufacturer device name

STRING

ro

O

1009h

0

VAR

STRING

ro

O

100Ah

0

VAR

STRING

ro

O

e.g.„6.0.9“

100Ch

0

VAR

Manufacturer Hardware version Manufacturer Software version Guard Time

„DIGSYcompac t E“ e.g. „3.0“

UNSIGNED16

rw

C

512

100Dh

0

VAR

Life Time Factor

UNSIGNED8

rw

C

3

ARRAY

Store parameters

1010h 0

Largest subindex supported Save all parameters

1

1011h

ARRAY 0

1012h

0

VAR

1014h

0

VAR ARRAY

Consumer Heartbeat Time

1

1016h

Hardware version Software version Min. Guarding time in [ms] Life time factor

O UNSIGNED8

ro

M

1

UNSIGNED32

rw

M

0

UNSIGNED8

ro

M

1

UNSIGNED32

rw

M

0

UNSIGNED32

rw

O

16#80000100

UNSIGNED32

rw

M

16#80 + NodeID

Restore default parameters Largest subindex supported Restore all default parameters COB-Id Time Stamp Object COB-Id Emergency Object

No error CAN-Identifier of the SYNC-Object (Bit 30:= 1 -> SYNC is generated; Bit 29:= 0 -> 11Bit-ID; Bits 10-0 -> SYNC-COPID (16#80))2 Communication cycle period in [µs] At present: no function Length of time window in [µs] At present: no function Device name

Max. Subindex of Index 1010h Storage of all parameters At present: no function

O

O

0

Number of entries

UNSIGNED8

ro

M

16#20

1

Consumer heartbeat time

UNSIGNED32

rw

M

0

2

Consumer heartbeat time

UNSIGNED32

rw

O

0

3

Consumer heartbeat time

UNSIGNED32

rw

O

0

4

Consumer heartbeat time

UNSIGNED32

rw

O

0

5

Consumer heartbeat time

UNSIGNED32

rw

O

0

6

Consumer heartbeat time

UNSIGNED32

rw

O

0

1

Max. Subindex of Index 1011h Recovery of all default parameters Transfer of the global time in a COB-Id COB-Id of the emergency object Entries to the Heartbeat consumer Number of possible entries Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat

The following categories are possible: M->Mandatory; O->Optional; C->Conditional At present: no complete SYNC-implementation, SYNC-output serves only for initiating SYNC-PDOs, time conditions are not kept to and checked

2

04 - 68 280 000/A Version 1.0.0

Page K-12

K Communication via CANopen

Index

SubIndex

Object

Name

Type/ Value Range

Manual digsy®

Attrib.

Category1

Default Value

Detailed Description time

1017h

7

Consumer heartbeat time

UNSIGNED32

rw

O

0

8

Consumer heartbeat time

UNSIGNED32

rw

O

0

9

Consumer heartbeat time

UNSIGNED32

rw

O

0

10

Consumer heartbeat time

UNSIGNED32

rw

O

0

11

Consumer heartbeat time

UNSIGNED32

rw

O

0

12

Consumer heartbeat time

UNSIGNED32

rw

O

0

13

Consumer heartbeat time

UNSIGNED32

rw

O

0

14

Consumer heartbeat time

UNSIGNED32

rw

O

0

15

Consumer heartbeat time

UNSIGNED32

rw

O

0

16

Consumer heartbeat time

UNSIGNED32

rw

O

0

17

Consumer heartbeat time

UNSIGNED32

rw

O

0

18

Consumer heartbeat time

UNSIGNED32

rw

O

0

19

Consumer heartbeat time

UNSIGNED32

rw

O

0

20

Consumer heartbeat time

UNSIGNED32

rw

O

0

21

Consumer heartbeat time

UNSIGNED32

rw

O

0

22

Consumer heartbeat time

UNSIGNED32

rw

O

0

23

Consumer heartbeat time

UNSIGNED32

rw

O

0

24

Consumer heartbeat time

UNSIGNED32

rw

O

0

25

Consumer heartbeat time

UNSIGNED32

rw

O

0

26

Consumer heartbeat time

UNSIGNED32

rw

O

0

27

Consumer heartbeat time

UNSIGNED32

rw

O

0

28

Consumer heartbeat time

UNSIGNED32

rw

O

0

29

Consumer heartbeat time

UNSIGNED32

rw

O

0

30

Consumer heartbeat time

UNSIGNED32

rw

O

0

31

Consumer heartbeat time

UNSIGNED32

rw

O

0

32

Consumer heartbeat time

UNSIGNED32

rw

O

0

Producer heartbeat time

UNSIGNED16

rw

C

0

0

1018h

VAR RECORD

Identity object

M

Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Producer heartbeat time in [ms] Device information

0

Number of entries

UNSIGNED8

ro

M

4

1

Vendor ID

UNSIGNED32

ro

M

16#0000007A

Max. number of entries

2

Product code

UNSIGNED32

ro

O

4885.27.xxx

3

Revision number

UNSIGNED32

ro

O

Device specific

Product-code (xxx -> Device specific) Revision number

4

Serial number

UNSIGNED32

ro

O

Device specific

Serial number

Vendor-Id (vendor)

Communication Profile Area (SDO-Server Area) 1200h

RECORD

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client->Server (Rx) COB-Id Server->Client (Tx)

UNSIGNED32

ro

M

0

UNSIGNED32

ro

M

0

2 1201h

1st Server-SDO parameter

RECORD

04 - 68 280 000/A Version 1.0.0

2nd Server-SDO

M

Page K-13

Parameter of 1st ServerSDO Max. number of entries COB-Id of 1st Client-> Server-SDO (reception) COB-Id of 1st Server-> Client-SDO (transm.) Parameter of 2nd

K Communication via CANopen

Index

SubIndex

Object

Name

Type/ Value Range

Manual digsy®

Attrib.

Category1

Default Value

parameter

Server-SDO

0

Number of entries

UNSIGNED8

rw

M

2

1

COB-Id Client->Server (Rx) COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

UNSIGNED32

rw

M

16#80000000

2 1202h

RECORD

3rd Server-SDO parameter

M

0

Number of entries

UNSIGNED8

rw

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1203h

RECORD

Detailed Description

4th Server-SDO parameter

M

0

Number of entries

UNSIGNED8

rw

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

Max. number of entries COB-Id of 2nd Client-> Server-SDO (reception) COB-Id of 2nd Server-> Client-SDO (transm.) Parameter of 3rd ServerSDO Max. number of entries COB-Id of 3rd Client-> Server-SDO (reception) COB-Id of 3rd Server-> Client-SDO (transm.) Parameter of 4th ServerSDO Max. number of entries COB-Id of 4th Client-> Server-SDO (reception) COB-Id of 4th Server-> Client-SDO (transm.)

Communication Profile Area (SDO-Client Area) 1280h

RECORD

1st Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client->Server (Rx) COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

UNSIGNED32

rw

M

16#80000000

2 1281h

RECORD

2nd Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1282h

RECORD

3rd Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1283h

RECORD

4th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1284h

RECORD

5th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1285h

RECORD

6th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1286h

RECORD

7th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

Page K-14

Parameter of 1st ClientSDO Max. number of entries COB-Id of 1st Client-> Server-SDO (reception) COB-Id of 1st Server-> Client -SDO (transm.) Parameter of 2nd ClientSDO Max. number of entries COB-Id of 2nd Client-> Server-SDO (reception) COB-Id of 2nd Server-> Client -SDO (transm.) Parameter of 3rd ClientSDO Max. number of entries COB-Id of 3rd Client-> Server-SDO (reception) COB-Id of 3rd Server-> Client -SDO (transm.) Parameter of 4th ClientSDO Max. number of entries COB-Id of 4th Client-> Server-SDO (reception) COB-Id of 4th Server-> Client -SDO (transm.) Parameter of 5th ClientSDO Max. number of entries COB-Id of 5th Client-> Server-SDO (reception) COB-Id of 5th Server-> Client -SDO (transm.) Parameter of 6th ClientSDO Max. number of entries COB-Id of 6th Client-> Server-SDO (reception) COB-Id of 6th Server-> Client -SDO (transm.) Parameter of 7th ClientSDO Max. number of entries COB-Id of 7th Client-> Server-SDO (reception) COB-Id of 7th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

1287h

Object RECORD

Name

Type/ Value Range

Attrib.

8th Client -SDO parameter

Manual digsy® Category1 M

Default Value

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1288h

RECORD

9th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1289h

RECORD 0

10th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Ah

RECORD

M

0

11th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Bh

RECORD

M

0

12th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Ch

RECORD

M

0

13th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Dh

RECORD

M

0

14th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Eh

RECORD

M

0

15th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Fh

RECORD

M

0

16th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1290h

RECORD

M

0

17th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

M

Page K-15

Detailed Description Parameter of 8th ClientSDO Max. number of entries COB-Id of 8th Client-> Server-SDO (reception) COB-Id of 8th Server-> Client -SDO (transm.) Parameter of 9th ClientSDO Max. number of entries COB-Id of 9th Client-> Server-SDO (reception) COB-Id of 9th Server-> Client -SDO (transm.) Parameter of 10th Client-SDO Max. number of entries COB-Id of 10th Client-> Server-SDO (reception) COB-Id of 10th Server-> Client -SDO (transm.) Parameter of 11th Client-SDO Max. number of entries COB-Id of 11th Client-> Server-SDO (reception) COB-Id of 11th Server-> Client -SDO (transm.) Parameter of 12th Client-SDO Max. number of entries COB-Id of 12th Client-> Server-SDO (reception) COB-Id of 12th Server-> Client -SDO (transm.) Parameter of 13th Client-SDO Max. number of entries COB-Id of 13th Client-> Server-SDO (reception) COB-Id of 13th Server-> Client -SDO (transm.) Parameter of 14th Client-SDO Max. number of entries COB-Id of 14th Client-> Server-SDO (reception) COB-Id of 14th Server-> Client -SDO (transm.) Parameter of 15th Client-SDO Max. number of entries COB-Id of 15th Client-> Server-SDO (reception) COB-Id of 15th Server-> Client -SDO (transm.) Parameter of 16th Client-SDO Max. number of entries COB-Id of 16th Client-> Server-SDO (reception) COB-Id of 16th Server-> Client -SDO (transm.) Parameter of 17th Client-SDO Max. number of entries COB-Id of 17th Client-> Server-SDO (reception) COB-Id of 17th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

1291h

Object RECORD

Name

Type/ Value Range

Attrib.

Manual digsy® Category1 M

Default Value

0

18th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1292h

RECORD 0

19th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1293h

RECORD

M

0

20th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1294h

RECORD

M

0

21st Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1295h

RECORD

M

0

22nd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1296h

RECORD

M

0

23rd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1297h

RECORD

M

0

24th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1298h

RECORD

M

0

25th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1299h

RECORD

M

0

26th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Ah

RECORD

M

0

27th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

M

Page K-16

Detailed Description Parameter of 18th Client-SDO Max. number of entries COB-Id of 18th Client-> Server-SDO (reception) COB-Id of 18th Server-> Client -SDO (transm.) Parameter of 19th Client-SDO Max. number of entries COB-Id of 19th Client-> Server-SDO (reception) COB-Id of 19th Server-> Client -SDO (transm.) Parameter of 20th Client-SDO Max. number of entries COB-Id of 20th Client-> Server-SDO (reception) COB-Id of 20th Server-> Client -SDO (transm.) Parameter of 21st ClientSDO Max. number of entries COB-Id of 21st Client-> Server-SDO (reception) COB-Id of 21st Server-> Client -SDO (transm.) Parameter of 22nd Client-SDO Max. number of entries COB-Id of 22nd Client-> Server-SDO (reception) COB-Id of 22nd Server-> Client -SDO (transm.) Parameter of 23rd Client-SDO Max. number of entries COB-Id of 23rd Client-> Server-SDO (reception) COB-Id of 23rd Server-> Client -SDO (transm.) Parameter of 24th Client-SDO Max. number of entries COB-Id of 24th Client-> Server-SDO (reception) COB-Id of 24th Server-> Client -SDO (transm.) Parameter of 25th Client-SDO Max. number of entries COB-Id of 25th Client-> Server-SDO (reception) COB-Id of 25th Server-> Client -SDO (transm.) Parameter of 26th Client-SDO Max. number of entries COB-Id of 26th Client-> Server-SDO (reception) COB-Id of 26th Server-> Client -SDO (transm.) Parameter of 27th Client-SDO Max. number of entries COB-Id of 27th Client-> Server-SDO (reception) COB-Id of 27th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

129Bh

Object RECORD

Name

Type/ Value Range

Attrib.

Manual digsy® Category1 M

Default Value

0

28th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Ch

RECORD 0

29th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Dh

RECORD

M

0

30th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Eh

RECORD

M

0

31st Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Fh

RECORD

M

0

32nd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A0h

RECORD

M

0

33rd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A1h

RECORD

M

0

34th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A2h

RECORD

M

0

35th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A3h

RECORD

M

0

36th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A4h

RECORD

M

0

37th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

M

Page K-17

Detailed Description Parameter of 28th Client-SDO Max. number of entries COB-Id of 28th Client-> Server-SDO (reception) COB-Id of 28th Server-> Client -SDO (transm.) Parameter of 29th Client-SDO Max. number of entries COB-Id of 29th Client-> Server-SDO (reception) COB-Id of 29th Server-> Client -SDO (transm.) Parameter of 30th Client-SDO Max. number of entries COB-Id of 30th Client-> Server-SDO (reception) COB-Id of 30th Server-> Client -SDO (transm.) Parameter of 31st ClientSDO Max. number of entries COB-Id of 31st Client-> Server-SDO (reception) COB-Id of 31st Server-> Client -SDO (transm.) Parameter of 32nd Client-SDO Max. number of entries COB-Id of 32nd Client-> Server-SDO (reception) COB-Id of 32nd Server-> Client -SDO (transm.) Parameter of 33rd Client-SDO Max. number of entries COB-Id of 33rd Client-> Server-SDO (reception) COB-Id of 33rd Server-> Client -SDO (transm.) Parameter of 34th Client-SDO Max. number of entries COB-Id of 34th Client-> Server-SDO (reception) COB-Id of 34th Server-> Client -SDO (transm.) Parameter of 35th Client-SDO Max. number of entries COB-Id of 35th Client-> Server-SDO (reception) COB-Id of 35th Server-> Client -SDO (transm.) Parameter of 36th Client-SDO Max. number of entries COB-Id of 36th Client-> Server-SDO (reception) COB-Id of 36th Server-> Client -SDO (transm.) Parameter of 37th Client-SDO Max. number of entries COB-Id of 37th Client-> Server-SDO (reception) COB-Id of 37th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

12A5h

Object RECORD

Name

Type/ Value Range

Attrib.

Manual digsy® Category1 M

Default Value

0

38th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A6h

RECORD 0

39th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A7h

RECORD

M

0

40th Client -SDO parameter Number of entries

M UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

Detailed Description Parameter of 38th Client-SDO Max. number of entries COB-Id of 38th Client-> Server-SDO (reception) COB-Id of 38th Server-> Client -SDO (transm.) Parameter of 39th Client-SDO Max. number of entries COB-Id of 39th Client-> Server-SDO (reception) COB-Id of 39th Server-> Client -SDO (transm.) Parameter of 40th Client-SDO Max. number of entries COB-Id of 40th Client-> Server-SDO (reception) COB-Id of 40th Server-> Client -SDO (transm.)

Communication Profile Area (RxPDO Communication Area) 1400h

RECORD 0

RxPDO-Parameter

M

Parameter of 1st RxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000200

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

1401h

RECORD 0

RxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000300

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

1402h

RECORD 0

RxPDO-Parameter

M

Max. subindex of Index 1400h COB-Identifier of 1st RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 2nd RxPDO Max. subindex of Index 1401h COB-Identifier of 2nd RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 3rd RxPDO Max. subindex of Index 1402h COB-Identifier of 3rd RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000400

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 4th RxPDO

UNSIGNED8

ro

M

5

UNSIGNED32

rw

M

16#00000500

Max. subindex of Index 1403h COB-Identifier of 4th RxPDO

1403h

RECORD 0 1

04 - 68 280 000/A Version 1.0.0

RxPDO-Parameter Largest subindex supported COB-ID used by PDO

M

Page K-18

K Communication via CANopen

Index

SubIndex 2

Attrib.

Transmission type

Type/ Value Range UNSIGNED8

3

Inhibit time

UNSIGNED16

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 5th RxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

Max. subindex of Index 1404h COB-Identifier of 5th RxPDO In this case inactive Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 6th RxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

Max. subindex of Index 1405h COB-Identifier of 6th RxPDO In this case inactive Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

5

Event timer

UNSIGNED16

rw

O

0

1404h

Object

RECORD 0

1405h

RECORD 0

Name

Manual digsy®

rw

Category1 M

Default Value 254

rw

O

0

RxPDO-Parameter

M

RxPDO-Parameter

M

Detailed Description Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

:

:

:

:

:

:

:

:

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) :

:

:

:

:

:

:

:

:

:

143Fh

RECORD 0

RxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

Parameter of 64th RxPDO Max. subindex of Index 143Fh COB-Identifier of 64th RxPDO In this case inactive Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function Time for timer in [ms] (ATTENTION: not used in the case of RxPDO)

Communication Profile Area (RxPDO Mapping Area) 1600h

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A8C00140

1601h

RECORD 0

04 - 68 280 000/A Version 1.0.0

RxPDO mapping Largest subindex supported

M UNSIGNED8

Page K-19

rw

M

1

Mapping parameter of 1st RxPDO Max. subindex of Index 1600h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1024 Mapping parameter of 2nd RxPDO Max. subindex of Index 1601h

K Communication via CANopen

Index

SubIndex

Object

Name

Type/ Value Range

Attrib.

Manual digsy® Category1

Default Value

Detailed Description

:

:

:

:

:

:

:

:

0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1032 Mapping parameter of 3rd RxPDO Max. subindex of Index 1602h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1040 Mapping parameter of 4th RxPDO Max. subindex of Index 1603h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1048 Mapping parameter of 5th RxPDO Max. subindex of Index 1604h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1056 :

:

:

:

:

:

:

:

:

:

1

1602h

PDO-Mapping for the 2nd Mapped application object

RECORD

UNSIGNED32

rw

RxPDO mapping

C

16#A8C00240

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 3rd Mapped application object

UNSIGNED32

rw

C

16#A8C00340

1603h

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 4th Mapped application object

UNSIGNED32

rw

C

16#A8C00440

1604h

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 5th Mapped application object

UNSIGNED32

rw

C

16#A8C00540

163Fh

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 64th Mapped application object

UNSIGNED32

rw

C

16#A8C00240

Mapping parameter of 64th RxPDO Max. subindex of Index 163Fh 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1528

Communication Profile Area (TxPDO Communication Area) 1800h

RECORD 0

M

Parameter of 1st TxPDO

UNSIGNED8

ro

M

5

1

UNSIGNED32

rw

M

16#00000180

2

Transmission type

UNSIGNED8

rw

M

254 10

Max. subindex of Index 1800h COB-Identifier of 1st TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

1801h

RECORD

3

Inhibit time

UNSIGNED16

rw

O

10

Parameter of 2nd TxPDO Max. subindex of Index 1801h COB-Identifier of 2nd TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

0

3

TxPDO-Parameter Largest subindex supported COB-ID used by PDO

TxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000280

2

Transmission type

UNSIGNED8

rw

M

254

At present: only asynchronous transmission possible

04 - 68 280 000/A Version 1.0.0

Page K-20

K Communication via CANopen

Index

SubIndex 5

1802h

Object

Name Event timer

RECORD 0

Type/ Value Range UNSIGNED16

Attrib. rw

TxPDO-Parameter

Manual digsy® Category1 O

Default Value 0

M

Detailed Description Time for timer in [ms] Parameter of 3rd TxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000380

2

Transmission type

UNSIGNED8

rw

M

254 10

Max. subindex of Index 1802h COB-Identifier of 3rd TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000480

2

Transmission type

UNSIGNED8

rw

M

254 10

1803h

RECORD 0

TxPDO-Parameter

M

Parameter of 4th TxPDO Max. subindex of Index 1803h COB-Identifier of 4th TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254 10

1804h

RECORD 0

TxPDO-Parameter

M

Parameter of 5th TxPDO Max. subindex of Index 1804h COB-Identifier of 5th TxPDO In this case inactive Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

183Fh

RECORD 0

TxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254 10

Parameter of 64th TxPDO Max. subindex of Index 183Fh COB-Identifier of 64th TxPDO In this case inactive Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

Communication Profile Area (TxPDO Mapping Area) 1A00h

RECORD

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400140

1A01h

1A02h

TxPDO mapping

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400240

RECORD

04 - 68 280 000/A Version 1.0.0

TxPDO mapping

M

Page K-21

Mapping parameter of 1st TxPDO Max. subindex of Index 1A00h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB0 Mapping parameter of 2nd TxPDO Max. subindex of Index 1A01h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB8 Mapping parameter of 3rd TxPDO

K Communication via CANopen

Index

SubIndex 0

Object

Name Largest subindex supported

Type/ Value Range UNSIGNED8

Attrib.

UNSIGNED32

Manual digsy®

rw

Category1 M

Default Value 1

rw

C

16#A4400340

Detailed Description

:

:

:

:

:

:

:

:

Max. subindex of Index 1A02h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB8 Mapping parameter of 4th TxPDO Max. subindex of Index 1A03h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB16 Mapping parameter of 5th TxPDO Max. subindex of Index 1A04h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB24 :

:

:

:

:

:

:

:

:

:

1

1A03h

PDO-Mapping for the 1st Mapped application object

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400440

1A04h

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400540

1A3Fh

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4404040

04 - 68 280 000/A Version 1.0.0

Page K-22

Mapping parameter of 5th TxPDO Max. subindex of Index 1A3Fh 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB504

K Communication via CANopen

K.2.1.1.1

Allocation of the network variables

Data type[%..] Int8/Uint8 INT16/UINT16 INT/UINT32 8-String REAL (32Bit) LREAL (64Bit) UINT64 (64Bit)

MB0

MW

MB1

0 MD SO MD

MB2

MW 0 CT 0

MB3

1

MB4

MW

MB5

2 MD

Manual digsy®

MB6

MW 1

MB7

3

0 MD

1

...

M2044 M2045 M2046 M2047

... ... ... ... ... ... ...

MW SO MD

1022 MD CT 511

MW 511 255

1023

Table K.3 Memory allocation of the flag area in the IEC 1131 Network input variables (from the perspective of the CAN-bus): Read-Only-Variables (TxPDOs) (Note: from the perspective of the Prosyd 1131: output variables): Variable types SINT USINT/ BYTE BOOL

INT WORD/ UINT DINT/ UDINT/ DWORD REAL Int64 Uint64

from %MB0

from %MB256

from %MB512

from %MB768

to %MB1023

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

A000 A040

1 - 255 1 - 255

A001 A041

1 – 255 1 – 255

A002 A042

1 - 255 1 - 255

A003 A043

1 - 255 1 - 255

A080 A0C0 A100

1 - 255 1 - 128 1 - 128

A081 A0C0 A100

1 – 255 128-255 128-255

A082 A0C1 A101

1 - 255 1 - 128 1 - 128

A083 A0C1 A101

1 - 255 128-255 128-255

A1C0

1 - 64

A1C0

65 – 128

A1C0

129-192

A1C0

193-255

A240 A400 A440

1 - 64 1 - 32 1 - 32

A240 A400 A440

65 – 128 33 – 64 33 – 64

A240 A400 A440

129-192 65 - 96 65 - 96

A240 A400 A440

193-255 97 - 128 97 – 128

Table K.4 Index and Subindex allocation for the TxPDOs

04 - 68 280 000/A Version 1.0.0

Page K-23

K Communication via CANopen

Manual digsy®

Network output variables (from the perspective of the CAN-bus): Read-Write-Variables (RxPDOs) (Note: from the perspective of the Prosyd 1131: Input variables) Variable types SINT USINT/ BYTE BOOL

from %MB0

from %MB256

from %MB512

to %MB1023

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

A480 A4C0

1 - 255 1 - 255

A481 A4C1

1 – 255 1 – 255

A482 A4C2

1 - 255 1 - 255

A483 A4C3

1 - 255 1 - 255

A500 A540

1 - 255 1 - 128

A501 A542

A502 A543

1 - 255 1 - 128

A503 A543

1 - 255 128 - 255

A580

1 - 128

A582

A583

1 - 128

A583

128 - 255

A640

129 192

A640

193 - 255

129 192 65 - 96 65 - 96

A6C0

193 - 255

A880 A8C0

97 - 128 97 - 128

WORD/UI NT DINT/ UDINT/ DWORD REAL

A640

1 - 64

A640

1 – 255 128 – 255 128 – 255 65 – 128

A6C0

1 - 64

A6C0

65 – 128

A6C0

Int64 Uint64

A880 A8C0

1 - 32 1 - 32

A880 A8C0

33 – 64 33 – 64

A880 A8C0

INT

from %MB768

Table K.5 Index and Subindex allocation for the RxPDOs

ATTENTION:

04 - 68 280 000/A Version 1.0.0

The flag area cannot fully be mapped with the network variables. For more details please refer to the chapter „Mapping in digsy®compact E/ digsy®CGM“.

Page K-24

K Communication via CANopen

Manual digsy®

K.2.1.2 Object directory digsy®CGM Index

SubIndex

Object

Name

Type/ Value Range

Attrib.

Category4

Default Value

Detailed Description

Communication Profile Area (CANopen Communication Characteristics Area) 1000h

VAR

Device type

UNSIGNED32

ro

M

1001h

VAR

Error register

UNSIGNED8

ro

M

16#0195 0

No error

1005h

0

VAR

COB-ID SYNC message

UNSIGNED32

rw

O

16#40000080

1006h

0

VAR

Communication cycle period

UNSIGNED32

rw

O

0

1007h

0

VAR

Synchronous windows length

UNSIGNED32

rw

O

0

1008h

0

VAR

Manufacturer device name

STRING

ro

O

„CGM“

1009h

0

VAR

STRING

ro

O

e.g. „2.1“

Hardware version

100Ah

0

VAR

STRING

ro

O

e.g. „3.1.1“

Software version

100Ch

0

VAR

Manufacturer Hardware version Manufacturer Software version Guard Time

UNSIGNED16

rw

C

512

100Dh

0

VAR

Life Time Factor

UNSIGNED8

rw

C

3

ARRAY

Store parameters

1010h 0

Largest subindex supported Save all parameters

1

1011h

ARRAY 0

1012h

0

VAR

1014h

0

VAR ARRAY

Consumer Heartbeat Time

1

1016h

Min. Guarding time in [ms] Life time factor

O UNSIGNED8

ro

M

1

UNSIGNED32

rw

M

0

UNSIGNED8

ro

M

1

UNSIGNED32

rw

M

0

UNSIGNED32

rw

O

16#80000100

UNSIGNED32

rw

M

16#80 + NodeID

Restore default parameters Largest subindex supported Restore all default parameters COB-Id Time Stamp Object COB-Id Emergency Object

CAN-Identifier of SYNCObjects (Bit 30:= 1 -> SYNC will be generated; Bit 29:= 0 -> 11Bit-ID; Bits 10-0 -> SYNC-COPID (16#80))5 Communication cycle period in [µs] At present: no function Length of time window in [µs] At present: no function Device name

Max. subindex of Index 1010h Storage of all parameters At present: no function

O

O

0

Number of entries

UNSIGNED8

ro

M

16#20

1

Consumer heartbeat time

UNSIGNED32

rw

M

0

2

Consumer heartbeat time

UNSIGNED32

rw

O

0

3

Consumer heartbeat time

UNSIGNED32

rw

O

0

4

Consumer heartbeat time

UNSIGNED32

rw

O

0

5

Consumer heartbeat time

UNSIGNED32

rw

O

0

6

Consumer heartbeat time

UNSIGNED32

rw

O

0

7

Consumer heartbeat time

UNSIGNED32

rw

O

0

8

Consumer heartbeat time

UNSIGNED32

rw

O

0

9

Consumer heartbeat time

UNSIGNED32

rw

O

0

4

Max. subindex of Index 1011h Recovery of all default parameters Transfer of the global time in a COB-Id COB-Id of Emergencyobject Entries to the HeartbeatConsumer Number of possible entries Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time

The following categories are possible: M->Mandatory; O->Optional; C->Conditional At present: No complete SYNC-implementation, SYNC-output serves only for initiating SYNC-PDOs, no time conditions are kept to and checked 5

04 - 68 280 000/A Version 1.0.0

Page K-25

K Communication via CANopen

Index

1017h

SubIndex 10

Attrib.

Consumer heartbeat time

Type/ Value Range UNSIGNED32

rw

Category4 O

Default Value 0

11

Consumer heartbeat time

UNSIGNED32

rw

O

0

12

Consumer heartbeat time

UNSIGNED32

rw

O

0

13

Consumer heartbeat time

UNSIGNED32

rw

O

0

14

Consumer heartbeat time

UNSIGNED32

rw

O

0

15

Consumer heartbeat time

UNSIGNED32

rw

O

0

16

Consumer heartbeat time

UNSIGNED32

rw

O

0

17

Consumer heartbeat time

UNSIGNED32

rw

O

0

18

Consumer heartbeat time

UNSIGNED32

rw

O

0

19

Consumer heartbeat time

UNSIGNED32

rw

O

0

20

Consumer heartbeat time

UNSIGNED32

rw

O

0

21

Consumer heartbeat time

UNSIGNED32

rw

O

0

22

Consumer heartbeat time

UNSIGNED32

rw

O

0

23

Consumer heartbeat time

UNSIGNED32

rw

O

0

24

Consumer heartbeat time

UNSIGNED32

rw

O

0

25

Consumer heartbeat time

UNSIGNED32

rw

O

0

26

Consumer heartbeat time

UNSIGNED32

rw

O

0

27

Consumer heartbeat time

UNSIGNED32

rw

O

0

28

Consumer heartbeat time

UNSIGNED32

rw

O

0

29

Consumer heartbeat time

UNSIGNED32

rw

O

0

30

Consumer heartbeat time

UNSIGNED32

rw

O

0

31

Consumer heartbeat time

UNSIGNED32

rw

O

0

32

Consumer heartbeat time

UNSIGNED32

rw

O

0

Producer heartbeat time

UNSIGNED16

rw

C

0

0

1018h

Object

VAR RECORD

Name

Manual digsy®

Identity object

M

Detailed Description Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Consumer heartbeat time Producer heartbeat time in [ms] Device information

0

Number of entries

UNSIGNED8

ro

M

4

1

Vendor ID

UNSIGNED32

ro

M

16#0000007A

Max. number of entries

2

Product code

UNSIGNED32

ro

O

4885.8x.xxx

3

Revision number

UNSIGNED32

ro

O

Device specific

Product-code (x.xxx -> Device specific) Revision number

4

Serial number

UNSIGNED32

ro

O

Device specific

Serial number

Vendor-Id (vendor)

Communication Profile Area (SDO-Server Area) 1200h

RECORD

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client->Server (Rx) COB-Id Server->Client (Tx)

UNSIGNED32

ro

M

0

UNSIGNED32

ro

M

0

2 1201h

RECORD 0 1

2nd Server-SDO parameter Number of entries COB-Id Client->Server (Rx) COB-Id Server->Client (Tx)

2 1202h

1st Server-SDO parameter

RECORD

04 - 68 280 000/A Version 1.0.0

M UNSIGNED8

rw

M

2

UNSIGNED32

rw

M

16#80000000

UNSIGNED32

rw

M

16#80000000

3rd Server-SDO parameter

M

Page K-26

Parameter of 1st ServerSDO Max. number of entries COB-Id of 1st Client-> Server-SDO (reception) COB-Id of 1st Server-> Client-SDO (transm.) Parameter of 2nd Server-SDO Max. number of entries COB-Id of 2nd Client-> Server-SDO (reception) COB-Id of 2nd Server-> Client-SDO (transm.) Parameter of 3rd Server-

K Communication via CANopen

Index

SubIndex

Object

Name

Type/ Value Range

Manual digsy®

Attrib.

Category4

Default Value

Detailed Description SDO

0

Number of entries

UNSIGNED8

rw

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1203h

RECORD

4th Server-SDO parameter

M

0

Number of entries

UNSIGNED8

rw

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

Max. number of entries COB-Id of 3rd Client-> Server-SDO (reception) COB-Id of 3rd Server-> Client-SDO (transm.) Parameter of 4th ServerSDO Max. number of entries COB-Id of 4th Client-> Server-SDO (reception) COB-Id of 4th Server-> Client-SDO (transm.)

Communication Profile Area (SDO-Client Area) 1280h

RECORD

1st Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client->Server (Rx) COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

UNSIGNED32

rw

M

16#80000000

2 1281h

RECORD

2nd Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1282h

RECORD

3rd Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1283h

RECORD

4th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1284h

RECORD

5th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1285h

RECORD

6th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1286h

RECORD

7th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1287h

RECORD

8th Client -SDO parameter

M

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

Page K-27

Parameter of 1st ClientSDO Max. number of entries COB-Id of 1st Client-> Server-SDO (reception) COB-Id of 1st Server-> Client -SDO (transm.) Parameter of 2nd ClientSDO Max. number of entries COB-Id of 2nd Client-> Server-SDO (reception) COB-Id of 2nd Server-> Client -SDO (transm.) Parameter of 3rd ClientSDO Max. number of entries COB-Id of 3rd Client-> Server-SDO (reception) COB-Id of 3rd Server-> Client -SDO (transm.) Parameter of 4th ClientSDO Max. number of entries COB-Id of 4th Client-> Server-SDO (reception) COB-Id of 4th Server-> Client -SDO (transm.) Parameter of 5th ClientSDO Max. number of entries COB-Id of 5th Client-> Server-SDO (reception) COB-Id of 5th Server-> Client -SDO (transm.) Parameter of 6th ClientSDO Max. number of entries COB-Id of 6th Client-> Server-SDO (reception) COB-Id of 6th Server-> Client -SDO (transm.) Parameter of 7th ClientSDO Max. number of entries COB-Id of 7th Client-> Server-SDO (reception) COB-Id of 7th Server-> Client -SDO (transm.) Parameter of 8th ClientSDO Max. number of entries COB-Id of 8th Client-> Server-SDO (reception) COB-Id of 8th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

1288h

Object RECORD

Name

Type/ Value Range

Attrib.

9th Client -SDO parameter

Manual digsy® Category4 M

Default Value

0

Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1289h

RECORD 0

10th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Ah

RECORD

M

0

11th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Bh

RECORD

M

0

12th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Ch

RECORD

M

0

13th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Dh

RECORD

M

0

14th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Eh

RECORD

M

0

15th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

128Fh

RECORD

M

0

16th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1290h

RECORD

M

0

17th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1291h

RECORD

M

0

18th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

M

Page K-28

Detailed Description Parameter of 9th ClientSDO Max. number of entries COB-Id of 9th Client-> Server-SDO (reception) COB-Id of 9th Server-> Client -SDO (transm.) Parameter of 10th Client-SDO Max. number of entries COB-Id of 10th Client-> Server-SDO (reception) COB-Id of 10th Server-> Client -SDO (transm.) Parameter of 11th Client-SDO Max. number of entries COB-Id of 11th Client-> Server-SDO (reception) COB-Id of 11th Server-> Client -SDO (transm.) Parameter of 12th Client-SDO Max. number of entries COB-Id of 12th Client-> Server-SDO (reception) COB-Id of 12th Server-> Client -SDO (transm.) Parameter of 13th Client-SDO Max. number of entries COB-Id of 13th Client-> Server-SDO (reception) COB-Id of 13th Server-> Client -SDO (transm.) Parameter of 14th Client-SDO Max. number of entries COB-Id of 14th Client-> Server-SDO (reception) COB-Id of 14th Server-> Client -SDO (transm.) Parameter of 15th Client-SDO Max. number of entries COB-Id of 15th Client-> Server-SDO (reception) COB-Id of 15th Server-> Client -SDO (transm.) Parameter of 16th Client-SDO Max. number of entries COB-Id of 16th Client-> Server-SDO (reception) COB-Id of 16th Server-> Client -SDO (transm.) Parameter of 17th Client-SDO Max. number of entries COB-Id of 17th Client-> Server-SDO (reception) COB-Id of 17th Server-> Client -SDO (transm.) Parameter of 18th Client-SDO Max. number of entries COB-Id of 18th Client-> Server-SDO (reception) COB-Id of 18th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

1292h

Object RECORD

Name

Type/ Value Range

Attrib.

Manual digsy® Category4 M

Default Value

0

19th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1293h

RECORD 0

20th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1294h

RECORD

M

0

21st Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1295h

RECORD

M

0

22nd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1296h

RECORD

M

0

23rd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1297h

RECORD

M

0

24th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1298h

RECORD

M

0

25th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

1299h

RECORD

M

0

26th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Ah

RECORD

M

0

27th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Bh

RECORD

M

0

28th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

M

Page K-29

Detailed Description Parameter of 19th Client-SDO Max. number of entries COB-Id of 19th Client-> Server-SDO (reception) COB-Id of 19th Server-> Client -SDO (transm.) Parameter of 20th Client-SDO Max. number of entries COB-Id of 20th Client-> Server-SDO (reception) COB-Id of 20th Server-> Client -SDO (transm.) Parameter of 21st ClientSDO Max. number of entries COB-Id of 21st Client-> Server-SDO (reception) COB-Id of 21st Server-> Client -SDO (transm.) Parameter of 22nd Client-SDO Max. number of entries COB-Id of 22nd Client-> Server-SDO (reception) COB-Id of 22nd Server-> Client -SDO (transm.) Parameter of 23rd Client-SDO Max. number of entries COB-Id of 23rd Client-> Server-SDO (reception) COB-Id of 23rd Server-> Client -SDO (transm.) Parameter of 24th Client-SDO Max. number of entries COB-Id of 24th Client-> Server-SDO (reception) COB-Id of 24th Server-> Client -SDO (transm.) Parameter of 25th Client-SDO Max. number of entries COB-Id of 25th Client-> Server-SDO (reception) COB-Id of 25th Server-> Client -SDO (transm.) Parameter of 26th Client-SDO Max. number of entries COB-Id of 26th Client-> Server-SDO (reception) COB-Id of 26th Server-> Client -SDO (transm.) Parameter of 27th Client-SDO Max. number of entries COB-Id of 27th Client-> Server-SDO (reception) COB-Id of 27th Server-> Client -SDO (transm.) Parameter of 28th Client-SDO Max. number of entries COB-Id of 28th Client-> Server-SDO (reception) COB-Id of 28th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

129Ch

Object RECORD

Name

Type/ Value Range

Attrib.

Manual digsy® Category4 M

Default Value

0

29th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Dh

RECORD 0

30th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Eh

RECORD

M

0

31st Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

129Fh

RECORD

M

0

32nd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A0h

RECORD

M

0

33rd Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A1h

RECORD

M

0

34th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A2h

RECORD

M

0

35th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A3h

RECORD

M

0

36th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A4h

RECORD

M

0

37th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A5h

RECORD

M

0

38th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

04 - 68 280 000/A Version 1.0.0

M

Page K-30

Detailed Description Parameter of 29th Client-SDO Max. number of entries COB-Id of 29th Client-> Server-SDO (reception) COB-Id of 29th Server-> Client -SDO (transm.) Parameter of 30th Client-SDO Max. number of entries COB-Id of 30th Client-> Server-SDO (reception) COB-Id of 30th Server-> Client -SDO (transm.) Parameter of 31st ClientSDO Max. number of entries COB-Id of 31st Client-> Server-SDO (reception) COB-Id of 31st Server-> Client -SDO (transm.) Parameter of 32nd Client-SDO Max. number of entries COB-Id of 32nd Client-> Server-SDO (reception) COB-Id of 32nd Server-> Client -SDO (transm.) Parameter of 33rd Client-SDO Max. number of entries COB-Id of 33rd Client-> Server-SDO (reception) COB-Id of 33rd Server-> Client -SDO (transm.) Parameter of 34th Client-SDO Max. number of entries COB-Id of 34th Client-> Server-SDO (reception) COB-Id of 34th Server-> Client -SDO (transm.) Parameter of 35th Client-SDO Max. number of entries COB-Id of 35th Client-> Server-SDO (reception) COB-Id of 35th Server-> Client -SDO (transm.) Parameter of 36th Client-SDO Max. number of entries COB-Id of 36th Client-> Server-SDO (reception) COB-Id of 36th Server-> Client -SDO (transm.) Parameter of 37th Client-SDO Max. number of entries COB-Id of 37th Client-> Server-SDO (reception) COB-Id of 37th Server-> Client -SDO (transm.) Parameter of 38th Client-SDO Max. number of entries COB-Id of 38th Client-> Server-SDO (reception) COB-Id of 38th Server-> Client -SDO (transm.)

K Communication via CANopen

Index

SubIndex

12A6h

Object RECORD

Name

Type/ Value Range

Attrib.

Manual digsy® Category4 M

Default Value

0

39th Client -SDO parameter Number of entries

UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

12A7h

RECORD 0

40th Client -SDO parameter Number of entries

M UNSIGNED8

ro

M

2

1

COB-Id Client Server (Rx)

UNSIGNED32

rw

M

16#80000000

2

COB-Id Server->Client (Tx)

UNSIGNED32

rw

M

16#80000000

Detailed Description Parameter of 39th Client-SDO Max. number of entries COB-Id of 39th Client-> Server-SDO (reception) COB-Id of 39th Server-> Client -SDO (transm.) Parameter of 40th Client-SDO Max. number of entries COB-Id of 40th Client-> Server-SDO (reception) COB-Id of 40th Server-> Client -SDO (transm.)

Communication Profile Area (RxPDO Communication Area) 1400h

RECORD 0

RxPDO-Parameter

M

Parameter of 1st RxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000200

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

1401h

RECORD 0

RxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000300

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

1402h

RECORD 0

RxPDO-Parameter

M

Max. subindex of Index 1400h COB-Identifier of 1st RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) no function Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 2nd RxPDO Max. subindex of Index 1401h COB-Identifier of 2nd RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 3rd RxPDO Max. subindex of Index 1402h COB-Identifier of 3rd RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000400

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 4th RxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000500

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

Max. subindex of Index 1403h COB-Identifier of 4th RxPDO Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

1403h

RECORD 0

04 - 68 280 000/A Version 1.0.0

RxPDO-Parameter

M

Page K-31

K Communication via CANopen

Index

SubIndex

1404h

Object

RECORD 0

Name

Type/ Value Range

Attrib.

RxPDO-Parameter

Manual digsy® Category4

Default Value

Detailed Description (ATTENTION: not used in the case of RxPDO) Parameter of 5th RxPDO

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) Parameter of 6th RxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

Max. subindex of Index 1405h COB-Identifier of 6th RxPDO In this case inactive Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

5

Event timer

UNSIGNED16

rw

O

0

1405h

RECORD 0

RxPDO-Parameter

M

Max. subindex of Index 1404h COB-Identifier of 5th RxPDO In this case inactive Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function

:

:

:

:

:

:

:

:

Time for timer in [ms] (ATTENTION: not used in the case of RxPDO) :

:

:

:

:

:

:

:

:

:

143Fh

RECORD 0

RxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

0

4

Compatibility entry

UNSIGNED8

rw

O

0

5

Event timer

UNSIGNED16

rw

O

0

Parameter of 64th RxPDO Max. subindex of Index 143Fh COB-Identifier of 64th RxPDO In this case inactive Transmission type, in this case asynchronous Inhibit time (ATTENTION: not used in the case of RxPDO) No function Time for timer in [ms] (ATTENTION: not used in the case of RxPDO)

Communication Profile Area (RxPDO Mapping Area) 1600h

RECORD

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A8C00140

1601h

1602h

RxPDO mapping

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 2nd Mapped application object

UNSIGNED32

rw

C

16#A8C00240

RECORD

04 - 68 280 000/A Version 1.0.0

RxPDO mapping

M

Page K-32

Mapping parameter of 1st RxPDO Max. subindex of Index 1600h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1024 Mapping parameter of 2nd RxPDO Max. subindex of Index 1601h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1032 Mapping parameter of

K Communication via CANopen

Index

SubIndex

Object

Name

Type/ Value Range

Manual digsy®

Attrib.

Category4

Default Value

Detailed Description 3rd RxPDO

0

Largest subindex supported

UNSIGNED8

rw

M

1

:

:

:

:

:

:

:

:

Max. subindex of Index 1602h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1040 Mapping parameter of 4th RxPDO Max. subindex of Index 1603h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1048 Mapping parameter of 5th RxPDO Max. subindex of Index 1604h 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1056 :

1

PDO-Mapping for the 3rd Mapped application object

UNSIGNED32

rw

C

16#A8C00340

:

:

:

:

:

:

:

:

:

1603h

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 4th Mapped application object

UNSIGNED32

rw

C

16#A8C00440

1604h

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 5th Mapped application object

UNSIGNED32

rw

C

16#A8C00540

163Fh

RECORD

RxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 64th Mapped application object

UNSIGNED32

rw

C

16#A8C00240

Mapping parameter of 64th RxPDO Max. subindex of Index 163Fh 0 -> deactivated 1..8 -> activated Reception of an UNSIGNED64 with a data length of 64 bits from %MB1528

Communication Profile Area (TxPDO Communication Area) 1800h

RECORD 0

TxPDO-Parameter

M

Parameter of 1st TxPDO

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000180

2

Transmission type

UNSIGNED8

rw

M

254 10

Max. subindex of Index 1800h COB-Identifier of 1st TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

1801h

RECORD 0

TxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000280

2

Transmission type

UNSIGNED8

rw

M

254 10

Parameter of 2nd TxPDO Max. subindex of Index 1801h COB-Identifier of 2nd TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000380

2

Transmission type

UNSIGNED8

rw

M

254

3

Inhibit time

UNSIGNED16

rw

O

10

1802h

RECORD 0

04 - 68 280 000/A Version 1.0.0

TxPDO-Parameter

M

Page K-33

Parameter of 3rd TxPDO Max. subindex of Index 1802h COB-Identifier of 3rd TxPDO Transmission type, in this case asynchronous3 Inhibit time in [ms]

K Communication via CANopen

Index

SubIndex 4

Object

Attrib.

Compatibility entry

Type/ Value Range UNSIGNED8

Event timer

UNSIGNED16 UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#00000480

2

Transmission type

UNSIGNED8

rw

M

254 10

5 1803h

RECORD 0

Name

Manual digsy®

rw

Category4 O

Default Value 0

rw

O

0

TxPDO-Parameter

M

Detailed Description No function Time for timer in [ms] Parameter of 4th TxPDO Max. subindex of Index 1803h COB-Identifier of 4th TxPDO Transmission type, in this case asynchronous Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254 10

1804h

RECORD 0

TxPDO-Parameter

M

Parameter of 5th TxPDO Max. subindex of Index 1804h COB-Identifier of 5th TxPDO In this case inactive Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

183Fh

RECORD 0

TxPDO-Parameter

M UNSIGNED8

ro

M

5

1

Largest subindex supported COB-ID used by PDO

UNSIGNED32

rw

M

16#80000000

2

Transmission type

UNSIGNED8

rw

M

254 10

Parameter of 64th TxPDO Max. subindex of Index 183Fh COB-Identifier of 64th TxPDO In this case inactive Transmission type, in this case asynchronous3 Inhibit time in [ms]

3

Inhibit time

UNSIGNED16

rw

O

4

Compatibility entry

UNSIGNED8

rw

O

0

No function

5

Event timer

UNSIGNED16

rw

O

0

Time for timer in [ms]

Communication Profile Area (TxPDO Mapping Area) 1A00h

RECORD

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400140

1A01h

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400240

1A02h

1A03h

TxPDO mapping

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400340

RECORD

04 - 68 280 000/A Version 1.0.0

TxPDO mapping

M

Page K-34

Mapping parameter of 1st TxPDO Max. subindex of Index 1A00h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB0 Mapping parameter of 2nd TxPDO Max. subindex of Index 1A01h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB8 Mapping parameter of 3rd TxPDO Max. subindex of Index 1A02h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB8 Mapping parameter of 4th TxPDO

K Communication via CANopen

Index

SubIndex 0

Object

Name Largest subindex supported

Type/ Value Range UNSIGNED8

Attrib.

UNSIGNED32

Manual digsy®

rw

Category4 M

Default Value 1

rw

C

16#A4400440

Detailed Description

:

:

:

:

:

:

:

:

Max. subindex of Index 1A03h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB16 Mapping parameter of 5th TxPDO Max. subindex of Index 1A04h 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB24 :

:

:

:

:

:

:

:

:

:

1

1A04h

PDO-Mapping for the 1st Mapped application object

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4400540

1A3Fh

RECORD

TxPDO mapping

M

0

Largest subindex supported

UNSIGNED8

rw

M

1

1

PDO-Mapping for the 1st Mapped application object

UNSIGNED32

rw

C

16#A4404040

04 - 68 280 000/A Version 1.0.0

Page K-35

Mapping parameter of 5th TxPDO Max. subindex of Index 1A3Fh 0 -> deactivated 1..8 -> activated Transmission of an UNSIGNED64 with a data length of 64 bits from %MB504

K Communication via CANopen

K.2.1.2.1

Allocation of the network variables

Data type[%..] Int8/Uint8 INT16/UINT16 INT/UINT32 8-String REAL (32Bit) LREAL (64Bit) UINT64 (64Bit)

MB0

MW

MB1

0 MD SO MD

MB2

MW 0 CT 0

MB3

1

MB4

MW

MB5

2 MD

Manual digsy®

MB6

MW 1

MB7

3

0 MD

1

...

M2044 M2045 M2046 M2047

... ... ... ... ... ... ...

MW SO MD

1022 MD CT 511

MW 511 255

1023

Figure K.6 Storage allocation of the flag area in the IEC 1131 Network input variables (from the perspective of the CAN-bus): Read-Only-Variables (TxPDOs) (Note: from the perspective of the Prosyd 1131: Output variables): Variable types SINT USINT/ BYTE BOOL

INT WORD/ UINT DINT/ UDINT/ DWORD REAL Int64 Uint64

from %MB0

from %MB256

from %MB512

from %MB768

to %MB1023

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

A000 A040

1 - 255 1 - 255

A001 A041

1 – 255 1 – 255

A002 A042

1 - 255 1 - 255

A003 A043

1 - 255 1 - 255

A080 A0C0 A100

1 - 255 1 - 128 1 - 128

A081 A0C0 A100

1 – 255 128-255 128-255

A082 A0C1 A101

1 - 255 1 - 128 1 - 128

A083 A0C1 A101

1 - 255 128-255 128-255

A1C0

1 - 64

A1C0

65 – 128

A1C0

129-192

A1C0

193-255

A240 A400 A440

1 - 64 1 - 32 1 - 32

A240 A400 A440

65 – 128 33 – 64 33 – 64

A240 A400 A440

129-192 65 - 96 65 - 96

A240 A400 A440

193-255 97 - 128 97 – 128

Table K.6 Index and Subindex allocation for the TxPDOs Network output variables (from the perspective of the CAN-bus): Read-Write-Variables (RxPDOs) (Note: from the perspective of the Prosyd 1131: Input variables) Variable types SINT USINT/ BYTE BOOL

INT WORD/UI NT DINT/

from %MB0

from %MB256

from %MB512

from %MB768

to %MB1023

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

A480 A4C0

1 - 255 1 - 255

A481 A4C1

1 – 255 1 – 255

A482 A4C2

1 - 255 1 - 255

A483 A4C3

1 - 255 1 - 255

A500 A540

1 - 255 1 - 128

A501 A542

A502 A543

1 - 255 1 - 128

A503 A543

1 - 255 128 - 255

A580

1 - 128

A582

A583

1 - 128

A583

128 - 255

A640

1 - 64

A640

1 – 255 128 – 255 128 – 255 65 – 128

A640

129 -

A640

193 - 255

04 - 68 280 000/A Version 1.0.0

Page K-36

K Communication via CANopen

Variable types

from %MB0 Input ,

from %MB256 Subindex (Offset)

Input ,

Manual digsy®

from %MB512 Subindex (Offset)

Input ,

from %MB768 Subindex (Offset)

to %MB1023

Input ,

Subindex (Offset)

A6C0

193 - 255

A880 A8C0

97 - 128 97 - 128

192

UDINT/ DWORD REAL

A6C0

1 - 64

A6C0

65 – 128

A6C0

Int64 Uint64

A880 A8C0

1 - 32 1 - 32

A880 A8C0

33 – 64 33 – 64

A880 A8C0

129 192 65 - 96 65 - 96

Table K.7 Index and Subindex allocation for the RxPDOs

ATTENTION:

The flag area cannot fully be mapped with the network variables. For more details please refer to the chapter „Mapping in digsy®compact E/ digsy®CGM“.

K.2.1.3 Differences between digsy®compact and digsy®CGM A different assignment of the object directory entries takes only place in the area of the communication characteristics (Communication Characteristics Area). The following indices of the object directory are affected: • • • • •

1000h 1008h 1009h 100Ah and 1018h

All the other entries of the object directory have the same contents or an identical way of treatment.

04 - 68 280 000/A Version 1.0.0

Page K-37

K Communication via CANopen

Manual digsy®

K.2.2 Default settings in digsy®compact / digsy®CGM The following default settings from the object directory are to be emphasized:

K.2.2.1 Default PDOs / Default PDO-Mapping According to the CANopen–standard DS3.02 (V4.01), 4 transmission PDOs (1800H to 1803H) and 4 reception PDOs (1400H to 1403H) are configured as a default setting to the above defined objects. The automatic setting comprises the parameterization (area 1400h..143Fh and 1800h..183Fh) and the mapping (area 1600h..163Fh and 1A00h..1A3Fh). For a standard configuration that means that only the COB-Ids of the additional PDOs are to be set up. Thus, the configuration effort per digsy®compact or digsy®CGM is considerably reduced (even from the point of view of time). All the available TxPDOs are set via default as events with 10ms inhibit-time.

NOTE: Symbol/ PDO-No. Rx.PDO1 Rx.PDO2

Object Index A8C0Hex A8C0Hex

Object SubIndex 1 2

Rx.PDO3 Rx.PDO4

A8C0Hex A8C0Hex

3 4

Symbol/ PDO-No. Tx.PDO1 Tx.PDO2 Tx.PDO3 Tx.PDO4

Object Index A440Hex A440Hex A440Hex A440Hex

Object SubIndex 1 2 3 4

@ Operand %MB1024 %MB1032

Uint64 Uint64

PDO-DIC-Index Param. Mapping 1400hex 1600 hex 1401hex 1601 hex

%MB1040 %MB1048

Uint64 Uint64

1402hex 1403hex

Type

PDO-DIC-Index Param. Mapping 1800hex 1A00 hex 1801hex 1A01hex 1802hex 1A02hex 1803hex 1A03hex

@ Operand %MB0 %MB8 %MB16 %MB24

Type

Uint64 Uint64 Uint64 Uint64

COB-ID (Hex) x=Node-ID(1-32) 00000200 hex + x 00000300 hex + x

1602 hex 00000400 hex + x 1603 hex 00000500 hex + x COB-ID (Hex) x=Node-ID(1-32) 00000180 hex + x 00000280 hex + x 00000380 hex + x 00000480 hex + x

Table K.8 Default-PDOs in the case of digsy®compact E / digsy®CGM For closer details on the network variables please refer to the Chapter K.4.3 „Mapping in digsy®compact E/ digsy®CGM“.

NOTE:

K.2.2.2 NMT-values The following default values exist for nodeguarding: • •

TGuarding := 512 ms Life-time-factor nLIFETIME:= 3

04 - 68 280 000/A Version 1.0.0

Page K-38

K Communication via CANopen

Manual digsy®

K.2.3 Function blocks and functions under PROSYD 1131 K.2.3.1 Introduction The configuration of the CANopen-characteristics of a freely programmable device of the type digsy®compact E / digsy®CGM is to be carried out from the application program, the same applies to the network guarding, the SDO-transfer of process data, the transmission of SYNC-objects and the general error handling. For this, a series of functions and function blocks is available:

NOTE:

Presently, the mechanism of the synchronization via SYNC-objects is not fully implemented yet.

NOTE:

The Chapter K.8 „Error Handling“ provides important aids for an error handling in a running system. It is very advisable to use this means.

NOTE:

The transmission and reception of process data after a successful setup of the default data is automatically effected in the background of the application program.

04 - 68 280 000/A Version 1.0.0

Page K-39

K Communication via CANopen

Manual digsy®

K.2.3.2 Initialization of the CAN-bus and setup of objects K.2.3.2.1

CM_Init(): Setting up a CANopen-node

This function is used as an alternative to the previous function COPINIT(). The parameterization of the network node is to be carried out with the function CM_Init(): • node number • CANopen-slave or CANopen-manager • type of network guarding • type of error handling • type of SYNC-handling Only then will the CANopen – stack be set up. Function : CM_Init() 1131-Library: CANopen401.LIB Application: in CANopen-slave or in CANopen-manager Function symbol: CM_Init NodeId CanSpeed NodeType GuardType EmcyType SyncTime

Function input NodeId

Data type BYTE

CanSpeed

WORD

Description node-Id of CAN-node; range of values 1..32 transmission rate (acc. to CiA): KBD_1000 KBD_500 KBD_250 KBD_125 KBD_100 KBD_50 KBD_20 KBD_10 KBD_800

NodeType

04 - 68 280 000/A Version 1.0.0

BYTE

type of network node: 0 = CANopen–slave 1 = CANopen-manager

Page K-40

K Communication via CANopen

Function input

Data type

GuardType

BYTE

EmcyType

BYTE

SyncTime

WORD

Function output ErrorState

INT

Data type

Manual digsy®

Description >= 2 reserved type of guarding: 0 = no guarding 1 = guarding by master6 10 = heartbeat producer 20 = heartbeat producer + consumer type of error handling: 0 = no emergency message 1 = emergency message – producer 10 = emergency message producer + consumer7 (note: in the data structure TSysOut. en_emergency the emergency messages to be output are filtered) type of SYNC-handling (permissible synchronization): 0 : no Sync < 25 : not permissible >= 25 : Sync-time (should be a multiple of the AWP(application program) cycle time) Description 0 = OK < 0 error number (see Chapter K.2.4)

Example:

Figure K.7 Use of CM_INIT()

NOTE:

After successfully calling CM_Init(), the device is initialized as a CANopennode. This forms the basis for all further steps regarding the CANopen-network (see also Table K.20).

NOTE:

In the case of a new implementation, the function CM_Init() is to be absolutely preferred to the function COPINIT().

6 7

only in the case of CANopen-slave only in the case of CANopen-manager

04 - 68 280 000/A Version 1.0.0

Page K-41

K Communication via CANopen

K.2.3.2.2

Manual digsy®

COPINIT(): Setting up a CANopen-node – DcP/DcE-compatible

NOTE:

This function was used in digsy®compact and continues to be available for compatibility reasons. However, in the case of new implementations it is advisable to use always CM_Init().

The parameterization of the CANopen–node is to be effected with the function COPINIT(). Function : COPINIT() 1131-Library: CANopen401.LIB Application: in CANopen-slave or if an older, already existing implementation is to be adopted. Function symbol: COPINIT NodeId CanSpeed

Function input NodeId

Data type BYTE

CanSpeed

WORD

Description node-Id of CAN-node; range of values 1..32 transmission rate (acc. to CiA): KBD_1000 KBD_500 KBD_250 KBD_125 KBD_100 KBD_50 KBD_20 KBD_10 KBD_800

Function output ErrorState

Data type BOOL

Description TRUE = OK FALSE = error when setting up CANopen

Example:

Figure K.8 Use of COPINIT()

04 - 68 280 000/A Version 1.0.0

Page K-42

K Communication via CANopen

K.2.3.2.3

Manual digsy®

COBADD() : Setting up a new entry in the object directory:

The function COBADD() is available for setting up further CANopen object-directory-entries:

ATTENTION:

The objects have to be set up prior to the CANopen-initialization.

Function : COBADD() 1131-Library: CANopen401.LIB Application: CANopen-slave or CANopen-manager Function symbol: COBADD Index Subindex Attribute DataType DataLen

DefValue Object TransType

Function input Index SubIndex Attribute

Data type WORD BYTE WORD

DataType

WORD

DataLen

BYTE

04 - 68 280 000/A Version 1.0.0

Description

CANopen – Index CANopen – Subindex ATTR_RW, ATTR_RO, in the case of PDOs: extension "PDO_MAP " to be added: e.g., ATTR_RW + PDO_MAP -BOOLEAN -INTEGER8 -INTEGER16 -INTEGER32 -UNSIGNED8 -UNSIGNED16 -UNSIGNED32 -FLOAT -VISIBLE_STRING -OCTET_STRING -DOMAIN object size in bytes: -BOOLEAN :=1 -INTEGER8:=1 -INTEGER16:=2 -INTEGER32:=4

Page K-43

K Communication via CANopen

Function input

DefValue

Data type

TransType

POINTER TO BYTE POINTER TO BYTE WORD

Function output ErrorState

Data type BOOL

Object

Manual digsy®

Description -UNSIGNED8:=1 -UNSIGNED16:=2 -UNSIGNED32:=4 -FLOAT:=4 -VISIBLE_STRING:= max 255 OCTET_STRING:=8 -DOMAIN:=max. 255 bytes pointer to default value ZERO, if not available pointer to the current data object TYPE_TX TYPE_RX Description 0 = not executed 1 = prepared

It is possible to set up objects in the index area 2000H to 5FFFH, 6000h..9FFFh as well as the indices 100Ch, 100Dh, 1016H and 1017H. In this connection, however, it has to be taken into account that PDOs are only defined and mapped in the area of the %QW, %IW and %MW. For this purpose, the extension PDO_MAP is to be additionally inserted in the input word Attribute. Objects which are to be transferred only by means of SDO can be defined in any storage area whatever. If an object is to have several subindices, it has to be taken into account that a subindex 0 is defined with the number of the further subindices. The consistency of complex objects (i.e., with several subindices) is not checked by the system. SDOs can be defined in any storage area with the DataLen := DOMAIN. An SDO, however, is limited to 255 bytes.

ATTENTION:

An SDO defined as a data type DOMAIN can transfer a maximum of 255 bytes.

Example:

Figure K.9 Use of COBADD()

04 - 68 280 000/A Version 1.0.0

Page K-44

K Communication via CANopen

K.2.3.2.4

Manual digsy®

CM_AddNode(): Setting up the node list

To be able to set up further CANopen-nodes it is necessary to make their characteristics known to the CAN-manager or other CANopen-nodes. For each SDO-server in a node the SDO-client belonging to it is set up with this function, in this connection the number of the handle is equal to the node number. Function : CM_AddNode() 1131-Library: CANopen401.LIB Application: CANopen-slave or CANopen-manager Function symbol: COBADD node_no mode guardtime lifetime

Function input node_no

Data type BYTE

mode

BYTE

guardtime lifetime

WORD BYTE

Function output ErrorState

INT

NOTE:

Data type

Description 0 – ill. node number 1-32 number of the node >32 – ill. node number 0 := no guarding mechanism in the case of this node BIT0 : =1 : node guarding BIT1 : =1 : heartbeat BIT4-BIT7 : reserved guard-time or heartbeat-time in [ms] life time factor Description 0 = OK < 0 = error numbers

The guardtime and lifetime entered with CM_AddNode() have to correspond with the values of the node to be set up. Within the scope of this function these values are not transferred to the CANopen-node node_no belonging to it.

The following objects of the object directory are influenced by this function:

04 - 68 280 000/A Version 1.0.0

Page K-45

K Communication via CANopen

Mode Nodeguarding Heartbeat

Guardtime 16#100C 16#1017 := guardtime * lifetime or if lifetime := 0: 16#1617 := guardtime * 1

Manual digsy® Lifetime 16#100D

Table K.9 Objects of the object directory belonging to CM_AddNode()

NOTE:

If, prior to calling the function CM_AddNode(), SDO-channels with the same handle were set up with the function SDOADD(), they are eliminated by the function CM_AddNode() and its own handle is set up instead.

Example: Setting up the CANopen-slave 3 for nodeguarding and the SDO-channel

Figure K.10 Use of CM_AddNode()

04 - 68 280 000/A Version 1.0.0

Page K-46

K Communication via CANopen

K.2.3.2.5

Manual digsy®

CM_Reset():CM_Reset(): Resetting the network settings of the control unit

With this function all static variables of the firmware are reset to the default values. This becomes necessary, if a node is to be initialized anew with CM_Init() or CM_AddNode(). Function : CM_Reset() 1131-Library: CANopen401.LIB Application: CANopen-Manager Function symbol: CM_Reset wMode

Function input wMode

Data type WORD

Function output ErrorState

INT

NOTE:

Objects set up with COBADD() are not reset by this function.

Data type

Description reserved Description 0 = OK < 0 = error numbers

Example:

Figure K.11 Use of CM_Reset()

04 - 68 280 000/A Version 1.0.0

Page K-47

K Communication via CANopen

Manual digsy®

K.2.3.3 NMT and guarding mechanisms K.2.3.3.1

CM_SetNodeState(): Setting the node state

Via the function CM_SetNodeState() the master/manager is in a position to insert either the entire network or single nodes into the working network, i.e., by setting the node states. With CM_GetNodeState() the state of each node can be determined in the master. The following states can be initiated by the master: • RESET • RESET_COM • PREOPERATIONAL • PREPARED • OPERATIONAL Function : CM_SetNodeState( ) 1131-Library: CANopen401.LIB Application: CANopen-Manager Function symbol: CM_SetNodeState node_no cmnd

Function input node_no

Data type BYTE

Cmnd

ECanNetCmnd

Function output ErrorState

INT

04 - 68 280 000/A Version 1.0.0

Data type

Description 0 – entire network 1-32 number of the node >32 – ill. node number 0 = reset Node/Net 1 = reset Comm 4 = STOPPING (set PREPARED) 5 = STARTING (set OPERATIONAL) 127 = INITIALIZING (set PREOPERATIONAL)

Description 0 = OK < 0 = error numbers

Page K-48

K Communication via CANopen

Example:

Figure K.12 Use of CM_SetNodeState()

04 - 68 280 000/A Version 1.0.0

Page K-49

Manual digsy®

K Communication via CANopen

K.2.3.3.2

Manual digsy®

CM_GetNodeState(): Reading the node state of a slave

Via this function the node state of a node is returned.

ATTENTION:

In the case of a foreign node, only the state last received via guarding or heartbeating is returned. If nodes are not guarded (see CM_StartStopGuarding()), they are mapped with the state 1 or, if a boot-up was received, with the state 127, although another node state may exist.

Function : CM_GetNodeState( ) 1131-Library: CANopen401.LIB Application: CANopen-Manager or CANopen- Slave Function symbol: CM_GetNodeState node_no

Function input node_no

Data type BYTE

Description 0 – NET-State (own state) 1-32 - number of the node >32 – ill. node number

Function output node_state

Data type INT

Description 0 < error numbers 1 = INIT 4 = STOPPED (PREPARED) 5 = STARTED (OPERATIONAL) 127 = INITIALIZED (PREOPERATIONAL)

In CANopen-manager and CANopen-slave this function is differently handled:

CANopen-slave

CANopen-manager

Nodeguarding Provides the node status only in the case of an own node number or, in the case of a heartbeat consumer the states of it, too. Provides the currently transmitted guarding value of the node

Table K.10 Functionality in manager and in slave

04 - 68 280 000/A Version 1.0.0

Page K-50

Heartbeat Provides the last state of the guarded node which was entered in the heartbeat list with CM_AddNode() Provides the currently transferred heartbeat producer value of the node

K Communication via CANopen

Manual digsy®

Example:

Figure K.13 Use of CM_GetNodeState()

K.2.3.3.3

CM_StartStopGuarding(): Starting or stopping the network guarding

By means of the function CM_StartStopGuarding () a network or a particular node can be activated for guarding or the guarding mechanism can be deactivated. Guarding of the node/network is only possible in the PREOPERATIONAL-state. Prerequisite: The node to be guarded was set up with CM_AddNode().

ATTENTION:

A prerequisite for this is that the node to be guarded was set up with CM_AddNode().

Function : CM_StartStopGuarding(.) 1131-Library: CANopen401.LIB Application: CANopen-manager or CANopen-slave Function symbol: CM_StartStopGuarding node_no mode

Function input node_no

Data type BYTE

mode:

BYTE

Function output ErrorState

04 - 68 280 000/A Version 1.0.0

Description 0 – entire network 1-32 node number >32 – ill. node number 0: STOP_WATCHING: stop watching BIT1: GUARDING: guarding mode BIT2: HEARTBEATING heartbeat mode BIT1+BIT2: start guarding (only with node_no := 0 for all nodes)

Data type INT

Description 0 = OK < 0 = error numbers

Page K-51

K Communication via CANopen

Function input

NOTE:

Data type

Description > 0 = error with the node, error state if node_no := 0

By calling CM_StartStopGuarding(0,3) the entire network is started. In this connection, the guarding mechanism (node guarding or heartbeat) for the respective node is automatically selected from the internal node list. In the case of an error, this function will be aborted and the number of the affected node is transferred as a return value. Thereby, the guarding mechanism was activated only in the case of those nodes which have been set up with CM_AddNode() before the error node. The cause of the error will be output, if this node is individually started.

Example:

Figure K.14 Use of CM_StartStopGuarding()

04 - 68 280 000/A Version 1.0.0

Manual digsy®

Page K-52

K Communication via CANopen

K.2.3.3.4

Manual digsy®

: CM_Guarding(): Heartbeat and guarding mechanism

After starting the guarding with the function CM_StartStopGuarding() the function CM_Guarding() has to be cyclically called. With this function num participants from the node list generated with CM_AddNode() are guarded. In this connection, the following is to be taken into account: Note on the guardtime: This is the minimum time period. In CM_Guarding() a comparison takes place as to whether or not the node may be guarded again. If the minimum time period is exceeded, guarding is effected, otherwise not before the next call. This does not mean that the guarding takes place exactly at the guardtime. Example: guardtime := 500ms; CM_Guarding() calls the guarding of this node every t≈400ms. Thus it may happen, that the node is only guarded again after t≈800ms. Note regarding the call of CM_Guarding(): With every call only num nodes are guarded at the same time. Example: 2 nodes are to be guarded in the network. In the case of CM_Guarding() num is:= 1. Consequently, the node will try to guard only with every 2nd !! call.

ATTENTION:

The guarding of the nodes is not automatically carried out by the firmware.

Function : CM_Guarding() 1131-Library: CANopen401.LIB Application: CANopen-Manager Function symbol: CM_Guarding num Function input num

Data type BYTE

Function output State

INT

Data type

Description number of nodes to be guarded Description 0 = OK 1 ... 32 failed nodes < 0 = error numbers

Example:

04 - 68 280 000/A Version 1.0.0

Page K-53

K Communication via CANopen

Manual digsy®

Figure K.15 Use of CM_Guarding() Note regarding the reaction in the case of a detection of a node failure: In this connection, when its entry in the node list generated with CM_AddNode() is reached, the failed node will be instantly output and the further execution of the function stopped. Within the scope of error handling it has to be ensured that the guarding is executed (suitable in terms of time) for the further CANopen-slaves (e.g., by repeatedly calling it in the node-failure-handling-routine).

04 - 68 280 000/A Version 1.0.0

Page K-54

K Communication via CANopen

Manual digsy®

K.2.3.4 Functions and function blocks for SDO-transfer As a standard, 40 client and 4 server channels each are reserved for digsy®CGM and digsy®compact E (due to CANopen–manager). In the „predefined connection set“, however, only 1 server-SDO is basically set up. Further SDOs for a node can be set up via the PROSYD1131–function SDOADD(), which, however, is not in conformity with CANopen.

K.2.3.4.1

SDOADD(): Setting up SDO-channels

This function adds an SDO-Client/-Server. It is possible to set up a maximum of 40 SDOclient or 4 SDO-server channels.

NOTE:

In the case of the CANopen-manager the first 32 default-clientchannels are for the function CM_AddNode(), all further channels have to be set up by the user (from channel number 33 to channel number 40).

Function : SDOADD( ) 1131-Library: CANopen401.LIB Application: CANopen-slave or CANopen-manager Function symbol: SDOADD Id1 Id2 SDO_Type

Id1

Function input

Data type WORD

Id2

WORD

SDO_Type

BOOL

Function output SDO_Handle

Data type BYTE

04 - 68 280 000/A Version 1.0.0

Description Client-Tx-Id: 600h+node-ID Server-Tx-Id.: 580h+ node-ID Client-Rx-Id: 580h+ node-ID Server-Rx-Id: 600h+ node-ID TRUE: client-SDO, FALSE: server-SDO Description 0 := error or no further SDO available 1...40 client-handle 1...4 server-handle

Page K-55

K Communication via CANopen

Manual digsy®

The following possibility of distributing unassigned SDO-server-IDs is recommended when using the node-IDs 1..32: Node-Id 1 10 ... 16 ... 31 32

Default 581H + 601H 58AH + 60AH

SDO2 5A1H + 621H 5AAH + 62AH

SDO3 5C1H + 641H 5CAH + 64AH

SDO4 5E1H + 661H 5EAH + 66AH

590H + 610H

5B0H + 630H

5D0H + 650H

5F0H + 670H

59FH + 61FH 5A0H + 620H

5BFH + 63FH 5C0H + 640H

5DFH + 65FH 5E0H + 660H

5FFH + 67FH -

Table K.11 Possibility of distributing unassigned SDO-server-IDs Example:

Figure K.16 Use of SDOADD()

K.2.3.4.2

CM_SDO_RW(): Executing an SDO-transfer

This function block enables an SDO-read or SDO–write transfer. A call of this function is only possible after CM_Init()/COPINIT() has been called up. The maximum data length Length is 255 bytes. Function block: CM_SDO_RW(.) 1131-Library: CANopen401.LIB Application: CANopen-slave or CANopen-manager Function block symbol:

CM_SDO_RW Start Handle Index Subindex Mode Length DataPtr

04 - 68 280 000/A Version 1.0.0

Page K-56

Status ErrorPar1 ErrorPar2 CurrLength

K Communication via CANopen

VAR_INPUT Start

Data type BYTE

Description SDO_NONE:=0: FB not active SDO-transfer SDO_READ:=1 activate FB for read transfer SDO_WRITE:=2 activate FB for write transfer later optional SDO_READ_BLK SDO_WRITE_BLK

Handle

BYTE

Master: client 1-32: corresponds with node-ID, 33-40 = handle from SDOADD() Slave: client 1-40: node-ID to be addressed CANopen-object index CANopen-object subindex reserved object length in [BYTE] presently a maximum of 255 bytes is possible

WORD BYTE BYTE WORD

DataPtr

POINTER TO BYTE

VAR_OUT

Data type INT

Error_Par1 Error_Par2 CurrLength

WORD WORD WORD

Start := SDO_READ: destination of the read data Start := SDO_WRITE: source of the data to be written

Description 0: transfer is finished >0: transfer is still active 0: transfer active no message is output ) NO_ERROR := 16#01 -> normal message is output WARNING := 16#02 -> warnings are output USER_ERROR := 16#04 -> user error is output APP_ERROR := 16#08 -> application error is output SYS_ERROR := 16#10 -> system error is output 16#1F -> all are output TSystemIn.CanType SYSIN_CanType 1 -> CANopen-manager 0 -> CANopen-slave TSystemIn.CanNodeState SYSIN_CanNodeState Own CANopen node-status TSystemOut.set_CanType SYSOUT_setCanType Setting the own node state (only if CANopen-manager) TSystemOut.set_CanNodeState SYSOUT_setCANNodeState presently without function TSystemOut.en_emergency SYSOUT_EnableEmergency Mask for EMERGENCY-outputs on the CAN-bus: ( default: 0 -> no message is output ) NO_ERROR := 16#01 -> normal message is output WARNING := 16#02 -> warnings are output USER_ERROR := 16#04 -> user error is output APP_ERROR := 16#08 -> application error is output SYS_ERROR := 16#10 -> system error is output 16#1F -> all are output (ATTENTION: in the case of a value > 0, the value set in TSystemCfg.en_emergency will be overwritten)

04 - 68 280 000/A Version 1.0.0

Page K-66

K Communication via CANopen

Manual digsy®

K.2.5.2 digsy®CGM Data structures TSystemCGMIn.CanType

Adjustable control configuration SYSIN_CanType

TSystemCGMIn.CanNodeState TSystemCGMOut.set_CanType

SYSIN_CanNodeState SYSOUT_setCanType

TSystemCGMOut.set_CanNodeState TSystemCGMOut.en_emergency

SYSOUT_setCANNodeState SYSOUT_EMCY_MASK

04 - 68 280 000/A Version 1.0.0

Page K-67

Description 1 -> CANopen-Manager 0 -> CANopen-Slave own CANopen-node-state setting the own node status (only if CANopen-manager) presently without function mask for EMERGENCY-outputs on the CAN-bus: ( default: 0 -> no message is output) NO_ERROR := 16#01 -> normal message is output WARNING := 16#02 -> warnings are output USER_ERROR := 16#04-> user error is output APP_ERROR := 16#08 -> application error is output SYS_ERROR := 16#10 -> system error is output 16#1F -> all are output

K Communication via CANopen

Manual digsy®

K.2.6 Summary The following table gives an overview of the usable functions or function blocks in dependence on the implementation in a CANopen-manager or a CANopen-slave: Function / Function block CM_Init COPINIT() COBADD() CM_AddNode() CM_Reset() CM_SetNodeState() CM_GetNodeState() CM_StartStopGuarding() CM_Guarding() SDOADD() CM_SDO_RW() SDOTRANS() CM_DCFTrans() CM_PDO_Sync()

CANopen-Manager X X X X X X X X X X X X X X

CANopen-Slave X X X X X X X X X -

Table K.13 Overview of the functions / function blocks regarding the application

04 - 68 280 000/A Version 1.0.0

Page K-68

K Communication via CANopen

Manual digsy®

K.3 SDO-Transfer K.3.1 Basics An SDO functions according to the Client/Server principle. Between 2 network participants a logic point-to-point connection is established. An SDO always transfers an object from the object directory of a network participant. Access is effected via index and via subindex. An SDO always contains the index and the subindex of an object-directory-entry. There a 3 types of SDO-transfers: • • •

Segmented transfer (normal SDO-transfer) Expedited transfer (expedited transfer for a small data volume (max. 4 bytes)) Block transfer (transfer of a very large data volume)

K.3.1.1 Segmented SDO-transfer In general, the segmented SDO-transfer is used for the transfer of data. A segmented SDOtransfer consists of the following 2 functional groups: 1. Initiate SDO-down-/upload: Here, the client asks the server, whether it is allowed to receive (download) or to transmit (upload) data. Thus, it generates a request to the SDO-server (initiate SDO-down-/upload) and transfers the index and the subindex of the object directory entry to be influenced as well as the data length. The SDO-server replies with an SDO-response (initiate response). The confirmation message (response) to it contains an activation of the transfer or a rejection of the initiated transfer. 2. Upon activation of the transfer the data are segmented, i.e., transferred in blocks of up to 7 bytes per request cycle, until the requested data length has been completely transferred. The following figure shows the corresponding flow diagram:

04 - 68 280 000/A Version 1.0.0

Page K-69

K Communication via CANopen

Manual digsy® Server

Client Initiate SDO Upload/ Initiate SDO-Download Initiate Response Upload SDO-Segment/ Download SDO-Segment + Data Upload SDO-Segment response + Data/ Download SDO-Segment Response Upload SDO-Segment/ Download SDO-Segment + Data Upload SDO-Segment response + Data/ Download SDO-Segment Response

Figure K.20 Format for segmented SDO-write or SDO-read operations Since the introducing SDO-transfer has different individual SDO-transfer types, it is here once again explained in more detail: Client Request

Server Data 4 Byte

Subindex 1 Byte

Index 2 Byte

Status field 1 Byte

Confirmation

Indication

Response Statusfeld 1 Byte

Index 2 Byte

Subindex 1 Byte

Reserved 4 Byte

Figure K.21 Initiate SDO-download

NOTE:

04 - 68 280 000/A Version 1.0.0

The message data of the SDO-transfer are in the status field. For closer details on its contents please refer to the CANopen-specification DS301 V4.01.

Page K-70

K Communication via CANopen

Manual digsy®

K.3.1.2 Expedited SDO download The protocol of the expedited SDO-transfer is similar to that of the segmented SDO-transfer. The transfer, however, was modified so that only the block of the „Initiate SDO Download“ is used. The SDO-client generates only once a request to the SDO-server which in turn replies only once. Thus, it is only possible to transfer the index, subindex and a data field of a size of max. 4 bytes. In this connection, the data field Data does not contain the length of the data field to be transferred but the data themselves are transmitted in it.

K.3.1.3 Block transfer In the case of the „Block transfer“ the segments transferred in the „segmented SDO-transfer“ are combined to blocks which are then transferred in series. In this connection, only the single blocks are confirmed, not every single segment.

K.3.2 SDO-transfer in the case of digsy®compact E/ digsy®CGM The following functions and function blocks are available for the SDO-transfer: • • •

SDOADD() CM_SDO_RW() CM_DCFTrans()

If a network node plays the role of the CANopen-manager, an SDO-channel has to be set up in it for each CANopen-slave known to it.

K.3.2.1 SDOADD() When implementing a CANopen-manager it is necessary to set up an SDO-client for each CANopen-slave-node set up with CM_AddNode(). For this, the function SDOADD() is to be used. By means of it, additional SDO-clients or SDO-servers can be set up (see also Chapter K.2.3.4.1 SDOADD(): Setting up SDO-channels).

NOTE:

The call of SDOADD() has to be effected prior to calling CM_AddNode().

To be able to call data of all the other CANopen–slaves/manager from an identified CANopennode, it is necessary to set up an additional SDO-channel each. Since the dynamic SDO-allocation is not yet implemented in digsy®compact E or digsy®CGM, the reading node has to set up the appropriate client-channels (not the Default-SDO-channels !!!!) and each digsy®compact E / digsy®CGM the corresponding additional server-SDO-channel. This approach is not in conformity with CANopen! To accelerate the data transfer, it is possible to set up several SDO-channels for each digsy®compact E/ digsy®CGM. This also involves the setup of a default-node to be newly parameterized.

04 - 68 280 000/A Version 1.0.0

Page K-71

K Communication via CANopen

Manual digsy®

K.3.2.2 CM_SDO_RW() A segmented SDO-transfer is carried out with the function block CM_SDO_RW(). In this context, the input value Start determines, whether an SDO-download or an SDO-upload is to take place. The input value Handle determines the SDO-channel to be used. As described in Chapter K.3.1.1, the following is needed for the SDO-initiation: the object entry index Index, its subindex Subindex, and the data length Length of the data to be transferred. From this follows that these are the required input data for the segmented SDO-transfer. The data which are then in the segments transferred or received, are stored in the data field towards which the pointer DataPtr is directed. Depending on the data length, this SDO-transfer can take a relatively long time, so that the Output variable Status includes various options. If Status > 0, the SDO-transfer is still active. In the case of Status < 0, an error has occurred. If Status := CM_OK, the transfer has been successfully completed. In this connection, see also Chapter K.2.3.4.2 CM_SDO_RW(): Executing an SDOtransfer. Example: In this case, the heartbeat-producer-time of node 13 is to be changed to the time tPRODUCER=2500ms. This value is stored as a WORD-variable in the object directory under index 16#1017 and subindex 16#01. If this entry is made, the heartbeat-producer-time for this node will change:

Figure K.22 Changing the heartbeat-producer-time via SDO-transfer for node 13

04 - 68 280 000/A Version 1.0.0

Page K-72

K Communication via CANopen

Manual digsy®

K.3.2.3 CM_DCFTrans() This function block represents a special adaptation of the function block CM_SDO_RW(). With it, only an „expedited SDO-download“ is possible, i.e., the maximum data length Length is 4 bytes. If the value of Totalnum := 1, exactly one SDO-transfer will be carried out. This is explained by the following table, in the case of which an identical SDO-download with CM_SDO_RW() and CM_DCFTrans() is initiated: Value INPUT: Start SDO-channel Index Subindex Length No. of SDO-transfers Pointer towards data OUTPUT: Status ErrorPar1 ErrorPar2 CurrNum CurrPtrData

CM_SDO_RW()

CM_DCFTrans()

TRUE Handle := 3 16#1017 1 2 DataPtr (pointer to Length-size element)

TRUE Node_No := 3 TConDCF-element Idx := 16#1017 TConDCF-element SubIdx := 1 TConDCF-element Length := 2 TotalNum := 1 PtrData (pointer to TConDCF-element)

Error handling Additional error value Additional error value -

Error handling Additional error value Additional error value Initiated SDO-transfers -> here max. 1 In this case on PtrData

Table K.14 Identical SDO-transfer with CM_SDO_RW() and CM_DCFTrans() With the number of SDO-transfers TotalNum the process of the SDO-transfer can be automated to the effect that a complete list of SDOs in the mode-format is automatically transferred with a single start. Since for setting up the COB-identifier and for the mapping of the individual PDOs an „expedited SDO-download“ is sufficient, this function block is predestined for this application (see Chapter K.4.1.2 „Basic information on digsy®compact E/“). The following Figure shows how via CM_DCFTrans() 5 SDOs are transferred to node 3. For this, TxPDO5 is set up with COB-Id 16#2A3 for the transmission of 2 bytes each:

04 - 68 280 000/A Version 1.0.0

Page K-73

K Communication via CANopen

Figure K.23 Example regarding CM_DCFTrans()

In the CANanalyzer the execution of this program looks as follows: Num Time Id Data -----------------------------------------------------------------------------------------------------------------821 00:52:40.193.6 603 23 05 18 01 A3 02 00 00 #...£... 822 00:52:40.203.1 583 60 05 18 01 00 00 00 00 `....... 823 00:52:40.236.1 603 2F 05 1A 00 00 00 00 00 /....... 824 00:52:40.256.4 583 60 05 1A 00 00 00 00 00 `....... 825 00:52:40.298.1 603 23 05 1A 01 08 29 40 A0 #....)@ 826 00:52:40.300.6 583 60 05 1A 01 00 00 00 00 `....... 827 00:52:40.325.8 603 23 05 1A 02 08 2A 40 A0 #....*@ 828 00:52:40.327.7 583 60 05 1A 02 00 00 00 00 `....... 829 00:52:40.351.1 603 2F 05 1A 00 02 00 00 00 /....... 830 00:52:40.376.6 583 60 05 1A 00 00 00 00 00 `.......

Figure K.24 CANanalyzer-output

04 - 68 280 000/A Version 1.0.0

Page K-74

Manual digsy®

K Communication via CANopen

Manual digsy®

K.4 Mapping and COP-ID-setup in digsy®compact / digsy®CGM K.4.1 Basics K.4.1.1 General For the data exchange, each CANopen-node has process-data-objects(PDO). In this connection, a difference is to be made between PDOs which are already set up and cannot be changed any more (static system) and PDOs that can be set up in a user-related way (dynamic system). In principle, the data exchange via PDOs has the following features: • • • •

A transmitted PDO (TxPDO) has a definite identifier (COB-Id) which is exclusively assigned to it. This PDO can be received by several reception-PDOs (RxPDO). In this connection, their identifier must be identical with that of the RxPDO(s). The data contents of the PDOs (Rx- and Tx-page) belonging together have to be known and must be defined with the same data length. The data field of the PDOs must be identically configured, i.e., both the TxPDO and the RxPDO(s) should be of the same data type(s).

For setting up the COB-Ids or for mapping, the following indices are provided for under CANopen: Index in CANopen-object -directory 16#1400 + number of PDO (max. 16#1FF acc. to DS301) 16#1600 + number of PDO (max. 16#1FF acc. to DS301) 16#1800 + number of PDO (max. 16#1FF acc. to DS301) 16#1A00 + number of PDO (max. 16#1FF acc. to DS301)

Meaning COB-Identifier RxPDO Mapping RxPDO COB-Identifier TxPDO Mapping TxPDO

Table K.15 Meaning of the relevant indices in the object directory

The following figure shows this principle. The CANopen-node with the node-Id 3 has a TxPDO1 with the COB-ID := 16#0183 and transfers a data word of a size of 64 bits. Each of the CANopennodes 2, 4, 12, and 22 has an RxPDO1 with the COB-ID := 16#0183 and thus, when data are transferred with this COB-identifier via the CAN-network, they can receive these data. Since they too have been configured in a way such that they are able to receive a data word of a size of 64 bits a data exchange is carried out:

04 - 68 280 000/A Version 1.0.0

Page K-75

K Communication via CANopen

Manual digsy®

CANopen-Network Node-Id 4 (Receiver)

Node-Id 2 (Receiver) Index 16#1400 16#1600

Index 16#1400 16#1600

Subindex Value 16#01 16#00000183 16#01 16#A8C00140

Subindex Value 16#01 16#00000183 16#01 16#A8C00140

Node-Id 12 (Receiver) Index 16#1400 16#1600

Node-Id 3 (Transmitter) Index 16#1800 16#1A00

Subindex Value 16#01 16#00000183 16#01 16#A4400140

Subindex Value 16#01 16#00000183 16#01 16#A8C00140

Node-Id 22 (Receiver) Index 16#1400 16#1600

Subindex Value 16#01 16#00000183 16#01 16#A8C00140

Figure K.25 Principle of data exchange via PDO

How the data exchange via PDOs functions in the case of digsy®compact / digsy®CGM: In digsy®CGM and digsy®compact E the PDO-data are stored in the flag area. A clearly defined memory location in the flag area, which is allocated to the PDO, is the interface for the date exchange via the CAN-Bus:

DCE

CGM Flag area

Flag area TxPDOs

RxPDOs

TxPDOs

CAN-Bus

RxPDOs

Figure K.26 Principle of data exchange via PDOs in the case of digsy®compact / digsy®CGM

04 - 68 280 000/A Version 1.0.0

Page K-76

K Communication via CANopen

Manual digsy®

However, it is necessary to make a setting in order to allocate ranges of values, memory areas and identifiers to the individual PDOs. In this connection, the data field for the COB-identifiers contains the number of the identifier; the data field of a size of 32 bits, however, has the following basic structure:

MSB

LSB

Index (16 Bit)

Subindex (8 Bit)

Data length (8 Bit)

Figure K.27 Structure of a mapping-entry

K.4.1.2 Basic information on digsy®compact E/ digsy®CGM K.4.1.2.1

Structure of the Config-objects for an SDO-transfer to the CANopen-nodes

For the configuration of CANopen-manager and CANopen-slaves the following structure is to be defined in the Prosyd 1131: TYPE TConDCF : STRUCT Idx: SubIdx: Length: LData: END_STRUCT END_TYPE

WORD; BYTE; BYTE; DWORD;

(* CANopen-Object-Index *) (* CANopen-Object-SubIndex *) (* Data length of the object or data field to be transferred*) (* 32Bit Data field *)

By means of this structure it is possible to generate several lists (e.g., for the CANopen-manager and for the respective CANopen-slave-nodes). With the function block CM_DCFTrans() the elements of this structure are transmitted via SDO-transfer to the individual participants (see also example project in Chapter K.9.3 „Implementation of the CANopen-manager“).

K.4.1.2.2

COB-Identifier-setup

Via the COB-identifier the PDOs are linked to the individual CANopen-nodes. As the DS301 V4.0 indicates, in CANopen the identifiers in the area 16#0181 – 16#077Fh are available for the PDOs. Consequently, identifiers not used according to this arrangement may be freely assigned in the network.

K.4.1.2.3

Re-mapping process

04 - 68 280 000/A Version 1.0.0

Page K-77

K Communication via CANopen

Manual digsy®

The re-mapping process consists of the following steps: 1. Reset mapping: the subindex 0 used in the CANopen-object-directory for PDO-mapping is to be written on with the value 0. 2. Configuration of the PDO: the data in the format acc. to Figure K.27 are to be written on with the individual subindices (larger 0) and here the subindex determines the object to be mapped. 3. Declaring the mapping valid: the subindex 0 used in the CANopen-object-directory for PDOmapping is to be written on with the number of the subindices transmitted in point 2 (a maximum of 8 entries is possible). The following example shows the CANanalyzer-output of a configuration of the RxPDO9 of node 3 with 3 INT-values and the identifier of the PDO to be received with the value 16#1C2: Num Time Id Data -----------------------------------------------------------------------------------------------------------------89 00:00:34.127.4 603 23 08 14 01 C2 01 00 00 #...Â... 90 00:00:34.129.9 583 60 08 14 01 00 00 00 00 `....... 91 00:00:34.142.8 603 2F 08 16 00 00 00 00 00 /....... 92 00:00:34.157.7 583 60 08 16 00 00 00 00 00 `....... 93 00:00:34.168.1 603 23 08 16 01 10 21 40 A5 #....!@¥ 94 00:00:34.171.8 583 60 08 16 01 00 00 00 00 `....... 95 00:00:34.183.2 603 23 08 16 02 10 22 40 A5 #...."@¥ 96 00:00:34.185.9 583 60 08 16 02 00 00 00 00 `....... 97 00:00:34.198.5 603 23 08 16 03 10 23 40 A5 #....#@¥ 98 00:00:34.199.9 583 60 08 16 03 00 00 00 00 `....... 99 00:00:34.208.8 603 2F 08 16 00 03 00 00 00 /....... 100 00:00:34.216.4 583 60 08 16 00 00 00 00 00 `.......

Figure K.28 CANanalyzer-output For digsy®CGM and digsy®compact E, the appropriate list in the CDCF-format, which is transferred with the function block CM_DCFTrans(), looks as follows:

Figure K.29 CDCF-list of the example

K.4.2 Setting up the COB-Ids In digsy®CGM and digsy®compact E the following COB-identifiers are set up by Default:

TxPDO-Number TxPDO1

04 - 68 280 000/A Version 1.0.0

COB- Identifier 200h + node number

RxPDO-Number RxPDO1

Page K-78

COB-Identifier 180h + node number

K Communication via CANopen

TxPDO-Number TxPDO2 TxPDO3 TxPDO4

COB- Identifier 300h + node number 400h + node number 500h + node number

RxPDO-Number RxPDO2 RxPDO3 RxPDO4

Manual digsy® COB-Identifier 280h + node number 380h + node number 480h + node number

Table K.16 Default-COB-Ids in digsy®CGM and digsy®compact E If further COB-Ids are to be set up or existing ones are to be changed, a reconfiguration has to be carried out. As the DS301 V4.0 shows, in CANopen the identifiers in the area 16#0181 – 16#077Fh are available for the PDOs. Consequently, identifiers not used according to this arrangement may be freely assigned in the network. Example: Setting up the COB-identifiers of 16 TxPDO (in this case, e.g., node 2)

Figure K.30 Setting up the COB-identifiers of 16 TxPDOs

04 - 68 280 000/A Version 1.0.0

Page K-79

K Communication via CANopen

Manual digsy®

K.4.3 Mapping in digsy®compact E/ digsy®CGM In this context, the specification CiA DSP-405 is used as a basis. In the process image, additional certain segments with fixed indices and fixed allocations to the addresses are defined. In this connection, there exists a linear mapping between index and address. Within digsy®CGM and digsy®compact E the complete flag area (presently %MB0 to %MB2047) can be mapped to the CAN-bus. The network variables can be addressed in the flag area. In total, there are 2048 bytes available within this area (%MB0..%MB2047). Within the scope of the IEC-standard 1131 the memory allocation is as follows: Data type[%..] Int8/Uint8 INT16/UINT16 INT/UINT32 8-String REAL (32Bit) LREAL (64Bit) UINT64 (64Bit)

MB0

MW

MB1

0 MD SO MD

MB2

MW 0 CT 0

MB3

1

MB4

MW

MB5

2 MD

MB6

MW 1

MB7

3

0 MD

1

...

M2044 M2045 M2046 M2047

... ... ... ... ... ... ...

MW SO MD

1022 MD CT 511

MW 511 255

1023

Figure K.31 Memory allocation of the flag area in the IEC 1131 Within the flag area the lower 1024 bytes are usable for the TxPDOs, whereas the upper 1024 bytes are used for the RxPDOs. Consequently, the TxPDOs start from %MB0 and the RxPDOs from %MB1024. The RxPDOs, however, are to be counted up from „0“, too, i.e., %MB1024 corresponds with the subindex(or Offset) 0. In the case of an access via the CAN-bus the index and subindex are given. The index indicates both the data type and thus its data width, too. The appropriate address can be calculated as follows: Offset = (Subindex - 1) * Data width Equation K.1 Offset determination Consequently, the following subdivision results for the network-objects: Network input variables (from the perspective of the CAN-bus): Read-Only-variables (TxPDOs) (Note: from the perspective of the Prosyd 1131: output variables): Variable types SINT USINT/ BYTE BOOL

INT

from %MB0

from %MB256

from %MB512

from %MB768

to %MB1023

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

A000 A040

1 - 255 1 - 255

A001 A041

1 – 255 1 – 255

A002 A042

1 - 255 1 - 255

A003 A043

1 - 255 1 - 255

A080 A0C0

1 - 255 1 - 128

A081 A0C0

1 – 255 128-255

A082 A0C1

1 - 255 1 - 128

A083 A0C1

1 - 255 128-255

04 - 68 280 000/A Version 1.0.0

Page K-80

K Communication via CANopen

Manual digsy®

Variable types

from %MB0

WORD/ UINT DINT/ UDINT/ DWORD REAL Int64 Uint64

A100

1 - 128

A100

128-255

A101

1 - 128

A101

128-255

A1C0

1 - 64

A1C0

65 – 128

A1C0

129-192

A1C0

193-255

A240 A400 A440

1 - 64 1 - 32 1 - 32

A240 A400 A440

65 – 128 33 – 64 33 – 64

A240 A400 A440

129-192 65 - 96 65 - 96

A240 A400 A440

193-255 97 - 128 97 – 128

from %MB256

from %MB512

from %MB768

to %MB1023

Table K.17 Index and subindex allocation for the TxPDOs

Network output variables (from the perspective of the CAN-bus): Read-Write-variables (RxPDOs) (Note: from the perspective of the Prosyd 1131: input variables) Variable types SINT USINT/ BYTE BOOL

from %MB0

from %MB256

from %MB512

to %MB1023

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

Input ,

Subindex (Offset)

A480 A4C0

1 - 255 1 - 255

A481 A4C1

1 – 255 1 – 255

A482 A4C2

1 - 255 1 - 255

A483 A4C3

1 - 255 1 - 255

A500 A540

1 - 255 1 - 128

A501 A542

A502 A543

1 - 255 1 - 128

A503 A543

1 - 255 128 - 255

A580

1 - 128

A582

A583

1 - 128

A583

128 - 255

A640

129 192

A640

193 - 255

129 192 65 - 96 65 - 96

A6C0

193 - 255

A880 A8C0

97 - 128 97 - 128

WORD/UI NT DINT/ UDINT/ DWORD REAL

A640

1 - 64

A640

1 – 255 128 – 255 128 – 255 65 – 128

A6C0

1 - 64

A6C0

65 – 128

A6C0

Int64 Uint64

A880 A8C0

1 - 32 1 - 32

A880 A8C0

33 – 64 33 – 64

A880 A8C0

INT

from %MB768

Table K.18 Index and subindex allocation for the RxPDOs

ATTENTION:

Since the subindex (Offset) can address a maximum of 254 elements, it is for consistency reasons - on the index boundaries partly not possible to allocate flag areas within the IEC-1131-notation.

Example: Via the index A4C0h a data area of a size of 1 byte is indicated. Thus, according to the Equation K.1, the flag byte %MB254 is occupied by the maximum offset 255 (FFh). According to Table K.18 , however, the following next larger index A4C1h, Offset 1 lies on the flag byte %MB256. Hence, there exists a flag byte %MB255 which therefore cannot be allocated.

04 - 68 280 000/A Version 1.0.0

Page K-81

K Communication via CANopen

Manual digsy®

In digsy®CGM and digsy®compact E it is possible to set up a maximum of 64 TxPDOs and 64 RxPDOs each. The communication objects are predefined and set up through the initialization of CANopen. In this connection, the following setting (Default mapping) is applicable: RxPDO 1 2 3 4 5 : 64 TxPDO 1 2 3 4 5 : 64

Communication parameter index (16#14xx) 16#1400 16#1401 16#1402 16#1403 16#1404 : 16#143F Communication parameter index (16#18xx) 16#1800 16#1801 16#1802 16#1803 16#1804 : 16#183F

Default value of the Mapping Default value of communication index mapping parameter (16#16xx) 16#A8C0|01|40 16#200 + Node-Id 16#1600 16#A8C0|02|40 16#300 + Node-Id 16#1601 16#A8C0|03|40 16#400 + Node-Id 16#1602 16#A8C0|04|40 16#500 + Node-Id 16#1603 16#A8C0|05|40 16#80000000 (inactive) 16#1604 : : : 16#A8C0|40|40 16#80000000 (inactive) 16#163F Default value of the Mapping Default value of communication index mapping parameter (16#1Axx) 16#A440|01|40 16#180 + Node-Id 16#1A00 16#A440|02|40 16#280 + Node-Id 16#1A01 16#A440|03|40 16#380 + Node-Id 16#1A02 16#A440|04|40 16#480 + Node-Id 16#1A03 16#A440|05|40 16#80000000 (inactive) 16#1A04 : : : 16#A440|40|40 16#80000000 (inactive) 16#1A3F

Memory area PROSYD 1131 %MB1024..%MB1031 %MB1032..%MB1039 %MB1040..%MB1047 %MB1048..%MB1055

%MB1528..%MB1535

Memory area PROSYD 1131 %MB0..%MB7 %MB8..%MB15 %MB16..%MB23 %MB24..%MB31

%MB504..%MB511

Table K.19 Default mapping in digsy®CGM and digsy®compact E This default mapping has the advantage that the PDOs, e.g., when transmitting words or double words, do not have to be re-mapped (reconfigured) and that the setting of the communication object index is sufficient in order to use the PDO. If other allocations to the individual PDOs are to be formed, re-mapping is necessary. The mapping value Ldata (length: 4 bytes) from the structure TConDCF consists of index, subindex and data length[bit]:

MSB

LSB

Index (16 Bit)

Subindex (8 Bit)

Data length (8 Bit)

Figure K.32 Structure of an object-mapping-entry for digsy®CGM and digsy®compact E

Example: The 2nd TxPDO is to be mapped in the flag area from %MB8 to %MB15 and is to consist of the following data structure:

04 - 68 280 000/A Version 1.0.0

Page K-82

K Communication via CANopen

MSB %MB15

%MB14

WORD

%MB13

%MB12

%MB11

WORD

BYTE

Manual digsy®

%MB10

%MB9

BYTE

BYTE

LSB %MB8 BYTE

Figure K.33 Contents of the example-TxPDO The SDO-transfer with CM_DCFTrans(), by means of which this PDO is set up, consists of the following data in the CDCF-format:

Figure K.34 Mapping data of the example-PDO in Prosyd 1131

04 - 68 280 000/A Version 1.0.0

Page K-83

K Communication via CANopen

Manual digsy®

K.4.4 Mapping of slaves – in this case with DIGSYcompact In digsy®compact every communication object first has to be set up with the function COPADD(). There are no default-PDOs like in digsy®compact E. The access from the CANopen-manager is effected according to the specified object with the dynamic objects lying in the index range from 16#2000 to 16#2FFF. The memory area, where the data of the Tx- or RxPDOs lie, is freely selectable. It is advisable, however, to deposit all data in the flag area.

NOTE:

In the digsy®compact, no objects are arranged in the initialization part, since the used object types and object lengths are not yet known. The PDOs will only be dynamically arranged by the setup via the CANopenmanager.

In the DcP too, the mapping value Ldata of a length of 4 bytes consists of index, subindex and data length[bit]:

MSB

LSB

Index (16 Bit)

Subindex (8 Bit)

Data length (8 Bit)

Figure K.35 Structure of an object-mapping-entry for digsycompact Explanatory example: The data word 16#iiiissll to be mapped shall be occupied with the value 16#20400908. In this connection, iiii := 16#2040 corresponds with the index of COBADD(); ss := 16#09 is the subindex of COBADD() and ll := 16#08 (data length 8 bits) corresponds with the entry Len of COBADD(). Example: In the DcP, communication objects are arranged which are set up via the CANmanager. The data of the TxPDOx and RXPDOx have been defined in the flag area.

Figure K.36 Setting up the communication objects in the DcP-Slave

04 - 68 280 000/A Version 1.0.0

Page K-84

K Communication via CANopen

Manual digsy®

Here, these set up objects are entered in the manager (digsy®compact E or digsy®CGM) in the COB-list and later, when setting up the network, they are allocated during the runup:

Figure K.37 Mapping list of these communication objects in the CANopen-manager

04 - 68 280 000/A Version 1.0.0

Page K-85

K Communication via CANopen

Manual digsy®

K.4.5 Mapping of slaves – in this case with CGC The CGC has 32 input areas(%IW) and 32 output areas(%QW). Each of these areas includes a memory size of 128 bytes or 64 words. The CGC is accessed via word or bit operations. The access from the CANopen-manager is effected according to the specified object with the dynamic objects lying in the index range from 16#2100 to 16#2FFF.

NOTE:

Within the CGC, no objects are arranged in the initialization part, since the used object types and object lengths are not known yet. The PDOs will only be dynamically arranged by the setup via the CANopen-manager.

In the CGC too, the mapping value Ldata of a size of 4 bytes consists of index, subindex and data length[Bit]:

MSB

LSB

Index (16 Bit)

Subindex (8 Bit)

Data length (8 Bit)

Figure K.38 Structure of an object-mapping-entry for the CGC

The meaning of index and subindex is illustrated in the figure below:

04 - 68 280 000/A Version 1.0.0

Page K-86

K Communication via CANopen

Manual digsy®

Specification of the object-index and subindex for IW and QW accesses in CGC: 2

Index Typ. x

x

Subindex y y

Word index (1...64) Group index 16#01 IW1.yy ... 16#40 IW64.yy 16#81 ... 16#C0

QW1.yy QW64.yy

1 2 3 4 5 6 7 8 9 A B C F

BOOLEAN_k INTEGER8 INTEGER16 INTEGER32 UNSIGNED8 UNSIGNED16 UNSIGNED32 (FLOAT) not used VISIBLE_STRING OCTET_STRING TIME_OF_DAY TIME_DIFFERENCE VISIBLE_STRLEN

Figure K.39 Use of index and subindex in the CGC Example: The data word 16#2txxyyll to be mapped is to be occupied with the value 16#268A0110. In this case, the following applies t := 6 (WORD); xx := 16#8A (10); yy := 16#01 (1) -> xx.yy is here the data word %QW10.1 of the CGC and ll := 16#10 (data length 16 bits) The figure shows the list entries for 5 TxPDOs; each TxPDO consists of 4 WORD-variables each:

04 - 68 280 000/A Version 1.0.0

Page K-87

K Communication via CANopen

Figure K.40 Example of a COB-ID and mapping list for the CGC

04 - 68 280 000/A Version 1.0.0

Page K-88

Manual digsy®

K Communication via CANopen

Manual digsy®

K.4.6 Mapping of slaves – in this case standardized nodes acc. to DS301 In standardized CANopen-nodes acc. to the CiA-specification DS301 V4.01 for I/Omodules the input and/or output values are firmly deposited from index 6000h. In the case of these nodes the mapping value Ldata of a length of 4 bytes consists of index, subindex and data length[Bit]:

MSB

LSB

Index (16 Bit)

Subindex (8 Bit)

Data length (8 Bit)

Figure K.41 Structure of an object-mapping-entry Explanatory example: The first 32 digital inputs are allocated to the TxPDO1 of the CANopennode. According to DS301 V4.01 they are in the object directory under the index 6000h and the subindices 1 and 2 with a data length of 16 bits each. The data word 16#iiiissll to be mapped is to be occupied with the value 16#60000110 and 16#60000210. In this connection, iiii := 16#6000 corresponds with the index of the object directory; ss := 16#01 or 16#02 is the subindex of the object directory and ll := 16#10 (data length 16 bits) corresponds with the data length, since, according to the object directory, in this case WORDvariables are transferred.

Figure K.42 Setting up the communication objects in CANopen-nodes acc. to DS301 V4.01 These set up objects are entered in the CANopen-manager (digsy®compact E or digsy®CGM) in the COB-list and later, in the setup of the network, they are allocated during the runup.

04 - 68 280 000/A Version 1.0.0

Page K-89

K Communication via CANopen

K.5 Sequencer

Manual digsy®

for setting up a CANopen-network digsy compact -/ digsy®CGM as a manager

with

®

K.5.1 Steps of the runup sequencer When configuring a network it is advisable to use the existing example projects regarding the CANopen-manager or the CANopen-slaves as a basis. The entire sequencer is processed or executed in the program CAN_Manager(). In this sequencer every step is based on the previous step. We start from the fact that the CAN-network has been reset. INITIALIZATION STAGE: 1. Initialization: Initialization of the CAN-node with the functionality of the CANopen-network manager. -> see function F_Init_CAN() -> CM_Init(). CONFIGURATION STAGE: 2. Setting up the nodes belonging to the network: All the nodes which are used in this network have to be made accessible to the master F_Step1_Init() -> CM_AddNode(). Each node must have been successfully set up in order to be able to carry out the next step. 3. Starting the guarding of the individual nodes: Starting the guarding of the nodes used in the network. IMPORTANT: Each used node is to be guarded. See F_Step2_StartGuard() -> CM_StartStopGuarding(), F_Step3_Guarding() ATTENTION: The guarding should only be started if it has been ensured that each of the used CAN-nodes is really ready. So, for instance, after a network reset of CAN-nodes of the Intercontrol Company it takes approx. t≈500ms until the node sends its Bootup-message and consequently has taken the node state PREOPERATIONAL. If the guarding mechanism Nodeguarding is started before the Bootup-message, a guarding error can occur as a consequence of which the sequencer can no longer be processed. 4. Evaluating the guarding result: Checking whether or not the network can be set up -> Each and every node to be set up must be PREOPERATIONAL. This evaluation is to be made only after it has been ensured that a nodeguard-response or a heartbeat has arrived and been processed. If the nodes can be set up, the CDCF-list(device configuration(Mapping) is to be allocated to the respective node) F_Step4_WaitPreop() 5. Mapping of the CANopen-network: F_Step5_InitDCF(): In this step the SDO-transfer or the self-setup is implemented, by means of which the communication objects are set up and the mapping of the individual nodes is effected. 6. Stopping the network (optional): When all the nodes have been mapped, the network will be stopped. Only one node, which is active on the network, can carry out the state change PREOPERATIONAL->PREPARED/STOPPED (a little more safety that the nodes carried out the mapping and that there was a reaction to the manager. Besides, in the PREPARED-state neither an SDO-exchange nor a PDO-exchange is possible). This happens at the end of F_Step5_InitDCF() 7. If step 6. has been carried out: Check as to whether all nodes have been stopped. F_Step7_Preop().

04 - 68 280 000/A Version 1.0.0

Page K-90

K Communication via CANopen

Manual digsy®

NETWORK-RUN: 8. Starting the network: Network is started -> Switch to OPERATIONAL. F_Step8_Prepared(). Only from now on can the process data (PDOs) be exchanged. The following figure shows in this connection the use of the individual functions or function blocks regarding the sequences in the CANopen-network: CAN-stage Initialization

Configuration

RUN

-

Used functions and function blocks COBADD() CM_Init() COPINIT() CM_AddNode()

-

CM_StartStopGuarding() CM_Guarding()

-

CM_GetNodeState() CM_SetNodeState()

-

CM_DCFTrans() CM_SDO_RW() CM_StartStopGuarding() CM_Guarding()

-

CM_GetNodeState() CM_SetNodeState()

-

CM_SDO_RW()

-

CM_PDO_Sync()

Table K.20 Use of the functions and FBs depending on the „State“ in the CANopen-network

K.5.2 Keeping to the times between the individual steps As regards the processing of the sequencer there are time dependencies between the individual steps. Step sequence Call of CM_Init() until the call of function CM_StartStopGuarding() if guarding-mechanism Nodeguarding (Time t2)

04 - 68 280 000/A Version 1.0.0

Reason During the call of CM_Init() the entire network is reset. Each node has different times until it is responsive in the network again (Bootup-message) If Nodeguarding has been started, a Bootup-message will cause a guarding error

Page K-91

Time required At least the point of time until the node is responsive on the network again (Bootup), in this connection please mind the worst case t ≈ 500ms (should be sufficient)

K Communication via CANopen

Step sequence Call of CM_StartStopGuarding() of a node until inquiry PREOPERATIONAL in the step F_Step4_WaitPreop() (Time t3) Setting the node to the PREPARED-state in F_Step5_DCFTrans() until this state is inquired in the step F_Step7_Preop() (Time t5)

Manual digsy®

Reason In the case of started Nodeguarding, the request of the CANopen-manager must be answered; in the case of a started heartbeat consumer at least one heartbeat of the node must have been received In the case of started Nodeguarding, the request of the CANopen-managers must be answered; in the case of a started heartbeat consumer at least one heartbeat of the node must have been received

Time required Call of CM_Guarding() (one time) is to be waited out. In the case of heartbeat at least tHeartbeat-producer Call of CM_Guarding() (one time) is to be waited out In the case of heartbeat at least tHeartbeat-producer

Table K.21 Time dependencies

The following figure shows these time dependencies: t1

t2

t3

t4

c

d d d d

t5

t6

Master

c

e

d d d d

N4

c

c

d

d

e

d

d

N5

c

c

d

d

e

d

d

N6

c

c

d

e

d

N7

c

Sign

c d e

A

c B

d

d Ce

D

Legend: Meaning Bootup-message Heartbeat or Nodeguarding SDO-transfer HIGH-level: active on the bus LOW-level: inactive on the bus

Figure K.43 Graphical representation of the runup according to the time aspect

04 - 68 280 000/A Version 1.0.0

Page K-92

d

dE

K Communication via CANopen

Manual digsy®

Point of time A (call of CM_Init()): It must be ensured that all the participants to be set up by the CANopen-manager are available in the network. If this is not the case, the node not available at this point of time has to be individually set up. Point of time B (call of CM_StartStopGuarding()): During the call of CM_Init() a reset of the entire network will be effected. Each node has a different time until it is responsive in the network again (indicated by the Bootup-message). ATTENTION: In the case of started Nodeguarding, a received bootup-message causes a guarding error and a deactivation of the guarding. Point of time C (inquiry of the node state PREOPERATIONAL): No matter whether Heartbeat or Nodeguarding, within the period t3 at least one guarding message each (which contains the node state of the node(s)) must have been received. In the case of started Nodeguarding the request of the CANopen-manager must have been answered, in the case of a started Heartbeat-consumer at least one heartbeat of the node must have been received. In this connection, one has to start out from the worst case, i.e., the decisive factor is the longest guarding time or heartbeat-producertime. Point of time D (setting the network to the PREPARED-/STOPPED-state): Only if all the nodes in the network have been set up can the network be set to this state. In the PREPARED state neither SDO-transfer nor PDO-transfer is possible. Point of time E (inquiry of the node state PREPARED/STOPPED): See point of time D. In the case of started Nodeguarding the request of the CANopen-manager must have been answered, in the case of a started Heartbeat-consumer at least one heartbeat of the node must have been received. In this connection, one has to start out from the worst case, i.e., the decisive factor is the longest guarding time or heartbeat-producer-time.

04 - 68 280 000/A Version 1.0.0

Page K-93

K Communication via CANopen

Manual digsy®

K.6 PDO-Transfer K.6.1 PDO: Transfer of values in the REAL-format The CANopen-specification DS301 V4.01 explicitly defines how values in the REAL-format are transferred via the CAN-bus. The compilers, by means of which the firmware of the individual CANopen-nodes was generated, however, have no standard for this. Consequently, it may happen that CANopen-compliant devices transfer REAL-values in a different way.

DIFFERENCE:

The transfer and storage of the first 16 bits of the value (Low-16Bit) and of the higher significant 16 bits of the value (High-16Bit) are effected in a different order.

Device type A (e.g., digsy®compact E, digsy®CGM): Storage of the „High-16Bit“ BEFORE the „Low16Bit“ (this applies both to transmission and reception) Device type B: Storage of the „High-16Bit“ AFTER the „Low-16Bit“ (this applies also both to transmission and reception) If in a CANopen-network REAL-values are transferred from a device of the type A to a device of the type B (or if they are, vice versa, received by it), the „Low-16Bit“ and the „High-16Bit“ are stored in reverse order and thus the numerical value will be misinterpreted. If REAL-values are only transferred among devices of the A-type or of the B-type, the REAL-values require no special treatment and there are no problems. Workaround: Exchanging/swapping the „Low-16Bit“ and the „High-16Bit“ as a step prior to transmitting the REAL-PDO or receiving the REAL-PDO. For this purpose, there exists a function WordSwapOfAReal() in the library CANopen401.lib.

Figure K.44 Swapping the „Low-16Bit“ and the „High-16Bit“ of REAL-values

ATTENTION:

04 - 68 280 000/A Version 1.0.0

Most of the documentation does not explicitly include the treatment of the REAL-values, so that the implementation requires very careful testing.

Page K-94

K Communication via CANopen

Manual digsy®

K.7 NMT Guarding mechanisms In a CANopen-network the individual nodes have to be monitored with regard to their state in the network. For this mechanism the following functions of the library CANopen401.lib are available: • • • • •

CM_Init() CM_AddNode() CM_StartStopGuarding() CM_Guarding() CM_GetNodeState()

K.7.1 Bootup process After switching on the device or after a node reset, a CANopen-node goes automatically over to the node state PREOPERATIONAL. At this stage, the CANopen-node sends a Bootup-message over the network. The CANopen-manager in the network receives this message, provided that this CANopen-node was set up in it (setup with CM_AddNode()). In this connection, it is not necessary that the guarding mechanism has been started. The following table explains this principle: Example: CANopen-slave-node 3 vs. CANopen-manager State of slave-node 3 Off/Reset Switched on (Boot-up), afterwards PREOPERATIONAL Off/Reset Switched on (Boot-up), afterwards PREOPERATIONAL

Execution state of CM_AddNode(3,x,y,z) in the CANopen-manager Not executed Not executed

Return of CM_GetNodeState(3) in CANopen-Manager

Executed Executed

INIT (1) PREOPERATIONAL (127)

CM_NOT_EXISTANT CM_NOT_EXISTANT

Table K.22 Bootup-recognition in digsy®compact / digsy®CGM

K.7.2 Nodeguarding Nodeguarding can only be carried out by the CANopen-manager. It sends a request to each node to be guarded and receives, as an answer from it, the respective node state. (See also Chapter K.1.2.3.1 Nodeguarding). In the digsy®compact E or digsy®CGM the following must be set up and used for the Nodeguardingmechanism: 1. Initialization as CANopen-manager through the function CM_Init() 2. Each node to be guarded must have been set up with the function CM_AddNode(). In this connection, it is important that the entries guardtime correspond with the entry 16#100C of the object directory of the slave-node and lifetime with the entry 16#100D of the object directory of the slave-node.

04 - 68 280 000/A Version 1.0.0

Page K-95

K Communication via CANopen

Manual digsy®

Note: If other guarding times than those of the object directory are to be used, they can be adapted by the CANopen-Manager via an SDO-transfer. This, however, should be done prior to starting the guarding. 3. Start of the guarding or of the nodeguarding with the function CM_StartStopGuarding(). The guarding mechanism will only be active after successfully executing this function. The guardtime (from CM_AddNode()) is the minimum time in the course of which guarding is possible. In CM_Guarding() a comparison takes place as to whether the node may be guarded again or not. If the minimum period guardtime is exceeded, guarding takes place, otherwise the next call is waited out. Consequently, this does not mean that the guarding takes place exactly at the guardtime. Example: guard-time := 500ms; CM_Guarding() calls the guarding of this node every t≈400ms. Thus, it may happen that the node will only be guarded again after t≈800ms.

ATTENTION:

The guarding of the nodes is not automatically carried out by the firmware. Consequently, the application program (AWP) must ensure that CM_Guarding() is called as often as necessary.

Reaction in the case of a guarding error in the digsy®compact E or digsy®CGM: Slave: When a guarding failure is detected (tFailure=guardtime * lifetime) the own node state will be set to PREOPERATIONAL and an entry into the error memory is effected. Master: In the case of a slave-node failure the nodeguarding-mechanism will be deactivated after tFailure=guardtime * lifetime. A failure is visible via the return value of the function CM_Guarding(). Besides, an entry in the error memory is effected. The nodeguarding-mechanism can be restarted by carrying out point 3.

K.7.3 Heartbeat The guarding of the nodes can be carried out both from the CANopen-manager and from the CANopen-slaves. In contrast to nodeguarding this requires no central point which manages the guarding. Thus CANopen-slaves can monitor CANopen-slaves, too.

RECOMMENDATION:

If a CANopen-node supports both nodeguarding and heartbeat, the heartbeat is to be used preferentially in an application.

Heartbeat-producer: In digsy®compact E or in digsy®CGM the Default-heartbeat-producer-time (object directory 16#1017) is tPRODUCER:= 0ms. Consequently, a default value has to be given to this time prior to the CAN-initialization. This is done by setting up the communication object for the index 16#1017 via the COBADD()-function. After successfully carrying out the CAN-initialization, the CAN-node automatically sends its life sign (node state) in tPRODUCER-intervals via the CAN-bus. The following example shows an initialization with the defined tPRODUCER:= 512ms.

04 - 68 280 000/A Version 1.0.0

Page K-96

K Communication via CANopen

Manual digsy®

Figure K.45 Setting the heartbeat-producer-time in the case of digsy®compact E/ digsy®CGM

Heartbeat-consumer: Via the function CM_AddNode() the node to be guarded can be set up and be made accessible with its node-characteristics to the heartbeat-consumer. In this connection, it has to be taken into account that the value of mode := 2 (see also section K.2.3.2.4 CM_AddNode(): Setting up the node list). When the CANopen-node is set up, the guarding can be started with CM_StartStopGuarding(x,2). In a CANopen-slave-configuration the guarding is effected by calling the function CM_GetNodeState(), in a CANopen-manager-configuration it is also possible to use additionally the function CM_Guarding(). Functions CM_GetNodeState() CM_Guarding()

Manager x x

Slave X Not usable

Table K.23 HB-consumer-functions in digsy®compact / digsy®CGM Reaction in the case of a guarding error in digsy®compact E or digsy®CGM: A failure becomes visible by a change of the node state of the heartbeat-producer to be guarded to the state 1(INIT) by means of the function CM_GetNodeState(). In a CANopen-manager-configuration a failure can be noticed with the function CM_Guarding() too, since the node number of the affected heartbeat-producer is mapped in it as a return value. Example of an evaluation:

04 - 68 280 000/A Version 1.0.0

Page K-97

K Communication via CANopen

Manual digsy®

Figure K.46 Guarding evaluation when using the heartbeat-consumer

ATTENTION:

04 - 68 280 000/A Version 1.0.0

In the CANopen-Manager, after a guarding error, the guarding mechanism has to be restarted with CM_StartStopGuarding(). In the slave-node this is not necessary.

Page K-98

K Communication via CANopen

Manual digsy®

K.8 Error Handling K.8.1 Introduction CANopen-devices generate so-called „Emergency-messages“ by means of which error events or messages are signalized. The emergency-message is specified in DS301 V4.01. It has the following identifier with which it is output on the CAN-bus: Identifier:

16#80 + node number

The message has a length of 8 bytes and looks as follows: Byte Contents

0 1 Emergency Error Code (see table)

2 Error Register (Object 16#1001)

3

4 5 6 Manufacture Specific Error Field

7

Table K.24 Data contents of the emergency-object For the Emergency Error Code in CANopen the following classification applies to the „MostSignificant-Byte“ of this code word: Error Code (hexadecimal) 00xx 10xx 20xx 21xx 22xx 23xx 30xx 31xx 32xx 33xx 40xx 41xx 42xx 50xx 60xx 61xx 62xx 63xx 70xx 80xx 81xx 8110 8120 8130 8140 82xx 8210 8220

04 - 68 280 000/A Version 1.0.0

Meaning Error Reset or No error Generic error Current Current, device input side Current, input current Current, device output side Voltage Principal voltage Input voltage Output voltage Temperature Ambient temperature Device temperature Hardware of the device Software of the device Firmware Application program Data set Additional modules Monitoring Communication CAN Overrun (loss of CAN-messages) CAN in Error passive mode Life guard or Heartbeat error Recovered from bus off Protocol error PDO not accepted due to data length error PDO-data length exceeded

Page K-99

K Communication via CANopen

Error Code (hexadecimal) 90xx F0xx FFxx

Manual digsy® Meaning

External error Additional functions Device-specific

Table K.25 Emergency Error Codes

K.8.2 Functionalities regarding digsy®compact E / digsy®CGM

the

emergency-objects

in

digsy®compact and digsy®CGM feature an integrated error mechanism which can also be used via the application program. In this connection, there are 2 possibilities: • •

Reading of an error/a message (emergencies) and entry in the own error memory Generation of errors/messages from the application program

K.8.2.1 Basic user-functions regarding the error memory K.8.2.1.1

GetNextError(): Inquiring the error memory

With this function the internal error memory can be read out. Only one error or message is read out at a time. In this connection, the FIFO-principle (first in, first out) applies, which ensures that no entry gets lost. Function block: 1131-Library: Application:

GetNextError Dcompact50x.lib, CGM01_10x.lib; Prosyd.lib in CANopen-manager or in CANopen-slave

GetNextError Code Location Channel Para1 Para2

Function output Code

Data type WORD

Location Channel Para1 Para2

WORD DWORD WORD WORD

04 - 68 280 000/A Version 1.0.0

Description Error code acc. to „Emergency Error Code“classification Error location Channel number or address Additional parameter 1 Additional parameter 2

Page K-100

K Communication via CANopen

K.8.2.1.2

GetNextErrorTS():

Manual digsy®

Inquiring the error memory with time

indication This function block is an extension of the function block GetNextError(). In addition, the point of time of the occurred error or of the occurred message is output, too. Function block: 1131-Library: Application:

GetNextErrorTS Dcompact50x.lib, CGM01_10x.lib; Prosyd.lib in CANopen-manager or in CANopen-slave

GetNextErrorTS Code Location Channel Para1 Para2

timestamp

Function output Code

Data type WORD

Location Channel Para1 Para2 timestamp

WORD DWORD WORD WORD DWORD

Description Error code acc. to „Emergency Error Code“classification Error location Channel number or address Additional parameter 1 Additional parameter 2 Point of time, i.e., here, the time of the system timer is filed

Example: see Chapter K.8.2.2 „Reading-out an emergency message“

K.8.2.1.3

SetNextError(): Generating an error / a message

In this function block an error or a message is generated from the application program. This generated message/error is exactly treated like an error generated by the digsy®compact and the digsy®CGM itself, i.e., it is entered in the internal error memory and, if necessary, output via the CAN-bus. Function block: 1131-Library: Application:

04 - 68 280 000/A Version 1.0.0

SetNextError Dcompact50x.lib, CGM01_10x.lib; Prosyd.lib; Prosyd42.lib in CANopen-manager or in CANopen-slave

Page K-101

K Communication via CANopen

Manual digsy®

SetNextError Code Location Channel Para1 Para2

Function input Code

Data type WORD

Location Channel Para1 Para2

WORD DWORD WORD WORD

Description Error code acc. to „Emergency Error Code“classification (see note) Error location Channel number or address Additional parameter 1 Additional parameter 2

Example: see Chapter K.8.2.3 „Generating emergency messages“

K.8.2.1.4

Emergency-variables in data structures or of the adjustable control configuration

With the variable en_emergency it is possible for the user to output only certain emergencymessages via the CAN-bus. For this, a mask is placed over the function input or output Code. This is documented in the Chapter K.2.5 „CAN-variables in data structures or in the control configuration“. Note: There is no difference between an error/a message generated by the system itself and an error/a message generated by the user. The following classification is applicable: Number 0 16#01 16#02 16#04 16#08 16#10 16#1F

Symbolic name NO_ERROR WARNING USER_ERROR APP_ERROR SYS_ERROR -

Meaning No message output Output of messages Output of warnings Output of user error Output of application error Output of system error Output of all errors/messages (logic OR-operation of the numbers of this table)

Table K.26 Allocation of en_emergency

04 - 68 280 000/A Version 1.0.0

Page K-102

K Communication via CANopen

Manual digsy®

K.8.2.2 Reading-out an emergency message The function blocks SetNextError() and SetNextErrorTS() described above are used in order to provide the contents of the internal error memory to the user.

ATTENTION:

Since the internal error memory is a ring buffer, the internal error memory has to be prevented from overflowing by regularly reading out the entries.

Appearance of an error memory entry: The variables Code and Location belonging to the error memory entry define the main selection criteria for the classification of an entry: Code: Here, a code according to the classification of Table K.25 is deposited. For a detailed description of all possible entries/codes and their respective meanings please refer to the „Manual digsy®CGM“ or the „Manual digsy®CGM“. Location: This WORD-variable is divided up into 2 bytes which include the following classifications: • MSB: Classifying the significance according to Table K.26 • LSB: Area where the error / message occurred: Area designation ERR_LOCAT_OS ERR_LOCAT_1131_LZS ERR_LOCAT_DIGIN ERR_LOCAT_DIGOUT ERR_LOCAT_ANIN ERR_LOCAT_PWM ERR_LOCAT_ COUNTER ERR_LOCAT_ FLASH ERR_LOCAT_ RETAIN ERR_LOCAT_ MEASURE ERR_LOCAT_ HARDWARE ERR_LOCAT_ CANOPEN

Area Operating system 1131-Runtime system (firmware area) Digital inputs Digital outputs Analog inputs PWM-outputs Counter Flash-ROM Retain data Measurement inputs Hardware CANopen

Value 1 2 16#10 16#11 16#12 16#13 16#14 16#15 16#16 16#17 16#18 16#19

Table K.27 Locations in DIGSYcompact Example: Location := Meaning:

ATTENTION:

04 - 68 280 000/A Version 1.0.0

16#0212; 16#02xx -> a warning is output 16#xx12 -> the message was generated in the area of the analog inputs As a CANopen-Slave the MSB of the variable Location is changed in a transmission via the CAN-bus: MSB: - 16#80 (external error)

Page K-103

K Communication via CANopen

Manual digsy®

In the case of an implementation as a CANopen-manager the messages or error messages of the individual slaves can thus be unambiguously received and are available for the user. In the variable Channel the node number of the transmitting node is deposited in the „Most-Significant-Word“. Example: The figure shows the basic sequence for a read-in of the internal error memory in the user error memory ErrorHist:

Figure K.47 Sequence for reading-in the error memory

K.8.2.3 Generating emergency messages Via the function block SetNextError() it is possible to generate your own messages or error messages. In this connection, the nomenclature of the error coding should correspond with that of the digsy®compact and digsy®CGM, in order to avoid a non-ambiguity of the message. This applies particularly to the variables Code and the MSB of Location. For user-specifically generated messages/errors the following areas are available for the input variable Code:

04 - 68 280 000/A Version 1.0.0

Page K-104

K Communication via CANopen

Error Code –> Code 16#0000..16#0FFF 16#6200..16#62FF 16#FF00..16#FFFF

Manual digsy®

Comments None Partly occupied, please refer to the Chapter Error Coding in the „ digsy®compact“ or „digsy®CGM“ manual None

Table K.28 Usable Error Codes for the user

Example: With every thousandth call a message will be generated which is entered in the internal error memory and possibly (occupation of en_emergency) transmitted via the CAN-bus:

Figure K.48 Example of generating an error message

04 - 68 280 000/A Version 1.0.0

Page K-105

K Communication via CANopen

Manual digsy®

K.9 Example Project K.9.1 Task definition The following example shows how to set up a CANopen-network with 2 digsy®compact E-control units and a digsy®CGM. The following constellation applies: • • • • •

The network will be operated with a baud rate of 250 kBauds. Node number of the manager: 2 (in this case a digsy®compact E) Node numbers of the slaves: 3 (in this case a digsy®compact E) and 5 (in this case a digsy®CGM) The NMT guarding mechanism is heartbeat, and in this connection both the manager and the slave are consumer and producer for all nodes in the network The following PDOs are to be transmitted or received:

COB-ID TxPDO1

16#182

TxPDO2

16#282

TxPDO3

16#382

TxPDO4

16#482

RxPDO1

16#183

RxPDO2

16#283

RxPDO3

16#185

RxPDO4

16#282

Node 2 Mapping 4 WORD to %MB0..7 4 BYTE 1 DWORD to %MB8..15 2 BYTE to %MB16..17 2 REAL to %MB24..31 1 DWORD to %MB1024..1027 8 BYTE to %MB1032..1039 3 WORD to %MB1040..1045 1 BYTE to %MB1048

COB-ID 16#183

Node 3 Mapping

COB-ID

Node 5 Mapping

1 DWORD to %MB0..3 8 BYTE to %MB8..15

16#185

Inactive

Default

Inactive

Default

Inactive

Default

Inactive

Default

16#182

4 WORD to %MB1024..1027 4 BYTE 1 DWORD to %MB1032..1039 2 BYTE to %MB1040..1041 1 BYTE to %MB1048

16#283

8 BYTE to %MB1024..1031 4 BYTE 1 DWORD to %MB1032..1039 2 REAL to %MB1040..1047 Default

16#283

16#282 16#382 16#285

16#285

16#282 16#482 Inactive

3 WORD to %MB0..5 1 BYTE to %MB8

Table K.29 PDO-setup in the example network • • •

•

Via a user-SDO a data field of a size of 200 bytes is to be transmitted from the manager to the slave 3 and read out from it, too. The CANopen-network always starts with node 2 and node 3. Node 5, as soon as it is available, will be set up for the network without any effects on the remaining network. Reaction in the case of a node failure: Failure of node 3: During the failure of this node, the entire network is set to PREOPERATIONAL; the network will be newly set up and started as soon as this node is again available in the network. Failure of node 5: The node will be newly set up and started as soon as this node is again available in the network. Entries in the error memory are to be evaluated and both in the CAN-manager and in a slave an own message shall be generated.

04 - 68 280 000/A Version 1.0.0

Page K-106

K Communication via CANopen

Manual digsy®

K.9.2 Implementation of the CANopen-slave-nodes The configuration of the slaves is very easy. The following points have to be set up: a.) CAN-initialization b.) Determining the PDO-memory areas according to configuration c.) Setting up the guarding mechanism

K.9.2.1 CAN-Initialization It is necessary to set up the requirements for the CANopen-nodes called for in Chapter K.9.1 Task definition. For this purpose, the initialization is to be carried out in the IEC1131-program CAN_Init() once: -

Setup of possibly required additional COB-identifiers or those to be changed and their meaning with COBADD(). CANopen-initialization as a slave-node with CM_Init(), in this connection, the heartbeatproducer is started with the initialization. Setup of the heartbeat-consumer-values for the guarding of the other nodes with CM_AddNode()

The following figure shows the appropriate initialization steps for slave-node 3:

04 - 68 280 000/A Version 1.0.0

Page K-107

K Communication via CANopen

Manual digsy®

Figure K.49 Initialization of CANopen-slave-node 3

K.9.2.2 PDO-Setup In the slave-node, the memory areas used for the PDOs have to be defined in the flag area. In this connection, the memory positions defined in Chapter K.9.1 Task definition are applicable which are set up in the slave-node by the CANopen-manager during the runup. The following figure shows the memory allocation for the PDOs in slave-node 5:

04 - 68 280 000/A Version 1.0.0

Page K-108

K Communication via CANopen

Manual digsy®

Figure K.50 Memory allocation of the PDOs in slave-node 5

K.9.2.3 Guarding mechanism In the slave-node the guarding is implemented by means of the heartbeat-consumer. The guarding is effected in every AWP(application program)-cycle in the 1131-program P_Guarding(). As soon as the slave-node has been set to OPERATIONAL, the guarding will be started. The slave-node can now receive the node states of the nodes to be guarded and thus, if necessary, react to changes in their states:

Figure K.51 Excerpt from the guarding routine in slave-node 3

04 - 68 280 000/A Version 1.0.0

Page K-109

K Communication via CANopen

Manual digsy®

K.9.2.4 SDO-transfer The communication object where the data field is to be transferred to is to be set up in slavenode 3. This is to be done with COBADD() prior to the initialization:

Figure K.52 Setting up the communication object for the data field

K.9.2.5 Error evaluation in slave-node implementations As compared with a CANopen-manager-implementation the only difference here is that slavenodes do not receive the emergency-messages of other nodes. In this case too, a further specification of the individual errors or messages can be effected. This has the advantage that it is possible to accept only the important messages, whereas the less important ones are rejected, since in the internal error memory all errors or messages are stored. The following figure shows the sequence for storing the „real“ errors in the user error memory:

Figure K.53 Filtering the errors of the internal error memory

04 - 68 280 000/A Version 1.0.0

Page K-110

K Communication via CANopen

Manual digsy®

K.9.3 Implementation of the CANopen-manager Basically, the configuration of the CANopen-managers does not differ from that of a slave-node. In this case too, the following points have to be set up: a.) CAN-initialization b.) Determining the PDO-memory areas according to configuration c.) Setting up the guarding mechanism The CANopen-manager-characteristics have to be implemented as well: d.) Runup sequencer for setting up the network e.) Network management Here, in addition, the f.) SDO-Transfer is set up, too.

K.9.3.1 CAN-Initialization It is necessary to set up the requirements for the CANopen-manager which are called for in the Chapter K.9.1 Task definition. For this purpose, the initialization in the IEC1131-function F_Init_CAN() is to be carried out once: -

Setup of possibly required additional COB-identifiers or those to be changed and their meaning with COBADD() CANopen-initialization as a manager with CM_Init(), in this connection, the heartbeat-producer is started with the initialization Initializing the runup sequencer

The following figure shows the appropriate initialization steps for the manager:

Figure K.54 Initialization of the CANopen-manager node 2

04 - 68 280 000/A Version 1.0.0

Page K-111

K Communication via CANopen

Manual digsy®

K.9.3.2 PDO-Setup In this case too, the memory areas used for the PDOs have to be defined in the flag area. In this connection, the memory positions defined in Chapter K.9.1 Task definition apply, which the CANopen-manager sets up in itself during the runup: The following figure illustrates the memory utilization for the PDOs in the CANopen-manager:

Figure K.55 Memory allocation of the PDOs in the manager

K.9.3.3 Guarding mechanism The implementation of the guarding mechanism is a bit more complicated than in the case of the slave-nodes. It is effected in the 1131-program P_Guarding(). According to the task definition in Chapter K.9.1 the two slave-nodes are to be differently treated with regard to their guarding reaction. In this connection, the network situations indicated in the following figure can result: active

Node 2 CAN-manager

active

Node 3 Slave:

active inactive

active

Node 5 Slave: inactive Point of time:

1

inactive 2

3

3a 4

Figure K.56 Time representation of the network states

04 - 68 280 000/A Version 1.0.0

active

Page K-112

5 5a

6

K Communication via CANopen

Manual digsy®

The following table gives a description of the network states and indicates the reaction of the CANopen-manager-node 2 at the individual points of time: Point of time 1

2

3

3a

4

5

5a

6

Node states

Reaction

Node 2: active (node state change to > 1 The CAN-manager-node 2 is connected to (INIT)) the network and configures node 3 which is Node 3: active (node state > 1 (INIT)) active, too. Afterwards, both nodes are in the Node 5: inactive (node state = 1 (INIT)) network, i.e., in the node state OPERATIONAL Node 2: active (node state > 1 (INIT)) Node 5 sends its bootup-message and the Node 3: active (node state > 1 (INIT)) first heartbeat. Thus, it will be recognized by Node 5: inactive (node state change to > 1 the node 2 as being active and configured (INIT)) and then it is in the status OPERATIONAL in the network, too. Node 2: active (node state > 1 (INIT)) Node 3 becomes inactive (state change from Node 3: active (node state change to 1 greater than 1 to 1). (INIT)) Node 5: inactive (node state > 1 (INIT)) Node 2: active (node state > 1 (INIT)) Node 2 has recognized that and the function Node 3: active (node state = 1 (INIT)) CM_Guarding() signals a failure of the node. Node 5: inactive (node state > 1 (INIT)) The entire network is now set to PREOPERATIONAL. Node 2: active (node state > 1 (INIT)) Node 3 is active again. The manager node 2 Node 3: active (node state change to > 1 recognizes that, configures the entire network (INIT)) anew and sets then the entire network to Node 5: inactive (node state > 1 (INIT)) OPERATIONAL. Node 2: active (node state > 1 (INIT)) Node 5 becomes inactive (state change from Node 3: active (node state > 1 (INIT)) greater than 1 to 1). Node 5: inactive (node state change to 1 (INIT)) Node 2: active (node state > 1 (INIT)) Node 2 has recognized that and the function Node 3: active (node state > 1 (INIT)) CM_Guarding() signals a failure of the node. Node 5: inactive (node state = 1 (INIT)) The guarding of the node is restarted with CM_StartStopGuarding(), in order to recognize when it becomes active in the network again. Node 2: active (node state > 1 (INIT)) Node 5 is active again. The manager node 2 Node 3: active (node state > 1 (INIT)) recognizes that, configures the node 5 anew Node 5: inactive (node state change to > 1 and sets then the node to OPERATIONAL. (INIT)) Table K.30 Description of the time states acc. to Figure K.56

In this example, the 1131-program P_Guarding() is called every AWP(application program)-cycle. The implemented program sequence looks as follows:

04 - 68 280 000/A Version 1.0.0

Page K-113

K Communication via CANopen

Manual digsy®

Figure K.57 Program flow of the guarding in CANopen-manager-node 2 It is visible that, in the evaluation of the guarding, the runup of the network is called as a functionality to be executed.

04 - 68 280 000/A Version 1.0.0

Page K-114

K Communication via CANopen

Manual digsy®

K.9.3.4 Runup sequencer for setting up the network In this program, there are the following sequences as regards the runup sequencer for setting up this CANopen-network: 1. 2.

Network runup, in the case of which the node 3 is set up and in which the setup of node 5 is only optionally effected (if it is available in the network). Runup sequencer for setting up node 5 as soon as it has been recognized as being existent or active in the network.

K.9.3.4.1

Setting up node 3, optionally node 5

The setup of the network is carried out according to the process described in Chapter K.5 „Sequencer for setting up a CANopen-network with digsy®compact -/ digsy®CGM “. After successfully initializing node 2 as a manager, the runup sequencer in the 1131-program CAN_Manager() is called. In the first step STEP_INIT the relevant nodes in it are set up in the 1131-funktion F_Step1_Init() with the function CM_AddNode(). After the node guarding has been started in the next step STEP_STARTGUARD, a period of time at least as long as the longest heartbeat-producer-time of the relevant nodes has to be waited out until it is checked whether or not the nodes are existent in the network. In step STEP_WAITPREOP it is checked, whether the relevant nodes are available in the network. The optional node 5 will only be taken into account in the further course of the sequencer, if it is available in the network with a node state of >1(INIT). In the next step STEP_INIT_DCF the actual setup of the node(s) is effected. In it, the lists, in which the „Expedited SDOs“ saved in the format CDCF are stored, are transmitted to the relevant nodes. The list belonging to node 3 includes the following program parts: • In Global_Variables in CANList_N3, in which the defined list Node_03_DCF of the type TConDCF is declared • In the folder initNodes the function F_Init_Node3(), in which this list with the applicable values is initialized When this transfer is successfully completed, the network will be set to PREPARED. In this network state neither an SDO nor a PDO transfer is possible. This network state will be evaluated in the following step STEP_PREOP. In this case it is necessary too that a defined period of time has to be waited out which is at least as long as the longest heartbeat-producer-time of the relevant nodes. If the network is set to PREPARED, the network can be started in the next step STEP_PREPARED by setting it to the OPERATIONAL state. From now on an exchange of the process data can be effected. If an error occurs in one of the steps of the runup sequencer, the step STEP_ERROR, within which the complete network will be started or setup anew, will be immediately activated. The following figure shows the sequence of the individual steps:

04 - 68 280 000/A Version 1.0.0

Page K-115

K Communication via CANopen

Manual digsy®

Figure K.58 Complete sequencer of the CANopen-manager

K.9.3.4.2

Individual setup of the node 5

Since the setup of node 5 is not to have an influence on the remaining network, the setup of this node does not cause a state change in the network. If the node in the network is recognized as being active (see point of time 2 in Chapter K.9.3.3 Guarding mechanism), in the 1131-program STEP_N5_INITDCF the CDCF-list Node_05_DCF will be transferred to this node via SDO. After successfully carrying out this step, the node 5 will be set to PREPARED and after waiting out a defined period of time, which is at a least as long as the longest heartbeat-producer-time of node 5, the step STEP_N5_PREPARED will be called. Within it, it is checked whether the node 5 has taken this state PREPARED, and if yes, the node 5 will be set to OPERATIONAL. From now on, an exchange of process data with this node is possible.

04 - 68 280 000/A Version 1.0.0

Page K-116

K Communication via CANopen

Manual digsy®

K.9.3.5 Network management One of the CANopen-manager's most important characteristics is the network management. Only the CANopen-manager may change the node states in a CANopen-network. This is done with the function CM_SetNodeState(). If a node state change is effected without the CANopen-manager initiating it, a guarding error will result as a reaction. This reaction is detectable via the function CM_Guarding().

K.9.3.6 Error evaluation in the CANopen-manager-implementation In the folder ErrorHandling the functionalities belonging to the error memory are implemented. In the CANopen-manager all messages of the individual nodes are entered in the program ErrorTraceRoutine() and a case distinction is made as to from which node this entry has come:

04 - 68 280 000/A Version 1.0.0

Page K-117

K Communication via CANopen

Manual digsy®

Figure K.59 Program ErrorTraceRoutine() Afterwards, the individual errors or messages can be further specified. Slave-nodeimplementations transmit only those emergency messages via the CAN-bus which are released for this in their application program (Variable en_emergency). Consequently, the CANopen-manager can receive only these emergency messages. In the example implemented here, all the errors or messages are sent via the CAN-bus.

04 - 68 280 000/A Version 1.0.0

Page K-118

K Communication via CANopen

Manual digsy®

In the evaluation routine for the own node Error_N2() all errors are additionally stored in an own error memory.

04 - 68 280 000/A Version 1.0.0

Page K-119

K Communication via CANopen

Manual digsy®

K.10 Technical Data and Important Additions K.10.1 Technical data a.) NMT: Master, Slave b.) Node-ID: max. 32 CANopen-nodes possible, node numbers freely selectable from 1 to 32 PDO: c.) A maximum of 64 TxPDOs and 64 RxPDOs each can be set up d.) PDO-mode: time-triggered e.) PDO linking and variables mapping SDO: f.) 40 SDO-clients g.) 4 SDO-servers Guarding mechanism: h.) Nodeguarding i.) Heartbeat (producer and consumer) Error handling: j.) Output of emergency messages CANopen-version: Device profile:

DS301-V4.01 DSP405-V1.0

K.10.2 Storage processes in FLASH-memory in the case of digsy®compact E/ digsy®CGM The storage of the retain data requires between t≈0.03s and t≈10 seconds. During this period of time a data transfer cannot take place. For this reason, the storing of data has to be requested from the CANopen-manager. Then, the inquiring node can, for a certain period of time, be set to a state (e.g., PREOPERATIONAL or better PREPARED) in which it cannot lose any data or in which data can be purposefully transmitted anew. This has to be absolutely taken into account in an application!

04 - 68 280 000/A Version 1.0.0

Page K-120

K Communication via CANopen

Manual digsy®

K.11 Appendix K.11.1 List of illustrations: Figure K.1 Schematic device connection on the CAN-bus .............................................................K-5 Figure K.2 Structure of a CAN-message.........................................................................................K-6 Figure K.3 NMT-states ....................................................................................................................K-9 Figure K.4 Nodeguard principle.....................................................................................................K-10 Figure K.5 Heartbeat principle.......................................................................................................K-11 Figure K.6 Storage allocation of the flag area in the IEC 1131.....................................................K-36 Figure K.7 Use of CM_INIT().........................................................................................................K-41 Figure K.8 Use of COPINIT() ........................................................................................................K-42 Figure K.9 Use of COBADD()........................................................................................................K-44 Figure K.10 Use of CM_AddNode() ..............................................................................................K-46 Figure K.11 Use of CM_Reset() ....................................................................................................K-47 Figure K.12 Use of CM_SetNodeState().......................................................................................K-49 Figure K.13 Use of CM_GetNodeState() ......................................................................................K-51 Figure K.14 Use of CM_StartStopGuarding() ...............................................................................K-52 Figure K.15 Use of CM_Guarding()...............................................................................................K-54 Figure K.16 Use of SDOADD()......................................................................................................K-56 Figure K.17 Use of CM_SDO_RW()..............................................................................................K-58 Figure K.18 Handling of the function block CM_DCFTrans()........................................................K-62 Figure K.19 Handling of CM_PDO_Sync()....................................................................................K-63 Figure K.20 Format for segmented SDO-write or SDO-read operations ......................................K-70 Figure K.21 Initiate SDO-download...............................................................................................K-70 Figure K.22 Changing the heartbeat-producer-time via SDO-transfer for node 13 ......................K-72 Figure K.23 Example regarding CM_DCFTrans().........................................................................K-74 Figure K.24 CANanalyzer-output ..................................................................................................K-74 Figure K.25 Principle of data exchange via PDO..........................................................................K-76 Figure K.26 Principle of data exchange via PDOs in the case of digsy®compact / digsy®CGM ............K-76 Figure K.27 Structure of a mapping-entry .....................................................................................K-77 Figure K.28 CANanalyzer-output ..................................................................................................K-78 Figure K.29 CDCF-list of the example ..........................................................................................K-78 Figure K.30 Setting up the COB-identifiers of 16 TxPDOs ...........................................................K-79 Figure K.31 Memory allocation of the flag area in the IEC 1131 ..................................................K-80 Figure K.32 Structure of an object-mapping-entry for digsy®CGM and digsy®compact E .....................K-82 Figure K.33 Contents of the example-TxPDO...............................................................................K-83 Figure K.34 Mapping data of the example-PDO in Prosyd 1131 ..................................................K-83 Figure K.35 Structure of an object-mapping-entry for digsycompact............................................K-84 Figure K.36 Setting up the communication objects in the DcP-Slave...........................................K-84 Figure K.37 Mapping list of these communication objects in the CANopen-manager..................K-85 Figure K.38 Structure of an object-mapping-entry for the CGC....................................................K-86 Figure K.39 Use of index and subindex in the CGC .....................................................................K-87 Figure K.40 Example of a COB-ID and mapping list for the CGC ................................................K-88 Figure K.41 Structure of an object-mapping-entry ........................................................................K-89 Figure K.42 Setting up the communication objects in CANopen-nodes acc. to DS301 V4.01.....K-89 Figure K.43 Graphical representation of the runup according to the time aspect.........................K-92 Figure K.44 Swapping the „Low-16Bit“ and the „High-16Bit“ of REAL-values..............................K-94 Figure K.45 Setting the heartbeat-producer-time in the case of digsy®compact E/ digsy®CGM ............K-97 Figure K.46 Guarding evaluation when using the heartbeat-consumer........................................K-98 Figure K.47 Sequence for reading-in the error memory .............................................................K-104 Figure K.48 Example of generating an error message ...............................................................K-105 Figure K.49 Initialization of CANopen-slave-node 3 ...................................................................K-108 Figure K.50 Memory allocation of the PDOs in slave-node 5 .....................................................K-109

04 - 68 280 000/A Version 1.0.0

Page K-121

K Communication via CANopen

Manual digsy®

Figure K.51 Excerpt from the guarding routine in slave-node 3..................................................K-109 Figure K.52 Setting up the communication object for the data field............................................K-110 Figure K.53 Filtering the errors of the internal error memory......................................................K-110 Figure K.54 Initialization of the CANopen-manager node 2........................................................K-111 Figure K.55 Memory allocation of the PDOs in the manager......................................................K-112 Figure K.56 Time representation of the network states ..............................................................K-112 Figure K.57 Program flow of the guarding in CANopen-manager-node 2 ..................................K-114 Figure K.58 Complete sequencer of the CANopen-manager .....................................................K-116 Figure K.59 Program ErrorTraceRoutine()..................................................................................K-118

04 - 68 280 000/A Version 1.0.0

Page K-122

K Communication via CANopen

Manual digsy®

K.11.2 List of tables: Table K.1 Communication types in the case of CANopen ..............................................................K-8 Table K.2 Network states and how they differ.................................................................................K-8 Table K.3 Memory allocation of the flag area in the IEC 1131......................................................K-23 Table K.4 Index and Subindex allocation for the TxPDOs............................................................K-23 Table K.5 Index and Subindex allocation for the RxPDOs ...........................................................K-24 Table K.6 Index and Subindex allocation for the TxPDOs............................................................K-36 Table K.7 Index and Subindex allocation for the RxPDOs ...........................................................K-37 Table K.8 Default-PDOs in the case of digsy®compact E / digsy®CGM .................................................K-38 Table K.9 Objects of the object directory belonging to CM_AddNode() .......................................K-46 Table K.10 Functionality in manager and in slave ........................................................................K-50 Table K.11 Possibility of distributing unassigned SDO-server-IDs ...............................................K-56 Table K.12 Error codes .................................................................................................................K-65 Table K.13 Overview of the functions / function blocks regarding the application........................K-68 Table K.14 Identical SDO-transfer with CM_SDO_RW() and CM_DCFTrans() ...........................K-73 Table K.15 Meaning of the relevant indices in the object directory...............................................K-75 Table K.16 Default-COB-Ids in digsy®CGM and digsy®compact E ........................................................K-79 Table K.17 Index and subindex allocation for the TxPDOs ..........................................................K-81 Table K.18 Index and subindex allocation for the RxPDOs ..........................................................K-81 Table K.19 Default mapping in digsy®CGM and digsy®compact E ........................................................K-82 Table K.20 Use of the functions and FBs depending on the „State“ in the CANopen-network ....K-91 Table K.21 Time dependencies.....................................................................................................K-92 Table K.22 Bootup-recognition in digsy®compact / digsy®CGM .............................................................K-95 Table K.23 HB-consumer-functions in digsy®compact / digsy®CGM .....................................................K-97 Table K.24 Data contents of the emergency-object ......................................................................K-99 Table K.25 Emergency Error Codes ...........................................................................................K-100 Table K.26 Allocation of en_emergency .....................................................................................K-102 Table K.27 Locations in DIGSYcompact.....................................................................................K-103 Table K.28 Usable Error Codes for the user ...............................................................................K-105 Table K.29 PDO-setup in the example network ..........................................................................K-106 Table K.30 Description of the time states acc. to Figure K.56 ....................................................K-113

04 - 68 280 000/A Version 1.0.0

Page K-123

K Communication via CANopen

Manual digsy®

K.11.3 Bibliography Etschberger, Konrad: Controller-Area-Network Munich/Vienna: Hanser-Verlag, 2000 Farsi, Mohammed; Bernardo, Manuel; Barbosa, Martin: CANopen Implementations - applications to industrial network Baldock(UK): Reseach Studies Press, 2000 Zeltwanger, Holger: CANopen Berlin: VDE-Verlag, 2001 CiA (CAN in Automation e.V.): CANopen Applications Layer and Communications Profile DS 301 V4.01 CiA (CAN in Automation e.V.): Device Profile for IEC1131 Programmable Devices DSP 405 V2.0 INTER CONTROL: Manual digsycompact Nuremberg: 04-68255 INTER CONTROL: Manual digsyCGM Nuremberg: 04-68253

04 - 68 280 000/A Version 1.0.0

Page K-124

K Communication via CANopen

K.12 Notes

04 - 68 280 000/A Version 1.0.0

Page K-125

Manual digsy®

K Communication via CANopen

04 - 68 280 000/A Version 1.0.0

Page K-126

Manual digsy®

K Communication via CANopen

04 - 68 280 000/A Version 1.0.0

Page K-127

Manual digsy®

K Communication via CANopen

04 - 68 280 000/A Version 1.0.0

Page K-128

Manual digsy®