Application note

CM CANopen
Description of the CANopen demo
HMS Technology Center Ravensburg GmbH
Helmut-Vetter-Straße 2
88213 Ravensburg
Germany

Tel.: +49 751 56146-0

Fax: +49 751 56146-29
Internet: www.hms-networks.de
E-Mail: info-ravensburg@hms-networks.de

Support
In case of unsolvable problems with this product or other HMS products
please contact HMS in written form:

Fax: +49 751 56146-29

E-Mail: support@ixxat.de

Further international support contacts can be found on our webpage

www.hms-networks.de

Copyright
Duplication (copying, printing, microfilm or other forms) and the electronic
distribution of this document is only allowed with explicit permission of HMS
Technology Center Ravensburg GmbH. HMS Technology Center
Ravensburg GmbH reserves the right to change technical data without
prior announcement. The general business conditions and the regulations
of the license agreement do apply. All rights are reserved.

Registered trademarks
All trademarks mentioned in this document and where applicable third
party registered are absolutely subject to the conditions of each valid label
right and the rights of particular registered proprietor. The absence of
identification of a trademark does not automatically mean that it is not
protected by trademark law.

Document number: X.XX.XXXX.XXXXX

Version: 1.0
 Content

1 Introduction .................................................................................... 7
1.1 Restrictions ............................................................................. 8
1.2 Related Documents ................................................................ 8
2 Hardware identifier of the CM module .......................................... 9
2.1 TIA Portal V11 / V12 ................................................................ 9
2.2 TIA Portal V13........................................................................ 10
2.3 TIA Portal V14........................................................................ 12
2.4 TIA Portal V15........................................................................ 14
3 Overview of the CANopen demo ................................................. 15
4 Exchange of process image data ............................................... 16
4.1 General hints ......................................................................... 16
4.2 Get Process Data In .............................................................. 18
4.2.1 Layout of the Process Image ................................................. 19
4.2.2 Hardware Configuration of the CM module in TIA Portal ....... 22
4.2.3 Description of the used structure ........................................... 22
4.2.4 Upload and update of the process image input data ............. 23
4.2.4.1 ProcessImageData [DB14] ....................................... 23
4.2.4.2 GetProcessDataIn [FC1] .......................................... 24
4.2.4.3 UpdatePIInData_PLC [FC2] ..................................... 25
4.2.5 Adaption of the demo to the user`s application...................... 25
4.3 Set Process Data Out ........................................................... 26
4.3.1 Layout of the Process Image ................................................. 27
4.3.2 Hardware Configuration of the CM module in TIA Portal ....... 29
4.3.3 Description of the used structure ........................................... 30
4.3.4 Download of the process image output data .......................... 30
4.3.4.1 ProcessImageData [DB14] ....................................... 31
4.3.4.2 SetProcessDataOut [FC3] ........................................ 31
4.3.4.3 UpdatePIOutData_CM [FC4] ................................... 33
4.3.5 Adaption of the demo to the user`s application...................... 33
5 SDO commands ........................................................................... 34
5.1 General hint ........................................................................... 34
5.1.1 Processing of a SDO command ............................................. 34
5.1.2 Data format ............................................................................ 35
5.1.3 Parallel processed SDO commands ...................................... 38
5.1.4 Application note “CANopen manager” mode ......................... 39
Copyright HMS Technology Center 3 CM CANopen, CANopen Application, V1.0
Ravensburg GmbH
 Content

5.1.5 Restrictions “CANopen slave” mode ...................................... 40

5.2 SDO Demo ............................................................................. 42
5.3 SDO Read .............................................................................. 42
5.3.1 Description of ReadSDO [FB104] .......................................... 43
5.3.2 Structure: "Ctrl_CM_CANopen".ReadSDO ............................ 45
5.3.3 SDORead_Request [FC6]...................................................... 46
5.3.4 SDORead_InterpretReadData [FC7] ..................................... 47
5.4 SDO Write .............................................................................. 48
5.4.1 Description of WriteSDO [FB105] .......................................... 49
5.4.2 Structure: "Ctrl_CM_CANopen".WriteSDO ............................ 51
5.4.3 SDOWrite_Request [FC5] ...................................................... 52
5.4.4 SDOWrite_InterpretResult [FC8] ........................................... 53
6 Get Node & Network Status ........................................................ 54
6.1.1 Structure: "Ctrl_CM_CANopen".GetNNStatus ....................... 54
6.1.2 GetNodeNetworkStatus [FC18] ............................................. 55
6.1.3 AnalyseNodeNetworkStatus [FC14] ...................................... 56
6.1.4 Discussion of the diagnostic information ................................ 57
6.1.4.1 General hints ............................................................ 57
6.1.4.2 Get Node & Network Status: Message error ............ 62
6.1.4.3 Get Node & Network Status: CANopen Module
mode 63
6.1.4.4 Get Node & Network Status: Error flags (module) ... 63
6.1.4.5 Get Node & Network Status: Error flags (network) .. 65
6.1.4.6 Get Node & Network Status: CANopen Node
Status 68
6.1.4.7 Get Node & Network Status: Network status ........... 69
7 CM CANopen Configuration Studio ............................................ 73
7.1 Exchange of process image data ........................................ 73
7.2 “Device Parameters” tool window ....................................... 75
8 Status LEDs.................................................................................. 77
8.1 Indicator states and flash rates ........................................... 78

Copyright HMS Technology Center 4 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Content

Copyright HMS Technology Center 5 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Introduction

1 Introduction
The demo explains how to communicate with one CM CANopen running in
CANopen mode to exchange process image data, to process SDO Read / Write
and to process Get Node & Network Status.

The demo must be enhanced if the PLC shall communicate with several CM
CANopen modules running in CANopen mode.

Hint: SDO FBs

 These FBs have been revised to provide more performance
 The interface of the CANopen interface function blocks differs from the
description in the user manual of the CM CANopen
 The actual interface is described
 for ReadSDO FB by chapter 5.3.1
 for WriteSDO FB by chapter 5.4.1

Replacement of the PLC:

cases:
 The main version number of the PLC to be used is equal to the main
version number of the PLC of the demo
 replace the PLC of the demo
 The main version number of the PLC to be used is greater than the main
version number of the PLC of the demo
 replace the PLC of the demo by a PLC similar to the finally used
one
 afterwards replace this PLC by the actual used PLC
 The main version number of the PLC to be used is smaller than the
main version number of the PLC of the demo
 generate a library of the demo
 remove the PLC of the demo
 add the used PLC
 import the demo library

Copyright HMS Technology Center 7 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Introduction

1.1 Restrictions

The CM CANopen supports CAN 2.0A (11 bit CAN identifier) but it does not
support CAN 2.0B (29 bit CAN identifier).

“CANopen Manager auto configuration” in “Module parameters” of the CM

CANopen module in TIA Portal must not be activated:
 the mechanism has not been defined to inform the application about the
auto generated configuration

The CM CANopen does not support bit mapping.

 contact support if it is possible that the single bits can be mapped in bytes

Hint:
The CM CANopen may lose CAN frames received from the CAN bus if the used
CAN baudrate is higher than 250kBaud.

1.2 Related Documents

Document name Author

CM CANopen - User Manual.pdf HMS
Rev 1.00

Copyright HMS Technology Center 8 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Hardware identifier of the CM module

2 Hardware identifier of the CM module

The hardware identifier is needed by
 the used RDREC instance to process “Get Process Data In”
=> input ID of RDREC
 the used RDREC instance to process “Get Node & Network Status”
=> input ID of RDREC
 the used WRREC instance to process “Set Process Data Out”
=> input ID of WRREC
 the instances of ReadSDO FB / WriteSDO FB
=> input ID of ReadSDO FB / WriteSDO FB
to address the CM CANopen module.

2.1 TIA Portal V11 / V12

The hardware identifier of the CM CANopen module is provided by the hardware
configuration of the CM CANopen module.

Copyright HMS Technology Center 9 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Hardware identifier of the CM module

2.2 TIA Portal V13

The hardware identifier of the CM CANopen module is provided by the hardware
configuration of the CM CANopen module.

Copyright HMS Technology Center 10 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Hardware identifier of the CM module

Alternatively:
TIA Portal V14 also provides a system constant that is provided by:
hardware configuration of the CM CANopen module / System constants

Copyright HMS Technology Center 11 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Hardware identifier of the CM module

2.3 TIA Portal V14

The hardware identifier of the CM CANopen module is provided by the hardware
configuration of the CM CANopen module.

Copyright HMS Technology Center 12 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Hardware identifier of the CM module

Alternatively:
TIA Portal V14 also provides a system constant that is provided by:
PLC tags / Show all tags / System constants

“Local~CM_CANopen_1” is the hardware identifier of the CM module with the

name:
CM CANopen_1
Its data type must be Port.

Copyright HMS Technology Center 13 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Hardware identifier of the CM module

2.4 TIA Portal V15, V15.1

Siemens has removed the hardware identifier of the CM CANopen module
from the hardware configuration of the CM module.
The hardware identifier of the CM CANopen module can be found in:
PLC tags / Show all tags / System constants

Device configuration:

Hardware Id of the CM module: CM CANopen_1

“Local~CM_CANopen_1” is the hardware identifier of the CM module with the

name:
CM CANopen_1
Its data type must be Port.

Copyright HMS Technology Center 14 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Overview of the CANopen demo

3 Overview of the CANopen demo

Description of OB 1:
 Network 1:
processing of a “Get Node & Network Status” command

 Network 2:
upload of process image input data

 Network 3:
download of process image output data

 Network 4 - 6:
processing of a SDO Read command

Network 4: initiate and request the processing of a SDO Read

command
Network 5: run the requested SDO Read command
Network 6: analyze the result of the processed SDO Read command
and interpret the data

 Network 7 - 9:
processing of a SDO Write command

Network 7: initiate and request the processing of a SDO Write

command
Network 8: run the requested SDO Write command
Network 9: analyze the result of the processed SDO Write command

Copyright HMS Technology Center 15 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4 Exchange of process image data

4.1 General hints

Exchange of process image data between the PLC and the CM CANopen:
 The process image data are not exchanged via the process image area
of the PLC.
 The process image of the CM CANopen is organized as a byte array
which is read by RDREC / written by WRREC.
 WRREC / RDREC request the transmission of an asynchronous
telegram:
 the transmission of the asynchronous telegram is not deterministic
 it must be avoided that the read / written data will be corrupted
 it is recommended to differentiate between the data that are
exchanged with the CM CANopen and the data that are used by
the application to control the process

Conditions: exchange of process image data with the CANopen network:

 The CM CANopen neither receives nor transmits PDOs if it is not
operational.
 There is an additional condition for the CM CANopen running in CANopen
Manager mode:
 minimum one slave device must be operational
otherwise the CM CANopen will not transmit any TPDO
 the information which slaves are operational is provided by
 “Get Node & network Status”
see chapter 8.1.4 Get Node & Network Status
of the CM CANopen manual
 Index 5004h
see chapter 7.3 Manufacturer Specific Objects
of the CM CANopen manual

Default value of the process image:

 Each byte of the input and output area is initialized with 0 after power
on.

Copyright HMS Technology Center 16 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

Data format of the exchanged data between the PLC and the CM CANopen:
 The data format is little endian (CANopen format)
least significant byte at low address
most significant byte at high address
 whereas the data format of the PLC is big endian
most significant byte at low address
least significant byte at high address
 16 bit values / 32 bit values must be swapped
 hint: REAL
REAL variables requires an individual conversion
 SWAP(real value) does not return the correct value sometimes
 suggested method:
1. convert read data to DWORD
2. swap DWORD value
3. convert DWORD value to REAL

Performance:
The best performance is reached
 process image input
 CANopen input data size = MLEN = actual size
 CANopen input data size:
=> hardware configuration of the CM module in TIA Portal
=> Module parameters
=> CANopen input data size
 MLEN:
=> MLEN input of RDREC which is used to upload the
process image input
 actual size:
=> byte size of the process image input that covers all
mapped data
see CM CANopen Configuration Studio:
“Process Image”: Direction: IN
 more details are provided by:
chapter 4.2.1

Copyright HMS Technology Center 17 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

 process image output

 CANopen output data size = LEN = actual size
 CANopen output data size:
=> hardware configuration of the CM module in TIA Portal
=> Module parameters
=> CANopen output data size
 LEN:
=> LEN input of WRREC which is used to upload the
process image output
 actual size:
=> byte size of the process image output that covers all
mapped data
see CM CANopen Configuration Studio:
“Process Image”: Direction: OUT
 more details are provided by:
chapter 4.3.1

4.2 Get Process Data In

Program group "Get Process Data In" provides all functionality to process the
upload of the process image input from the CM CANopen and to update the
data for the PLC.
The process image input data are handled by:
 “CANopenProcessImage“.Input.CM_Data
 the read data are copied to this area by RDREC
 its data format is little endian
 “CANopenProcessImage“.Input.PLC_Data
 this area provides the read and converted data for the application
 its data format is big endian
 the user constant "cByteSize_PIInput_Struct"
 byte size of “CANopenProcessImage“.Input.CM_Data

Hint:
 it is recommended to differentiate between the uploaded data and the
data of the application to avoid inconsistencies caused by the
asynchronous upload of the process image

Hint: Implementation
 The implementation of “Get Process Data In” by the CANopen demo is
based on the layout of the “Process Image” of the demo project of the
CM CANopen Configuration Studio.
Copyright HMS Technology Center 18 CM CANopen, CANopen Application, V1.0
Ravensburg GmbH
 Exchange of process image data

4.2.1 Layout of the Process Image

Layout of the “Process Image” in CM CANopen Configuration Studio:

Layout of the “Process Image” – Direction: IN – how it is managed

Byte Address Object Byte Structure

Array: Node- Index Sub- Size used by the PLC
Offset ID Index
0 00000000 1 1001 00 1 N1_ErrorRegister
1 00000001 1 6000 01 1 N1_DigitalIn_1
2 00000002 1 6000 02 1 N1_DigitalIn_2
3 00000003 2 1001 00 1 N2_ErrorRegister
4 00000004 2 6000 01 1 N2_DigitalIn_1
5 unused 1 Dummy_Byte5
6 00000006 1 6401 01 2 N1_AnalogIn_1
7
8 00000008 2 6401 01 2 N2_AnalogIn_1
9
10 unused 1 Dummy_Byte10
11 unused 1 Dummy_Byte11
12 0000000C 1 2000 00 4 N1_StatusRegister

Copyright HMS Technology Center 19 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

13
14
15
16 00000010 2 6404 1 4 N2_AnalogInFloat_1
17
18
19
20
… free space of the process image input that does not carry data
255
(max)

The process image input of the CM module is a byte array whose application
specific use is defined by the layout of the “Process Image: Direction: IN” in the
Configuration Studio.

Notation:
 Byte Array: Offset
description of the process image input as a byte array
 Address, Node-ID, Index und Sub-Index
correspond to the same-named columns of the process image in
the CM CANopen Configuration Studio
 Byte Size: byte size of the mapped object  Size (bit) / 8
 Nx  Node-ID x
 Structure used by the PLC
description of the process image input as a structure

Copyright HMS Technology Center 20 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

The process image input is always read from offset 0 up to offset x:

 offset 0 is read first, offset x is transferred last
 unused bytes – bytes that do not carry data – are also transferred if their
offset is smaller than / equal to x
 x depends of:
 x + 1 = minimum of
 MLEN input of RDREC which is used to read the process
image
 “CANopen input data size“ in “Module parameters” of the
hardware configuration of the CM module in TIA Portal

 minimum size of the process image input that covers all data
 rule:
 minimum size = highest “Address“ of Direction: IN
+ byte size of the object at this address
 consequences
 minimum size <= “CANopen input data size“
 minimum size <= MLEN input of RDREC which is used to
read the process image
 best performance:
 minimum size = MLEN input = “CANopen input data size“

The demo uploads the process image as a structure.

Advantages of the structure:

 changes of the Process Image: Direction: IN in the CM CANopen
Configuration Studio during development are much more easily managed
by the structure
 mainly the definition of the structure has to be adjusted
 whereas the use of the byte array requires that each offset must be
checked and adjusted individually

Copyright HMS Technology Center 21 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.2.2 Hardware Configuration of the CM module in TIA Portal

The selected value of “CANopen input data size“

 reflects the minimum byte size that covers all data bytes
 provides the best performance
for the demo layout of the process image input in the Configuration Studio.

4.2.3 Description of the used structure

The demo uses the structure ”PIInput” that is defined in “PLC Data Types”:

Copyright HMS Technology Center 22 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.2.4 Upload and update of the process image input data

Upload and update of the process image input data consists of
 GetProcessDataIn [FC1]
main function of the upload
 function must not be modified by the user
 UpdatePIInData_PLC [FC2]
updates the process image input data used by the PLC program
 function must be adjusted by the user
 ProcessImageData [DB14]
DB for the process image data
 the input data structures are automatically updated after
Compile => Software (rebuild all blocks)
when the structure for the process image input has been
modified
 the user constant "cByteSize_PIInput_Struct"
must be adjusted by the customer

4.2.4.1 ProcessImageData [DB14]

The process image input data are handled by:
 “CANopenProcessImage“.Input.CM_Data
 data type: ”PIInput”
 the read data from the Cm module are copied to this area by
RDREC
 its data format is little endian
 “CANopenProcessImage“.Input.PLC_Data
 data type: ”PIInput”
 this area provides the read and converted data for the application
 its data format is big endian
 "cByteSize_PIInput_Struct"
 byte size of the structure "PIInput"
 byte size of “CANopenProcessImage“.Input.CM_Data

Hint: CANopenProcessImage [B14]

 DB shall not be optimized
 must be disabled in “Properties” of the DB
 offset of a mapped object in the structure – offset of the structure =
“Address” of the mapped object in the Process Image:
Direction: IN of the Configuration Studio

Copyright HMS Technology Center 23 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.2.4.2 GetProcessDataIn [FC1]

GetProcessDataIn [FC1]
 uploads the process image input data from the CM CANopen
 updates the process image input data used by the PLC program to
control the process

This function must not be modified by the customer.

Parameters of GetProcessDataIn [FC1]:

 Input:
 HW_ID hardware identifier of the CM CANopen in TIA Portal
data type: HW_IO

Upload of the process image from the CM module:

The process image input is read from the CM module
by "RDREC_GetProcessDataIn"( )
which is an instance of RDREC:

"RDREC_GetProcessDataIn"(REQ:=TRUE,
ID:=#HW_ID,
INDEX:=16#90,
MLEN:= "cByteSize_PIInput_Struct",
VALID=>#fValid,
BUSY=>#fBusy,
ERROR=>#fError,
STATUS=>#dwStatus,
LEN=>#uiLen,
RECORD:="CANopenProcessImage".Input.CM_Data.Data);

Hint: LEN output of "RDREC_GetProcessDataIn"( )

LEN output informs about the number of uploaded data bytes
 when BUSY output has switched to FALSE
 and ERROR output = FALSE
 and VALID output = TRUE

Copyright HMS Technology Center 24 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.2.4.3 UpdatePIInData_PLC [FC2]

UpdatePIInData_PLC [FC2]
 is called by GetProcessDataIn [FC1] when the data have been uploaded
 updates the process image input data that are used by the PLC program
to control the process
 the updated data are converted to the data format of the PLC

UpdatePIInData_PLC [FC2] must be coded by the user.

Parameters of UpdatePIInData_PLC [FC2]:

 Input:
 uiLen: number of uploaded data bytes
= LEN output of "RDREC_GetProcessDataIn"( )

The update of the process image input data of the application uses the
variables:
 the uploaded “CANopen” data are provided by
“CANopenProcessImage“.Input.CM_Data
 the updated “PLC” data are provided by:
“CANopenProcessImage“.Input.PLC_Data

4.2.5 Adaption of the demo to the user`s application

The adaption of the demo consists of the following steps:
1. adaption of the structure ”PIInput” that is defined in “PLC Data Types” to
the layout of “Process Image: Direction: IN” in the CM CANopen
Configuration Studio

2. adaption of the byte size of the structure ”PIInput”

=> user constant: "cByteSize_PIInput_Struct"

3. adaption of UpdatePIInData_PLC [FC2]

4. adaption of “Module parameters: CANopen input data size”

Copyright HMS Technology Center 25 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.3 Set Process Data Out

Program group "Set Process Data Out" provides all functionality to process the
download of the process image output to the CM CANopen.
The process image input data are handled by:
 "CANopenProcessImage".Output.PLC_Data
 this area provides the process image output data of the
application
 its data format is big endian
 “CANopenProcessImage“.Output.CM_Data
 this area provides converted data that are written to the CM
module
 its data format is little endian
 the user constant "cByteSize_PIOutput_Struct"
 byte size of "CANopenProcessImage".Output.CM_Data

Hint:
 it is recommended to differentiate between the downloaded data and the
data of the application to avoid inconsistencies caused by the
asynchronous download of the process image

Hint: Implementation
 The implementation of “Set Process Data Out” by the CANopen demo is
based on the layout of the “Process Image” of the demo project of the
CM CANopen Configuration Studio.

Copyright HMS Technology Center 26 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.3.1 Layout of the Process Image

Layout of the “Process Image” in CM CANopen Configuration Studio:

Layout of the “Process Image” – Direction: OUT – how it is managed

Byte “Address“ Object Byte Structure

Array: Node- Index Sub- Size used by the PLC
Offset ID Index
0 00000000 1 6200 01 1 N1_DigitalOut_1
1 00000001 1 6200 02 1 N1_DigitalOut_2
2 00000002 2 6200 01 1 N2_DigitalOut_1
3 00000003 2 6200 02 1 N2_DigitalOut_2
4 00000004 1 6411 1 2 N1_AnalogOut_1
5
6 00000006 1 6411 2 2 N1_AnalogOut_2
7
8 00000008 2 6411 1 2 N2_AnalogOut_2
9
10 unused 1 Dummy_Byte10
11 unused 1 Dummy_Byte11
12 0000000C 1 6413 1 4 N1_AnalogOutFloat_1

Copyright HMS Technology Center 27 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

13
14
15
16
… free space of the process image output that does not carry data
255
(max)

The process image output of the CM module is a byte array whose application
specific use is defined by the layout of the “Process Image: Direction: OUT” in
the Configuration Studio.

Notation:
 Byte Array: Offset
description of the process image input as a byte array
 Address, Node-ID, Index und Sub-Index
correspond to the same-named columns of the process image in
the CM CANopen Configuration Studio
 Byte Size: byte size of the mapped object  Size (bit) / 8
 Nx  Node-ID x
 Structure used by the PLC
description of the process image input as a structure

The process image output is always written to offset 0 up to offset x:

 offset 0 is written first, offset x is transferred last
 unused bytes – bytes that do not carry data – are also transferred when
they are located in the downloaded range
 x depends of:
 x + 1 = minimum of
 LEN input of WRREC which is used to write the process
image to the CM module
 “CANopen output data size“ in “Module parameters” of the
hardware configuration of the CM module in TIA Portal

Copyright HMS Technology Center 28 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

 minimum size of the process image output that covers all data
 rule:
 minimum size = highest “Address“ of Direction: OUT
+ byte size of the object at this address
 consequences
 minimum size <= “CANopen output data size“
 minimum size <= LEN input of WRREC which is used to
write the process image
 best performance:
 minimum size = LEN input = “CANopen output data size“

The demo manages the process image as a structure.

Advantages of the structure:

 changes of the Process Image: Direction: OUT in the CM CANopen
Configuration Studio during development are much more easily managed
by the structure
 mainly the definition of the structure has to be adjusted
 whereas the use of the byte array requires that each offset must be
checked and adjusted individually

4.3.2 Hardware Configuration of the CM module in TIA Portal

The selected value of “CANopen output data size“

 reflects the minimum byte size that covers all data bytes
 provides the best performance
for the demo layout of the process image output in the Configuration Studio.

Copyright HMS Technology Center 29 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.3.3 Description of the used structure

The demo uses the structure ”PIOutput” that is defined in “PLC Data Types”:

4.3.4 Download of the process image output data

Download of the process image output data consists of
 SetProcessDataOut [FC3]
main function of the download
 function must not be modified by the user
 UpdatePIOutData_CM [FC4]
updates and converts the process image output data that are
written to the CM module
 function must be adjusted by the user
 "ProcessImageData"
DB for the process image data
 the output data structures are automatically updated after
Compile => Software (rebuild all blocks)
when the structure for the process image output has been
modified
 the user constant “cByteSize_PIOutput_Struct“
must be adjusted by the customer
 "Ctrl_CM_CANopen".SetPIOut
structure to control the processing of the download of the process
image
 structure must not be modified by the user

Copyright HMS Technology Center 30 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.3.4.1 ProcessImageData [DB14]

The process image output data are handled by:
 "CANopenProcessImage".Output.PLC_Data
 data type: ”PIOutput”
 this area provides the data that are used by the application to
control the process
 its data format is big endian
 "CANopenProcessImage".Output.CM_Data
 data type: ”PIOutput”
 this area keeps the updated and converted data that are written to
the CM module
 its data format is little endian
 the user constant "cByteSize_PIOutput_Struct"
 byte size of the structure ”PIOutput”
 byte size of "CANopenProcessImage".Output.CM_Data

Hint: CANopenProcessImage [B14]

 DB shall not be optimized
 must be disabled in “Properties” of the DB
 offset of a mapped object in the structure = “Address” of the mapped
object in the Process Image: Direction: OUT of the Configuration Studio

4.3.4.2 SetProcessDataOut [FC3]

SetProcessDataOut [FC3]
 checks if a download of the process image has been requested by the
application
see: line 54 – 57
 checks if there is a running download of the process image
see: line 62
 calls UpdatePIOutData_CM [FC4] that updates the data that are written
to the CM CANopen
see: line 74
and updates the state machine of the download
see: line 78
 processes the download
see: line 84 - 92
 checks if the download has been processed
see: line 95 – 98
 checks the result of the processed download
see: line 104 - 113
 updates the state machine of the processed download
see: line 120

Copyright HMS Technology Center 31 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

 clears the request that indicates the download has been processed
see: line 126
SetProcessDataOut [FC3] must not be coded by the customer.

Parameters of SetProcessDataOut [FC3]:

 Input:
 HW_ID hardware identifier of the CM CANopen in TIA Portal
data type: HW_IO
 InOut:
 REQ TRUE: process image output shall be written
FALSE: process image shall not be written

hint:
set flag shall not be reset by the
application
REQ is automatically set to FALSE by the
function when the command has been
processed

The download of the “CANopen” process image output uses the variables:
 data record
"CANopenProcessImage".Output.CM_Data
see input RECORD of "WRREC_SetProcessDataOut"()

 length of the data record to be transferred in bytes

„cByteSize_PIOutput_Struct“
see input LEN of "WRREC_SetProcessDataOut"()

 state machine of SetProcessDataOut [FC3]

"Ctrl_CM_CANopen".SetPIOut.fUpdateData

"WRREC_SetProcessDataOut"():
 instance of WRREC that is used by SetProcessDataOut [FC3] to
download the process image to the CM CANopen

Copyright HMS Technology Center 32 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Exchange of process image data

4.3.4.3 UpdatePIOutData_CM [FC4]

UpdatePIOutData_CM [FC4]
 is called by SetProcessDataOut [FC3] before the data are written to the
CM CANopen module
 updates the process image output data that will be written to the CM
CANopen
 the updated data are converted to the data format of CANopen

UpdatePIInData_PLC [FC4] must be coded by the user.

Parameters of UpdatePIOutData_CM [FC4]:

 no parameters

The update of the “CANopen” process image output data that are written
to the CM CANopen uses the variables:
 the “PLC” data are provided by:
"CANopenProcessImage".Output.PLC_Data
 the updated “CANopen” data are transferred by
"CANopenProcessImage".Output.CM_Data

4.3.5 Adaption of the demo to the user`s application

The adaption of the demo consists of the following steps:
1. adaption of the structure ”PIOutput” that is defined in “PLC Data Types”
to the layout of “Process Image: Direction: Out” in the CM CANopen
Configuration Studio

2. adaption of the byte size of the structure ”PIOutput”

=> user constant "cByteSize_PIOutput_Struct"

3. adaption of UpdatePIOutData_CM [FC4]

4. adaption of “Module parameters: CANopen output data size”

Copyright HMS Technology Center 33 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5 SDO commands
5.1 General hint
5.1.1 Processing of a SDO command
The execution of a SDO command needs time
 especially if another device than the CM module is accessed
 especially if a high amount of data is transferred
 due to the use of Siemens SFBs WRREC and RDREC

A started command must be processed until it has signaled finished otherwise

the related state machines will be confused and the data will be corrupted:
 the CM module may run into a fatal error situation
=> only power off / on will resolve it
 the PLC will detect a serious error
=> only power off / on will resolve it

Note: outputs of ReadSDO [FB104] / WriteSDO [FB105]

 The outputs are only valid when the output BUSY has switched to
FALSE.

Note: SLOT
 SLOT must not be confused with the physical slot of the module
 The CM module internally uses SDO channels
 These SDO channels are not visible in the hardware configuration in TIA
portal
 SLOT defines the SDO channel to be used for the requested SDO
command

Copyright HMS Technology Center 34 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.1.2 Data format

The data are transferred

 from the device to the PLC according their received byte order
 from the PLC to the device according their byte order in the PLC

The data format is little endian (CANopen format)

 the least significant byte (LSB)
is transferred first
is located at low address
 the most significant byte (MSB)
is transferred last
is located at high address

The data format of the PLC is big endian

 the least significant byte (LSB)
is located at high address
 the most significant byte (MSB)
is located at low address

Data must be usually swapped before downloading or after being

uploaded:
 overview: standard data types

Bit size data types Swap

CANopen PLC
8 INTEGER8 SInt no
UNSIGNED8 USint, Byte
16 INTEGER16 Int yes
UNSIGNED16 UInt, Word
32 INTEGER32 Dint yes
UNSIGNED32 UDInt, DWord
REAL32 Real

 not standard data types:

 must be interpreted (read data) / entered (write data) individually

Copyright HMS Technology Center 35 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Examples: Write SDO

 the data are transferred to the CM module via a defined byte array
 definition of the byte array:
“SDO_WriteData” Array[1..x] of Byte

x is set by the customer

see chapter 5.4.1

 example:
the data to be written are provided by "SDO_Data_DB".WrData
data type of WrData: “SDO_WriteData”
 general:
1. transmitted data byte
"SDO_Data_DB".WrData.SDO_WriteData [1]
…
n. transmitted data byte
"SDO_Data_DB".WrData.SDO_WriteData [n]
 8 bit value:
value to be written: 16#12
=> "SDO_Data_DB".WrData.SDO_WriteData[1] := 16#12;
 16 bit value:
value to be written: 16#1234
=> "SDO_Data_DB".WrData.SDO_WriteData [1] := 16#34; // LSB
"SDO_Data_DB".WrData.SDO_WriteData [2] := 16#12; // MSB
 32 bit value:
value to be written: 16#12345678
=> "SDO_Data_DB".WrData.SDO_WriteData [1] := 16#78; // LSB
"SDO_Data_DB".WrData.SDO_WriteData [2] := 16#56;
"SDO_Data_DB".WrData.SDO_WriteData [3] := 16#34;
"SDO_Data_DB".WrData.SDO_WriteData [4] := 16#12; // MSB

Copyright HMS Technology Center 36 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Examples: Read SDO

 the read data are copied to a defined byte array
 definition of the byte array:
“SDO_ReadData” Array[1.. y] of Byte

y is set by the customer

see chapter 5.3.1

 example:
the read data are copied to „SDO_Data_DB“.RdData
data type of RdData: “SDO_ReadData”
 general:
1. transmitted / received data byte
„SDO_Data_DB“.RdData.SDO_ReadData [1]
…
n. transmitted / received data byte
„SDO_Data_DB“.RdData.SDO_ReadData [n]
 8 bit value:
„SDO_Data_DB“.RdData.SDO_ReadData[1] = 16#12
=> read value: 16#12
 16 bit value:
„SDO_Data_DB“.RdData.SDO_ReadData [1] = 16#34; // LSB
„SDO_Data_DB“.RdData.SDO_ReadData [2] = 16#12; // MSB
=> read value: 16#1234
 32 bit value:
„SDO_Data_DB“.RdData.SDO_ReadData [1] = 16#78; // LSB
„SDO_Data_DB“.RdData.SDO_ReadData [2] = 16#56;
„SDO_Data_DB“.RdData.SDO_ReadData [3] = 16#34;
„SDO_Data_DB“.RdData.SDO_ReadData [4] = 16#12; // MSB
=> read value: 16#12345678

Hint: conversion of Real data

 direct conversion of a Real value does not work reliably
therefore the conversion should be processed in 2 steps
 Write SDO
1. convert the Real value to DWord
2. Split the DWord in bytes
 Read SDO
1. convert the read data to DWord
2. convert the DWord to Real

Copyright HMS Technology Center 37 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.1.3 Parallel processed SDO commands

Maximum number of parallel processed SDO commands:

 maximum 4 SDO commands ( independent of read or write ) can be
processed at the same time

 this limitation is set by the S7 1200 although the CM module supports up

to 8 SDO channels ( see input SLOT of ReadSDO / WriteSDO FBs )

 but each SDO channel can be used ( SLOT 0 - 7 )

Restrictions for parallel processed SDO commands:

parallel processed SDO commands
 must use different instance FBs
otherwise the processing will be corrupted:
 the CM module may run into a fatal error situation
=> only power off / on will resolve it
 the PLC will detect a serious error
=> only power off / on will resolve it

 must access different CANopen devices

note:
 a CANopen device must support the 1. SSDO
but it must not support additional SSDOs
 the CM module always uses the 1. SSDO of the slave device to
run a SDO command
 the CM module checks if the requested SDO command collides
with a running SDO command and will not execute it
=> input NODE of parallel processed ReadSDO / WriteSDO commands
must differ

 must use different slots ( SDO channels )

to avoid that the running SDO command will be corrupted

=> input SLOT of parallel processed ReadSDO / WriteSDO commands

must differ

 must not share the same data area

otherwise the data will be corrupted

there is one exception:

 the same data shall be written to different devices

Copyright HMS Technology Center 38 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.1.4 Application note “CANopen manager” mode

SDO command that accesses a slave device should not be performed before
the slave has been successfully booted / configured because:
 the configuration of the slave is only consistent when it has been booted
successfully
 consequences if the slave has not been booted successfully:
 SDO read command:
read data may be erroneous because they are based on a
configuration which is only provided by a successfully booted
slave
 SDO write command:
its data will be most probably overwritten or reset to default by
the later processed boot slave process

"Get Node & Network Status" or the diagnostic objects 5002h ( Configured
slaves bit list ) and 5004h ( Operational slaves bit list ) of the CM module
provide the status information - booted / configured / operational – of the
slaves.
Note:
 only a successfully booted slave can be set to operational.

Copyright HMS Technology Center 39 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.1.5 Restrictions “CANopen slave” mode

Accessed CANopen device: CM module

 SDO read command:
there are not any restrictions:
the object dictionary of the CM module can be read
 SDO write command
cases:
 CANopen network with a CANopen master:
The object dictionary of the CM module shall not be
configured by the PLC to avoid inconsistencies of the over -
all configuration of the CANopen network
 CANopen network without a CANopen master
 the object dictionary of the CM module can be configured
by the PLC
the customer is responsible for a consistent
configuration of the CANopen network
 request NMT commands: index 1F82h
 reset node / reset communication / set preoperational
and set stopped of the CM module:
can be requested by the PLC

allowed action:
index: 1F82h
subindex: CANopen node-id of the CM
module
value: 4  set stopped
6  reset node
7  reset communication
127  set preoperational

 set operational of the CM module:

can be requested by the PLC
condition:
the CM module must be configured as a self-
starting device:
1F80h, subindex 0 = 16#00000008

allowed action:
index: 1F82h
subindex: CANopen node-id of the CM
module
value: 5  set operational

Copyright HMS Technology Center 40 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

 set operational all nodes / the CANopen network:

can be requested by the PLC
condition:
the CM module must be configured as as a
slave that shall execute the NMT service start
remote node with node-ID set to 0:
1F80h, subindex 0 = 16#00000002

allowed action:
index: 1F82h
subindex: 80h
value: 5  set operational

Accessed CANopen device: another device ( not the CM module )

Cases:
 CANopen network with a CANopen master:
the object dictionary of other devices shall not be accessed
 to avoid SDO conflicts
only the CANopen master is allowed to initiate a SDO
communication
 to avoid inconsistencies of the over - all configuration of the
CANopen network

 CANopen network without a CANopen master:

it is possible
 the customer is responsible that it will not cause SDO conflicts
 the customer is responsible for a consistent configuration of the
CANopen network

Copyright HMS Technology Center 41 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.2 SDO Demo

The CANopen demo shows how to run one SDO read / SDO Write command.
The CANopen demo uses
 SLOT 0 (  SDO channel 0 ) for SDO read
 SLOT 1 (  SDO channel 1 ) for SDO write

The CANopen demo must be enhanced to run several parallel SDO read /
several parallel SDO write commands.

5.3 SDO Read

Program group "SDO Read" provides all functionality to process a SDO read
command.
The processing of a “SDO read” command is controlled by the structure:
"Ctrl_CM_CANopen".ReadSDO
This structure holds all information to run a SDO read command and it
provides the data area where to save the read data.

The processing of a SDO read command consists of the steps:

1. check if a new SDO read command shall be processed:
if yes:
initiate and request the processing of the SDO Read command

the check and the initialization is done by

SDORead_Request [FC6]
that is called in Network 4 of OB1

2. run the requested SDO read command

the requested SDO read command is processed by

an instance of ReadSDO [FB104]
that is called in Network 5 of OB1

3. analyze the result of the processed SDO Read command and interpret
the data

Analysis of the result and interpretation of the read data is done by

SDORead_InterpretReadData [FC7]
that is called in Network 6 of OB1

Copyright HMS Technology Center 42 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.3.1 Description of ReadSDO [FB104]

The ReadSDO FB has been revised to provide more performance.

Input Parameters:

Name Data type Description

REQ Bool Start request:
- REQ is only relevant when the FB is idle ( it does
not process a requested command)
- idle state and REQ = TRUE
starts the requested SDO read command
ID HW_IO Hardware address for the module. Can be read in
TIA Portal.
SLOT Byte Defines which SDO channel is used.

This parameter has to be unique for each of the

SDO requests running simultaneously.

Valid values: 0 – 7

Note:
This slot defines a SDO channel and must not be
confused with the physical slot of the module
NODE Int Node-ID of the CANopen module where SDO read
is to be performed.

Valid values: 0 - 127

Note:
Node-ID 0 always addresses the CM module even
when the CM module has another Node-ID
INDEX Word index of the object to be read
SUB Byte subindex of the object to be read
MAX_SIZE DInt Byte size of the destination area where the read
data are saved
 limit of data bytes that can be read and saved

Copyright HMS Technology Center 43 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Output Parameters:

Name Data type Description

BUSY Bool BUSY turns TRUE and stays TRUE until the
request is finished, then it returns to FALSE.

Note:
REQ = FALSE in idle state:
=> BUSY = FALSE
=> RET =0
=> SIZE =0
RET UInt Error code
see description of RET in chapter 8.1.3 SDO
Read/Write

Available when BUSY turns FALSE

SIZE UInt Number of bytes that have been read
DATA "SDO_ReadData" Data area where to save the read data

Modifications of the revised ReadSDO FB:

 input DB has been removed
 POKE that had to be used to copy the read data to the DB
consumes a lot of time
 each parallel processed SDO read command needs its own DB
 input MAX_SIZE has been added
 the revised FB checks if the read data exceed the size of the
destination area to avoid that other data will be overwritten
 CountOfElement cannot be used because this function is not
supported by PLCs with an older version than V4.0
 output DATA has been added
 DATA replaces the input DB
 note:
 MOVE_BLK_VARIANT cannot be used because this
function is not supported by PLCs with an older version than
V4.0
 "SDO_ReadData" is defined in PLC data types
SDO_ReadData Array[1..n] of Byte

note:
 "SDO_ReadData" must be a byte array
 The customer can only vary n to adjust the byte size to its
application

Copyright HMS Technology Center 44 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

 The project must be compiled when the size of

"SDO_ReadData" has been changed

Definition of "SDO_ReadData" by the demo:

 SDO_ReadData Array[1.."cSDORead_MaxDataSize"] of Byte
 "cSDORead_MaxDataSize"
is defined in PLC tags: User constants
 "cSDORead_MaxDataSize"
is passed to the input MAX_SIZE of ReadSDO FB

5.3.2 Structure: "Ctrl_CM_CANopen".ReadSDO

This structure holds all information to run a SDO read command.
The SDO read demo is based on this structure.

Description of the structure ReadSDO:

Name Data type Description

fREQ Bool flag controls REQ input of ReadSDO FB
HW_ID HW_IO hardware identifier of the accessed CM
module in TIA Portal
bSLOT Byte selected SLOT (SDO channel)
iNODE Int CANopen node id of the accessed device
wINDEX Word index of the object dictionary
bSUB Byte subindex of the object dictionary
diMaxSize Dint limit of data bytes that can be read and
saved
fBusy Bool status of a requested SDO read
command:
=> value of output BUSY of ReadSDO FB
uiRet UInt result of a processed SDO read
command:
=> value of output RET of ReadSDO FB
uiSize UInt number of uploaded data bytes
=> value of output SIZE of ReadSDO FB
Data "SDO_ReadData" Data area where the read data are saved

Copyright HMS Technology Center 45 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.3.3 SDORead_Request [FC6]

This function
 checks if a new SDO read command shall be processed
 initializes the parameters of the SDO command
 requests the processing of the initialized SDO read command

Restriction of the CANopen demo:

 function is not called when there is a running SDO read command
because
 the CANopen demo shows how to run one SDO read command
 the CANopen demo is not an example for parallel processed SDO
read commands

Note:
 the purpose of this function is to explain how to initialize the inputs of
ReadSDO [FB104] to run a SDO read command

Description of the demo function:

 lines 100 – 105
 the demo does not request the processing of a SDO read
command
 the customer`s application has to decide if a SDO read command
shall be processed

 line 109:
 initialization of the hardware identifier of the accessed CM module
 line 133:
 demo uses SLOT 0 for read SDO command
 demo example reads the error register of the CANopen device with the
of the CANopen node id 1
 line 138 : accessed CANopen device
 line 143 : index of the object to be read
 line 148 : subindex of the object to be read
 line 159:
 demo indicates that read SDO command shall be processed

 demo always copies the read data to

“Ctrl_CM_CANopen“.ReadSDO.Data

 demo passes "cSDORead_MaxDataSize" to the input MAX_SIZE of the

ReadSDO FB
=> "Ctrl_CM_CANopen".ReadSDO.diMaxSize is not used

Copyright HMS Technology Center 46 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Parameters of SDORead_Request [FC6]:

 Input:
 HW_ID hardware identifier of the accessed CM
CANopen in TIA Portal
data type: HW_IO
 Output:
 RUN_SDOREAD flag indicates if a SDO read command
shall be processed
TRUE: process the initialized SDO
read command
FALSE: no SDO read command shall
be processed

5.3.4 SDORead_InterpretReadData [FC7]

This function is called when the requested SDO read command has been
processed.

Function
 checks if the requested command has been processed successfully:
 an error has been detected:
lines 54 – 59:
analysis and reaction must be coded by the customer

 interprets the successfully read data:

 number of read data bytes:
=> Input: uiSize
 data area where the read data are saved:
demo:
=> “Ctrl_CM_CANopen“.ReadSDO.Data
 order of reception:
first read/received data byte (LSB):
"Ctrl_CM_CANopen".ReadSDO.Data.SDO_ReadData [1]
…
last read/received data byte (MSB):
"Ctrl_CM_CANopen".ReadSDO.Data.SDO_ReadData [#uiSIZE]
 lines 64 – 163:
comment: how to interpret the data
line 166:
customer has to code the processing of the read data

 clears the current SDO read request

 line 173

Copyright HMS Technology Center 47 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Parameters of SDORead_InterpretReadData [FC7]:

 Input:
 uiRET result of the processed SDO read command
=> value of output RET of ReadSDO [FB104]
 uiSIZE number of read data bytes
=> value of output SIZE of ReadSDO [FB104]
 InOut:
 ClearReq clears the current SDO read request

5.4 SDO Write

Program group "SDO Write" provides all functionality to process a SDO write
command.
The processing of a “SDO write” command is controlled by the structure:
"Ctrl_CM_CANopen".WriteSDO
This structure holds all data and information to run a SDO write command.

The processing of a SDO write command consists of the steps:

1. check if a new SDO write command shall be processed:
if yes:
initiate and request the processing of the SDO write command

the check and the initialization is done by

SDOWrite_Request [FC5]
that is called in Network 7 of OB1

2. run the requested SDO write command

the requested SDO write command is processed by

an instance of WriteSDO [FB105]
that is called in Network 8 of OB1

3. analyze the result of the processed SDO write

Analysis of the result is done by

SDOWrite_InterpretResult [FC8]
that is called in Network 9 of OB1

Copyright HMS Technology Center 48 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.4.1 Description of WriteSDO [FB105]

The WriteSDO FB has been revised to provide more performance.

Input Parameters:

Name Data type Description

REQ Bool Start request:
- REQ is only relevant when the FB is idle
(it does not process a command)
- idle state and REQ = TRUE
starts the requested SDO write
command
ID HW_IO Hardware address for the module. Can be
read in TIA Portal.
SLOT Byte Defines which SDO channel is used.

This parameter has to be unique for each of

the SDO requests running simultaneously.

Valid values: 0 – 7

Note:
This slot defines a SDO channel and must
not be confused with the physical slot of the
module
NODE Int Node-ID of the CANopen module where
SDO write is to be performed.

Valid values: 0 - 127

Note:
Node-ID 0 always addresses the CM
module even when the CM module has
another Node-ID
INDEX Word index of the object to be written
SUB Byte subindex of the object to be written
DATA "SDO_WriteData" Data area where to get the data to be
written
DATASIZE UInt Number of bytes to be written.

Copyright HMS Technology Center 49 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Output Parameters:

Name Data type Description

BUSY Bool BUSY turns TRUE and stays TRUE until the
request is finished, then it returns to FALSE.

Note:
REQ = FALSE in idle state:
=> BUSY = FALSE
=> RET =0
=> SIZE =0
RET UInt Error code
see description of RET in chapter 8.1.3 SDO
Read/Write

Available when BUSY turns FALSE

Modifications of the revised WriteSDO FB:

 input DB has been removed
 PEEK that had to be used to copy the data to be written
consumes a lot of time
 each parallel processed SDO read command needs its own DB
 input DATA has been added
 DATA replaces the input DB
 Note:
MOVE_BLK_VARIANT cannot be used because this function is
not supported by PLCs with an older version than V4.0
 the data can be copied by MOVE_BLK which is much more faster
than the use of PEEK
 "SDO_WriteData" is defined in PLC data types
SDO_WriteData Array[1..n] of Byte

note:
 "SDO_WriteData" must be a byte array
 The customer can only vary n to adjust the byte size to its
application
 The project must be compiled when the size of
“SDO_WriteData" has been changed

Copyright HMS Technology Center 50 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

Definition of "SDO_WriteData" by the demo:

 SDO_WriteData Array[1.."cSDOWrite_MaxDataSize"] of Byte
 "cSDOWrite_MaxDataSize"
is defined in PLC tags: User constants

5.4.2 Structure: "Ctrl_CM_CANopen".WriteSDO

This structure holds all information to run a SDO write command.
The SDO write demo is based on this structure.

Description of the structure WriteSDO:

Name Data type Description

fREQ Bool flag controls REQ input of WriteSDO FB
HW_ID HW_IO hardware identifier of the accessed CM
module in TIA Portal
bSLOT Byte selected SLOT (SDO channel)
iNODE Int CANopen node id of the accessed device
wINDEX Word index of the object dictionary
bSUB Byte subindex of the object dictionary
uiSize UInt number of data bytes to be written
fBusy Bool status of a requested SDO write command:
=> value of output BUSY of WriteSDO FB
uiRet UInt result of a processed SDO write command:
=> value of output RET of WriteSDO FB
Data "SDO_WriteData" data area where to get the data to be written

Copyright HMS Technology Center 51 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

5.4.3 SDOWrite_Request [FC5]

This function
 checks if a new SDO write command shall be processed
 initializes the parameters of the SDO command
 enters the data in the data area
 requests the processing of the initialized SDO write command

Restriction of the CANopen demo:

 function is not called when there is a running SDO write command
because
 the CANopen demo shows how to run one SDO write command
 the CANopen demo is not an example for parallel processed SDO
write commands

Note:
 the purpose of this function is to explain how to initialize the inputs of
WriteSDO [FB105] to run a SDO write command

Description of the demo function:

 lines 174 – 179
 the demo does not request the processing of a SDO write
command
 the customer`s application has to decide if a SDO write command
shall be processed

 line 182:
 initialization of the hardware identifier of the accessed CM module
 line 208:
 demo uses SLOT 1 for write SDO command
 demo example clears the pre-defined error field of the CANopen device
with the of the CANopen node id 2
 line 213 : accessed CANopen device
 line 218 : index of the object to be written
 line 223 : subindex of the object to be written
 line 235
demo enters the data that shall be written in
"Ctrl_CM_CANopen".WriteSDO.Data.SDO_WriteData[]
 order of transmission:
first transmitted data byte (LSB):
"Ctrl_CM_CANopen".WriteSDO.Data.SDO_WriteData[1]
…
last transmitted data byte (MSB):
"Ctrl_CM_CANopen".WriteSDO.Data.SDO_WriteData[number bytes]

Copyright HMS Technology Center 52 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 SDO commands

 line 240
 demo updates the number of data bytes to be written
 line 246
 demo requests the processing of the initialized SDO write
command

Parameters of SDOWrite_Request [FC5]:

 Input:
 HW_ID hardware identifier of the accessed CM
CANopen in TIA Portal
data type: HW_IO
 Output:
 RUN_SDOWRITE flag indicates if a SDO write command
shall be processed
TRUE: process the initialized SDO
write command
FALSE: no SDO write command shall
be processed

5.4.4 SDOWrite_InterpretResult [FC8]

This function is called when the requested SDO write command has been
processed.

Function
 checks if the requested command has been processed successfully
 the command has been processed successfully
line: 26 - 27
 an error has been detected:
lines 29 – 34:
analysis and reaction must be coded by the customer

 clears the current SDO write request

 line 41

Parameters of SDORead_InterpretReadData [FC7]:

 Input:
 uiRET result of the processed SDO write command
=> value of output RET of WriteSDO [FB104]
 InOut:
 ClearReq clears the current SDO write request

Copyright HMS Technology Center 53 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6 Get Node & Network Status

The demo also provides an example how “Get Node & Network Status” can be
processed.

Program group "Get Node & Network Status" provides all functionality to
process a Get Node & Network Status command.
The processing of a “Get Node & Network Status” command is controlled by
the structure:
"Ctrl_CM_CANopen".GetNNStatus

“Get Node & Network Status” command is processed and analysed by

GetNodeNetworkStatus [FC18]
that is called in Network 1 of OB1.

6.1.1 Structure: "Ctrl_CM_CANopen".GetNNStatus

This structure holds all information to run a “Get Node & Network Status”
command.
The demo is based on this structure.

Description of the structure GetNNStatus:

Name Data type Description

fREQ Bool TRUE: run “Get Node & Network
Status” command
FALSE: do not run “Get Node &
Network Status” command
abData Array[0..131] of Byte data area holds all diagnostic information

hint:
do not change the data type of abData
 it covers all data

 GetNodeNetworkStatus [FC18]
is based on this definition:
see local Constant:
#cByteSizeRecord

 AnalyseNodeNetworkStatus [FC14]
is based on this definition

Copyright HMS Technology Center 54 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6.1.2 GetNodeNetworkStatus [FC18]

This function
 checks if a “Get Node & Network Status” command shall be processed
see: line 34 - 38
 processes the requested command
see: line 43 - 52
 checks if the command has been processed
see: line 56 - 59
 checks if the command has been successfully processed
see: line 65 - 76
 calls AnalyseNodeNetworkStatus [FC14] when the command has been
processed and the diagnostic data are valid
see: line 69
 clears the request: run “Get Node & Network Status” command
see: line 88

Parameters of GetNodeNetworkStatus [FC18]:

 Input:
 HW_ID hardware identifier of the accessed CM CANopen in
TIA Portal
data type: HW_IO
 InOut:
 REQ TRUE: run “Get Node & Network Status”

hint:
set flag shall not be reset by the application

REQ is automatically set to FALSE by the

function when the command has been
processed

Copyright HMS Technology Center 55 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6.1.3 AnalyseNodeNetworkStatus [FC14]

This function
 is called by GetNodeNetworkStatus [FC18] when the command has been
processed and the diagnostic data are valid
 analyses the uploaded diagnostic information
 valid data bytes:
"Ctrl_CM_CANopen".GetNNStatus.abData[0]
…
"Ctrl_CM_CANopen".GetNNStatus.abData[#uiLen - 1]
 reaction must be coded by the customer
 provides a detailed description of “Get Node & Network Status”
discusses the possible reasons of errors
lists where to get additional information
proposes reactions to errors
see: line 18 – 380

see also chapter 6.1.4

 provides a rough demo how to analyse the data

see: line 385 - 455

Parameters of GetNodeNetworkStatus [FC18]:

 Input:
 uiLen byte size of the uploaded diagnostics

Copyright HMS Technology Center 56 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6.1.4 Discussion of the diagnostic information

The discussion of the diagnostic information
 provides more details than the user manual
 lists the events that cause a specific diagnostic event
 lists diagnostic objects of the CM module that provide more / additional
information

6.1.4.1 General hints

“General hints” clarifies some terms that are used to discuss the diagnostic
information.

Notation: slave device / unexpected device

 slave device or slave:
 device has been entered as a CANopen slave in the Project
Explorer of the CM CANopen Configuration Studio
 Bit 0 of its NMT Slave configuration is set

note:
 each slave device is marked in the diagnostic object 5001h

 unexpected device:
 device has not been entered as a CANopen slave in the Project
Explorer of the CM CANopen Configuration Studio
 Bit 0 of its NMT Slave configuration is not set

note:
 unexpected devices are not marked in the diagnostic object 5001h
 a present unexpected device is marked in the diagnostic object
5003h

Copyright HMS Technology Center 57 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Note: Boot slave process

 The boot slave process is used by a CANopen Manager mode
1. to check if a device is present ( slave device and unexpected
device )
2. to check the identity of the slave device
see below: Note: identity error
3. to restore the default configuration
condition:
- Bit 7of its NMT Slave configuration must be set
- the value of its Restore Configuration must not be 0
4. to configure the slave with its generated configuration provided
by the object
1F22h, subindex CANopen node id of the booted slave
see chapter 7.2.2 of the user manual
see below: Note: configuration of the slave has failed
5. to start the error control service for the slave
6. to update the CANopen NMT state of the slave
hint:
the slave is set to operational if all subsequent conditions are true
- the CM module is allowed to start the slaves:
Bit 3 of the NMT Startup must not be set
- the CM module is operational or Bit 2 of the NMT Startup is
not set
- all mandatory slaves have been booted successfully

 CANopen network initialization

the CM module processes at least one boot slave process for each
CANopen node id
 Repetition of a failed boot slave process
 slave device:
failed boot slave process is only repeated if Bit 2 of its NMT
Slave configuration is set
otherwise it must be requested by the PLC:
see 1F25h, subindex CANopen node id of the booted slave
see chapter 7.2.2 of the user manual
 unexpected device:
the boot slave process of an unexpected device is repeated
until the unexpected device has been removed from the
CANopen network or when it has been configured as a slave

Copyright HMS Technology Center 58 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Note: identity error

 The CM module only checks the identity objects of a slave that has been
selected for the slave in the CM CANopen Configuration Studio.

see CM CANopen Configuration Studio:

Network Management Configuration
Slave Assignment
Device Type, Vendor-ID, Product Code, Revision
Number, Serial Number of the slave

 An identity object is checked if it has been selected and its value is not
equal to 0 (don`t care).
 Device Type, Vendor-ID, Product Code and Serial Number:
must match exactly
 Revision Number:
 major Revision Number (bits 16 - 31) must match exactly
 read minor revision number (bits 0 - 15) must be greater than or
equal to the expected on
 index 500Ah: identity error bit list
lists the slaves that identity do not match

Copyright HMS Technology Center 59 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Note: configuration of the slave has failed

 CM CANopen Configuration Studio generates an individual configuration
for each slave device that has been entered in the “Project Explorer”
 The generated configuration only contains the configuration that differs
from the default configuration of the EDS
 The generated configuration of a slave is stored in
1F22h, subindex CANopen node id of the slave
on the CM module
 Each slave device is configured with its configuration by its boot slave
process:
see above: Note: Boot slave process
 the configuration of a slave will fail
 if the configuration
- contains an object that is not supported by the slave
- contains an object that is read only
- contains a value that is out of range
- maps on object that is not mappable

these errors are caused by an EDS file that does not describe the
real device correctly and completely

action:
- ask the manufacturer for the correct EDS

 if the slave has not been implemented according the CANopen

specification

action:
- ask the manufacturer for a FW update

 realistic solution:
 manufacturer does not provide a revised EDS / FW update
 the EDS has to be revised by the customer:
analyse the CAN bus traffic and adjust the EDS step by step

Copyright HMS Technology Center 60 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Note: slave is configured by its specific configuration tool

 EDS:
 EDS file must be adjusted so it describes its individual
configuration as the default configuration

 Bit 7 of its NMT Slave configuration

 must not be set
 set bit requires the restoring of the default configuration which will
delete the individual configuration

Note: error control event

Error control event covers
 failure of the boot slave process of a slave
possible reasons:
 slave is missing
 identity error of a slave
 the configuration of the slave has failed
 erroneous behavior of the slave
 heartbeat timeout
slave has not transmitted its heartbeat within the configured heartbeat
consumer time

condition:
slave must be entered in the consumer heartbeat list with a
consumer heartbeat time > 0

see CM CANopen Configuration Studio:

Error Control Configuration
Consumer Time list of the CM module

 lifetime timeout
slave is guarded and has not responded within its lifetime

condition:
slave must be guarded by the CM module
Guard Time · Retry Factor > 0

see CM CANopen Configuration Studio:

Error Control Configuration
Node Guarding
Guard Time and Retry Factor of the slave

Copyright HMS Technology Center 61 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

 heartbeat / guarding response reports another CANopen NMT state

than the expected one
e.g.:
CM module expects operational
but the slave reports pre-operational

 unexpected bootup message of a slave

 a device is present that has not been configured as slave

Note: CANopen slave mode

 the diagnostic objects 5003h – 5006h are also updated by the CM
module running in CANopen slave mode
 condition:
only devices that has been entered in the consumer heartbeat list
of the CM module with a consumer heartbeat time > 0 are
displayed in these lists
 additional condition: 5003h
the monitoring of the heartbeat of another device is started with
the first reception of the heartbeat message
 the objects 5004h – 5006h display the CANopen NMT status
(operational, pre-operational, stop) reported by the received heartbeat
messages

6.1.4.2 Get Node & Network Status: Message error

Message error must be checked first.
If message error reports an error (message error <> 0)
 analysis of the message error and reaction must be coded by the
customer
 all subsequent diagnostic data are irrelevant / invalid
 see chapter 8.1.4 of the manual
Contents of parameter RECORD: Offset: 0
 demo
"Ctrl_CM_CANopen".GetNNStatus.abData[0]

Copyright HMS Technology Center 62 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6.1.4.3 Get Node & Network Status: CANopen Module mode

If the reported operating mode is not the expected one:
 select the correct operating mode in the hardware configuration of the
CM module
 download the new hardware configuration to the PLC
 power off / on the PLC
 see chapter 8.1.4 of the manual
Contents of parameter RECORD: Offset: 3
 demo
"Ctrl_CM_CANopen".GetNNStatus.abData[3]
 note: demo
demo expects that the CM module is running as CANopen
Manager
see constant #cOperatingMode

6.1.4.4 Get Node & Network Status: Error flags (module)

This chapter discusses the single error events
 see chapter 8.1.4 of the manual
Contents of parameter RECORD: Offset: 1
 demo
"Ctrl_CM_CANopen".GetNNStatus.abData[1]

Bus off (bit 0):

 possible reasons:
 short cut of the CAN cable
 wrong mounting of the CAN connection
 the CAN network is not correctly terminated
 the CAN network must have a line topology
 the cable length is too long for the selected CAN baudrate
 the CAN baudrate selected in the module parameters of the CM
module is wrong
 a CANopen device is running with a wrong CAN baudrate

 note:
the CM module automatically retries to recover form bus off

 action:
check the above mentioned possible errors

Copyright HMS Technology Center 63 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Configuration download error (bit 1):

 the download of the CANopen configuration to the CM module has
failed:
the configuration of the CM module is invalid
 action:
download the CANopen configuration to the CM

Parameterization error (bit 2):

 the actual CANopen network does not match the configured / expected
CANopen network:
possible reasons:
 boot slave process of a slave has failed:
possible reasons:
- slave is missing
- identity error of a slave
- download of the configuration to a slave has failed
 error control event of a slave
 an unexpected device is present
 action:
 analyse the status of each CANopen node id: 1 - 127
node id 1 "Ctrl_CM_CANopen".GetNNStatus.abData[5]
…
node id 127 "Ctrl_CM_CANopen".GetNNStatus.abData[131]

note:
the status of the CM module is also displayed

NVS error (bit 3):

 the saved CANopen configuration is corrupted:
 the CM module does not communicate with the CANopen network
RUN - CANopen LED: off
ERR - CANopen LED: blinking with 1Hz

 action:
 power off / on the PLC
 fatal error log can be read by SDO: index 5500h, subindex 1
 inform HMS and provide the read fatal error log

Copyright HMS Technology Center 64 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6.1.4.5 Get Node & Network Status: Error flags (network)

This chapter discusses the single error events
 see chapter 8.1.4 of the manual
Contents of parameter RECORD: Offset: 2
 demo
"Ctrl_CM_CANopen".GetNNStatus.abData[2]

Network not ready (bit 0):

 possible reasons: CANopen Manager mode
 CM module is not operational
- network scan and initialization has not been finished yet
see also 5000h, subindex 2
- the CM module is disconnected from the CAN bus
see object 5000h, subindex 1: bit 13
- error control event of a mandatory slave
- neither the CM module nor the network will be set to
operational until each mandatory slave has been booted
successfully
- error control event of a mandatory slave when the network was
operational:
the reaction to this event depends of the configuration of the
NMT Startup in the CM CANopen Configuration Studio
 no slave is operational
- network scan and initialization has not been finished yet
see also 5000h, subindex 2
- slave(s) is (are) missing
- no slave has been booted successfully
 the CANopen state of the CM module has been changed by
command
 PLC is stopped

action:
 "CANopen Node status"  CANopen NMT status of the CM
module:
"Ctrl_CM_CANopen".GetNNStatus.abData[4]
 check bit 1: node error control event of Error flags (network)
 analyse the status of each CANopen node id: 1 - 127
node id 1 "Ctrl_CM_CANopen".GetNNStatus.abData[5]
…
node id 127 "Ctrl_CM_CANopen".GetNNStatus.abData[131]

 additional diagnostic information is provided by the objects

5xxxh
see also chapter 7.3 Manufacturer Specific Objects
Copyright HMS Technology Center 65 CM CANopen, CANopen Application, V1.0
Ravensburg GmbH
 Get Node & Network Status

 possible reasons: CANopen slave mode

 CM module is not operational
- the CANopen master has not set the CM module to operational
or has requested a not operational state
- reaction to an error event:
the reaction depends of the configuration of the error behavior
object: index 1029h:
see chapter 7.2 of the user manual

 action:
- "CANopen Node status"  CANopen NMT status of the CM
module:
"Ctrl_CM_CANopen".GetNNStatus.abData[4]
- additional diagnostic information is provided by the objects
- 5000h: subindex 1 / 2
- 50003h
- 50004h - 5006h
note:
only devices that has been entered in the consumer
heartbeat list of the CM module with a consumer
heartbeat time > 0 are displayed in these lists

see chapter 7.3 of the user manual

Copyright HMS Technology Center 66 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Node error control event (bit 1):

 possible reasons: CANopen Manager mode
 error control event of a slave device
 CM module is disconnected from the CANopen network
see object 5000h, subindex 1: bit 13

action:
 analyse the status of each CANopen node id: 1 - 127
node id 1 "Ctrl_CM_CANopen".GetNNStatus.abData[5]
…
node id 127 "Ctrl_CM_CANopen".GetNNStatus.abData[131]

note:
the status of the CM module is also displayed

additional diagnostic information is provided by the objects

5xxxh
see also chapter 7.3 Manufacturer Specific Objects

 possible reasons: CANopen slave mode

 timeout of the reception of the heartbeat of another CANopen
device that is to be monitored:
see index 1016h described in chapter 7.2 of the user
manual
 CM module is disconnected from the CANopen network
see object 5000h, subindex 1: bit 13

action:
 additional diagnostic information is provided by the objects
- object 5003h
- object 5000h, subindex 1: bit 13

Guarding error (bit 2):

This bit is only relevant for the CANopen slave mode.
It reports a timeout of the guarding by the CANopen master
 condition:
 the master had started to guard the CM module
 lifetime > 0
lifetime = life time factor (index 100Dh) · guard time (index 100C h)
 guarding request of the CANopen master has not been received within
the configured lifetime

Copyright HMS Technology Center 67 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

6.1.4.6 Get Node & Network Status: CANopen Node Status

CANopen Node Status informs about the current CANopen NMT status of the
CM module
 see chapter 8.1.4 of the manual
Contents of parameter RECORD: Offset: 4
 demo
"Ctrl_CM_CANopen".GetNNStatus.abData[4]

Node NMT status:

 NMT State Operational
the CM module is operational and can exchange process image
data with PDOs
 NMT State Unknown
CM module has not finished its CANopen initialization after power
on
 Reset Node / Reset Communication
the CM module is processing a reset command that has been
requested by
the PLC (CANopen manager / slave mode)
or by the CANopen master (CANopen slave mode)
 NMT Pre-operational
possible reasons:
 CANopen Manager mode:
- the CANopen network initialization process is running
- the CM module is not allowed to set itself / the network to
operational because a mandatory slave has not been booted
successfully
- the CM module has been set to pre-operational by the PLC
 CANopen slave mode:
- the CANopen master has not set the CM module to operational
yet
- the CANopen master has set the CM module to preoperational
- the CM module has entered this state due to an error
see index 1029h
described in chapter 7.2 of the user manual

Copyright HMS Technology Center 68 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

 NMT State Stopped

possible reasons:
 CANopen Manager mode:
- the CM module has set the CANopen network and itself to
stopped due to an error control event of a mandatory slave
condition:
- network initialization process has been finished
- set Bit 6 of the NMT Startup configuration
- the CM module has been set to stopped by the PLC
 CANopen slave mode:
- the CANopen master has set the CM module to stopped
- the CM module has entered this state due to an error
see index 1029h
described in chapter 7.2 of the user manual

additional diagnostic information are provided by

 see Error flags (network)
 object 5000h, subindex 1 - 4

6.1.4.7 Get Node & Network Status: Network status

Network status provides individual diagnostic and CANopen NMT status
information for each CANopen node id: node id 1 - 127.

The CM module is also displayed.

Network status is only available in CANopen Manager mode.

 see chapter 8.1.4 of the manual
Contents of parameter RECORD: Offset: 5
 demo
"Ctrl_CM_CANopen".GetNNStatus.abData[5 - 131]
 diagnostic and CANopen NMT status of node id i
"Ctrl_CM_CANopen".GetNNStatus.abData[4 + i]

Copyright HMS Technology Center 69 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Node State: bits 0 – 3

 NMT State Unknown
possible reasons
 the CANopen network initialization is running and the CM module
has not tried to boot the slave yet
see also object 5000h, subindex 2

 the slave device has been booted successfully but it is not

controlled by the CM module:
neither by consuming its heartbeat nor by guarding
see also object 5002h

 the slave device is present but its boot slave process fails

see Bit 4: Configuration Error bit

see also object 5003h
additional: object 5009h, 500Ah

note:
failed boot slave process is repeated when
Bit 2 of the slave`s NMT Slave configuration
is set
and the NMT status of the CM module is not stopped

 the slave is present but it is not booted automatically

the CM module does not automatically starts a boot slave process

of a slave device
- after an error control event of the slave
- after a hot swap of the slave
- belated connection of the slave
if Bit 2 of the slave`s NMT Slave configuration is not set.

its boot slave process must be requested by

1F25h, subindex slave`s node id
see chapter 7.2 of the user manual

 unexpected device is not present

Copyright HMS Technology Center 70 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

 NMT State Stopped / Operational / Pre-operational

condition:
 slave device has been booted successfully
 slave device is controlled by the CM module
either by consuming its heartbeat or by guarding

note:
 only a slave that has been booted successfully can be set to
operational

 CANopen Device missing

possible reasons:
 slave device is missing / not connected

hint:
missing can be also caused by a reset node command that is
written to the slave due to
- heartbeat timeout / guarding timeout
- heartbeat / guarding response has reported another
CANopen NMT state than the expected one
- the configuration of the slave has failed
and the slave has not finished its CANopen initialization before
the CM module has started to boot the slave
the slave device should be detected as present after some retries
of the boot slave process

 CM module is disconnected from the CANopen network

see also object 5000h, subindex 1: ALONE (bit 13)

Copyright HMS Technology Center 71 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Get Node & Network Status

Configuration Error bit (bit 4):

 possible reasons:
 identity error
see also the diagnostic object 500Ah
 concise DCF error
the configuration of the slave has failed
see also the diagnostic object 5009h
 hint:
the boot slave process of a slave can also fail although neither an
identity error nor a concise DCF error has been detected.
 e.g.:
slave device has to restore its default configuration
but it does not support the object 1011h
and slave reports another error as “Object does not exist in the
object dictionary” or “Sub-index does not exist”
 such errors are not indicated by bit 4
 but the slave device is marked in the diagnostic object 5003h
 such errors can be only solved by the analysis of the CAN trace

Node mandatory bit (bit 5):

 device is configured as mandatory or optional slave

Unexpected device (bit 7):

 set bit: device is present but it is not configured as a slave in the CM
CANopen Configuration Studio

Copyright HMS Technology Center 72 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 CM CANopen Configuration Studio

7 CM CANopen Configuration Studio

This chapter clarifies some misunderstandings and emphasizes an overlooked
feature of the Configuration Studio.

7.1 Exchange of process image data

This chapter clarifies some misunderstandings of the exchange of the process
image between the CM CANopen and the CANopen network.

Exchanged process image data:

 only the application objects that are selected in “Application Objects” are
exchanged between the CM CANopen and the CANopen network

Transmission type of a PDO:

 the transmission type of a PDO depends of the transmission type of its
mapped objects
 the transmission type of an application object is individually selected in
“Application Objects”

 the generated PDO configuration is based on the selected application

objects and their individual transmission type
 only application objects with the same transmission type are mapped
in a PDO

Copyright HMS Technology Center 73 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 CM CANopen Configuration Studio

Hint: change of the transmission type of a PDO in “PDO Mapping

Parameters”
 PDO is not locked
 the modified transmission type is ignored
 PDO is locked
 the transmission type of its mapped objects in “Application Objects”
differs from the transmission type of the PDO
 the locked PDO is assumed to be used to transfer process data
between slaves and not between the CM CANopen and the slave
 calculate configuration has to look for an alternative configuration for
the process data exchange between the CM CANopen and the slave

Hint: Inhibit Time (100µs), Event Timer (ms), Transmission Rate

 Inhibit Time (100µs), Event Timer (ms), Transmission Rate are additional
attributes of a PDO to control its transmission rate
 these parameters are configurable in “PDO Mapping Parameters”

Hint: change of the CAN-ID of a PDO in “PDO Mapping Parameters”

 PDO is not locked
 the modified CAN-ID is ignored
 PDO is locked
 work around for all version 2.1.xx of the Configuration Studio
 close the Configuration Studio
 start the Configuration Studio
 calculate configuration

otherwise the CAN-ID of the corresponding PDO of the CM

CANopen is not updated
 CM CANopen and the slave will not exchange process data with
this PDO

Hint: Process Image Size (OUT) (byte), Process Image Size (IN) (byte)
 CM CANopen configuration Studio will use the values entered here to
check if the byte size of the selected application objects exceeds the
entered range
 the actual maximum byte size of the process image input / output is set
in the hardware configuration of the CM CANopen in TIA Portal
 Process Image Size (OUT) (byte) sets the limit for: Allocated process
Image Size IN
 Process Image Size (IN) (byte) sets the limit for: Allocated process
Image Size OUT

Copyright HMS Technology Center 74 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 CM CANopen Configuration Studio

7.2 “Device Parameters” tool window

The “Device Parameters” tool window provides access to parameter objects of
the CANopen device that is currently selected in the “Project Explorer” tool
window.
Parameters that may require specific initialization with an alternative parameter
value instead of the default value after power on / reset of the slave can be
configured here:
 the slave will be also configured with these modified values by the CM
CANopen
 the PLC program must not configure these parameters

CM CANopen Configuration Studio generates an individual configuration for

each slave device that has been entered in the “Project Explorer”:
 these slave configurations are also downloaded to and stored on the CM
CANopen
 the CM CANopen will automatically configure each slave with its specific
stored configuration
 during the CANopen network initialization
 after an error control event
 condition:
Bit 2 of its NMT Slave configuration must be set
 after hot swap of the device / exchange of a faulty device
 condition:
Bit 2 of its NMT Slave configuration must be set

The slave specific configuration contains

 the configuration that differs from the default configuration in its EDS
 the configuration of the PDOs
 the configuration of the communication parameters
 valid / not valid
 CAN-ID
 transmission type
 inhibit time (if supported)
 event timer (if supported)
 the configuration of the mapping
 number mapped objects
 mapped objects
 the configuration of the sync objects (if supported)
 sync producer / consumer
 sync cycle time
 the configuration of the heartbeat producer time (if supported)
 the configuration of the heartbeat consumer list (if supported)
 the configuration of the guard time / life time factor (if supported)
Copyright HMS Technology Center 75 CM CANopen, CANopen Application, V1.0
Ravensburg GmbH
 CM CANopen Configuration Studio

 the configuration of additional objects whose configuration has been

changed in “Device Parameters”

example for a modified value in “Device Parameters”:

“Analogue input global interrupt enable” ( object 6423h ) is disabled by

default but it should be enabled before the slave enters operational

Copyright HMS Technology Center 76 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Status LEDs

8 Status LEDs
This chapter describes the single LED patterns to avoid misinterpretation.

Hint: Double Flash

 double flash covers much more events than “a nodeguard event or a
heartbeat event has occurred”
 CANopen slave mode:
 heartbeat timeout of a device whose heartbeat is monitored
 timeout of being guarded by the CANopen master
 CANopen Manager mode:
double flash indicates the error control events
 failure of the boot slave process of a slave
- slave is missing
- identity error of a slave
- the configuration of the slave has failed
 nodeguard event or a heartbeat event
- timeout
- heartbeat / guarding response reports another CANopen NMT
state than the expected one
e.g.:
CM module expects operational
but the slave reports pre-operational
 unexpected / unforced bootup message of a slave
 a device is present that has not been configured as slave
 the CM module is disconnected from the CANopen network

Note: priority of the indicated error events

 the highest prior error is indicated if there are several errors
 order of priority

Priority Indication Error event

highest 1 Hz fatal error
On bus off
Triple flash sync timeout
decreasing
Double flash error control event
priority
Single flash warning limit reached in CAN
controller
lowest Blinking general configuration error
CANopen initialization of the CM
CANopen was not successful

Copyright HMS Technology Center 77 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH
 Status LEDs

8.1 Indicator states and flash rates

Copyright HMS Technology Center 78 CM CANopen, CANopen Application, V1.0

Ravensburg GmbH