Can in Automation (Cia) E. V.: Part 1: General Definitions
Can in Automation (Cia) E. V.: Part 1: General Definitions
Can in Automation (Cia) E. V.: Part 1: General Definitions
Version: 2.0.0
02 February 2011
HISTORY
CAN in AUTOMATION (CiA) calls attention to the possibility that some of the elements of this
CiA specification may be subject of patent rights. CiA shall not be responsible for identifying
any or all such patent rights.
Because this specification is licensed free of charge, there is no warranty for this
specification, to the extent permitted by applicable law. Except when otherwise stated in
writing the copyright holder and/or other parties provide this specification “as is” without
warranty of any kind, either expressed or implied, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose. The entire risk as to the
correctness and completeness of the specification is with you. Should this specification prove
failures, you assume the cost of all necessary servicing, repair or correction.
Trademarks
CANopen® and CiA® are registered community trademarks of CAN in Automation. The use is
restricted for CiA members or owners of CANopen vendor ID. More detailed terms for the use
are available from CiA.
© CiA 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm,
without permission in writing from CiA at the address below.
CAN in Automation e. V.
Kontumazgarten 3
DE - 90429 Nuremberg, Germany
Tel.: +49-911-928819-0
Fax: +49-911-928819-79
Url: www.can-cia.org
Email: headquarters@can-cia.org
CONTENTS
1 Scope ............................................................................................................................... 4
2 Normative references........................................................................................................ 4
3 Definitions, acronyms, and abbreviations .......................................................................... 4
3.1 General ................................................................................................................... 4
3.2 Acronyms ................................................................................................................ 4
3.3 Abbreviations........................................................................................................... 4
4 General architecture ......................................................................................................... 5
4.1 Overview ................................................................................................................. 5
4.2 Virtual device descriptions ....................................................................................... 5
4.2.1 General ....................................................................................................... 5
4.2.2 Call controller .............................................................................................. 5
4.2.3 Input panel unit............................................................................................ 6
4.2.4 Output panel unit ......................................................................................... 6
4.2.5 Car door controller....................................................................................... 6
4.2.6 Car door unit ............................................................................................... 6
4.2.7 Light barrier unit .......................................................................................... 6
4.2.8 Car drive controller ...................................................................................... 6
4.2.9 Car drive unit............................................................................................... 6
4.2.10 Car position unit .......................................................................................... 7
4.2.11 Load-measuring unit .................................................................................... 7
4.2.12 Remote data transmission unit .................................................................... 7
4.3 Single- and multiple-shaft lift control systems .......................................................... 7
5 Physical layer ................................................................................................................. 11
5.1 General ................................................................................................................. 11
5.2 Bit rate .................................................................................................................. 11
5.3 Bus topology.......................................................................................................... 11
5.4 Bus cable .............................................................................................................. 11
5.5 Bus connector ....................................................................................................... 11
6 Node-ID assignment ....................................................................................................... 11
6.1 General ................................................................................................................. 11
6.2 Recommendation for shaft lift control networks ...................................................... 11
6.3 Recommendations for the multiple-shaft controller network ................................... 12
7 Error handling ................................................................................................................. 13
7.1 Principle ................................................................................................................ 13
7.2 Error behavior........................................................................................................ 13
7.3 Emergency messages............................................................................................ 13
7.4 Additional emergency error code meanings ........................................................... 13
8 Character encoding......................................................................................................... 14
8.1 General ................................................................................................................. 14
8.2 Encoding of special characters .............................................................................. 14
8.3 Encodings codes to control the service menu (input) ............................................. 14
8.4 Requirements on VT52 escape sequences (output) ............................................... 14
1 Scope
This set of CANopen application profile specifications describes the CANopen Lift control
network system. It specifies the CANopen communication interfaces and the application
functionality of several functional elements (virtual devices).
Besides some general definitions such as general virtual device descriptions, this part
specifies the CAN physical layer as well as the error handling. Additionally some network
architecture examples are given.
2 Normative references
/CiA301/ CiA 301, CANopen application layer and communication profile
/CiA302/ CiA 302 (all parts), Additional CANopen application layer functions
/CiA305/ CiA 305, Layer setting services (LSS)
/CiA303-1/ CiA 303-1, Cabling and connector pin assignment
/CiA303-2/ CiA 303-2, Representation of SI units and prefixes
/ISO8859-15/ ISO/IEC 8859-15, Information technology – 8-bit single-byte coded graphic
character sets – Part 15: Latin alphabet No. 9
/ISO11898-2/ ISO 11898-2, Road vehicles – Controller area network (CAN) – Part 2:
High-speed medium access unit
3.1 General
The definitions, acronyms, and abbreviation given in /CiA301/ apply for this specification, too.
3.2 Acronyms
Acc. Access
Cat. Category
const constant
ro read-only
rw read/write
4 General architecture
4.1 Overview
This application profile specification describes the virtual devices of lift control systems. The
virtual controllers (e.g. call, car door, and car drive controller) perform dedicated control
functions of the lift application. In a lift application, all controller functions may be
implemented in one CANopen device. In other applications, the controller functions are
implemented in different CANopen devices. The virtual units (e.g. input and output panels, car
door, light barrier, car position, car drive, load-measuring) are implemented each in single
CANopen devices or combined in one or more CANopen devices. This flexible implementation
options allow the use of this application profile in simple as well as sophisticated lift
applications.
The virtual interfaces are implemented as CANopen interfaces or as CANopen device internal
interfaces, if the virtual devices reside in the same CANopen device. If the virtual interfaces
between virtual devices are implemented as CANopen interfaces they use SDO or PDO
services to read or write application objects.
Each virtual device supports a set of dedicated mandatory and optional application objects.
Most of the application objects are mapped into pre-defined PDOs. If an implemented
application object is not mapped into one of the pre-defined PDOs, other CANopen devices
may access them by means of SDO. The CSDOs, which corresponds to the Default SSDO,
shall be implemented always in the call controller. CANopen devices compliant to this
application profile without call controller functionality shall not implement any CSDO that
relates to Default SSDO. It is recommended to implement in the call controller an SDO
manager compliant to /CiA302-5/, if an external tool for configuration or trouble-shooting
purposes is used.
4.2.1 General
Every virtual device represents specific functional elements. The following brief descriptions
give an overview on the functionality of the different virtual devices. The supported application
objects and PDOs are summarized in part 2 of this application profile. The detailed PDO
interfaces are specified in part 3 of this application profile. The detailed application objects
are specified in part 4 of this application profile.
The VD call controller receives all call requests from the VD input panels, and transmits the
corresponding acknowledgements to the VD output panels. In addition, the call controller
sends commands to the VD car drive controller to move the car and the VD car door controller
to open and close the doors. When the call controller, the car drive controller, and the car
door controller are implemented on the same CANopen device, the communication between
these VDs is handled locally.
The call controller shall provide NMT master capability. If several CANopen devices with call
controller functionality are installed in one CANopen network, it is necessary that all of them
support the NMT “flying” master function.
The VD input panel unit is installed as in-car call panel or as floor call panel or as general
input device (e.g. key-switch or fire-alarm). The input panel transmits user requests to the VD
call controller including access requests.
The VD output panel unit is installed as in-car display panel or as floor display panel or as
general output device (e.g. announcement unit). The output panel is a display device that
shows car position and/or car moving direction. Additionally, it announces acoustically the
incoming car. It also receives the acknowledgements for the call requests.
The VD car door controller transmits commands (e.g. open and close) to the VD car door unit
and receives status information from the VD car door unit and the VD light barrier unit.
The VD car door unit opens and closes the car door(s). It receives the commands from the VD
car door controller and provides its status to the VD car door controller. Theoretically there
may be four doors installed in each car. However, only for three doors are TPDOs pre-defined
that contain status information.
The VD light barrier unit detects subjects and objects entering the protected area of the car
door unit and sends this information to the VD car door controller.
The VD car drive controller transmits commands to the VD car drive unit, on request from the
VD call controller. It receives status information from the VD car drive unit and the VD load-
measuring unit. If the profile position mode is used, the VD car drive controller needs
additionally status information from the VD car position unit.
The VD car drive unit moves the car upwards and downwards. It receives the motion
commands from the VD car drive controller. It is based on the CANopen profile for drives and
motion control as specified in /CiA402-2/.
NOTE There are some additional objects necessary for lift applications that are not specified in /CiA402-2/). If
there is no absolute encoder available, the target velocity (6430 h ) shall be provided to the car drive unit using the
Profile Velocity Mode; if there is an absolute encoder available, the target position (6420 h ) shall be provided to the
car drive unit using the Profile Position Mode.
The operation mode is selected by the modes of operation (6403 h ). In case of velocity-
controlled drives the Profile Velocity Mode shall be used. The objects for the velocity profile
are stored in the drive unit and may be configured by the drive controller. Due to safety
reasons, configuration shall not be possible in Operation Enable state of the VD car drive unit.
The car drive unit state machine is controlled by the controlword (6400 h). Drive-specific
functions such as motor relays are operated locally in the drive unit. Motion is determined by
a target velocity unequal 0. Direction is indicated by the sign of target velocity; positive values
shall indicate upward motion of the car. Sense of rotation depends on mounting position.
Depending on the given target velocity and the velocity profile curve parameters, the drive
unit calculates the control effort (6406 h ). Reaching the target floor-switch the controller shall
give the end velocity (6424 h) as new target velocity. Giving a target velocity of 0 shall
6 CiA 2011 – All rights reserved
Application profile for lift control systems – Part 1: General definitions
th
terminate the drive. The drive unit shall indicate reaching the target velocity in the 10 bit of
the statusword (6401 h ).
In case of position-controlled drives the Profile Position Mode shall be used. To configure the
position profile curve the same parameters as for the velocity profile curve are used. After
setting a new position, the drive unit calculates the curve and starts motion. During motion the
drive controller may change target position. If the control_effort allows stopping at the new
th
target position, this shall be indicated in the 12 bit of the statusword. If the drive cannot stop
at the new target position, the drive unit shall move to the previous target position. Reaching
th
a target position shall be indicated in the 10 bit of the statusword.
The VD car position unit measures the current position of the car and provides additionally
values like speed and acceleration. It is very similar to the function of an encoder device.
Therefore it is based on the CANopen profile for encoders as specified in CiA 406. Up to four
car position units may be used for each lift application.
The VD load-measuring unit measures the current load of the car and signals certain
situations like zero load, full load (no additional calls will be served), and overload (motion is
not allowed).
The VD remote data transmission unit provides gateway functionality for remote control and
diagnostics purposes. It uses normally SDO clients to access the other CANopen Lift devices.
In case of single-shaft lift control system, it is possible to connect all necessary devices in
one single CANopen network (see example in Figure 1). It is also possible to use a parallel
dual CANopen network architecture with a centralized controller acting as a PDO bridge (see
example in Figure 2). Another option is to cascade CANopen networks (see example in Figure
3); the network connecting devices may provide SDO router and/or PDO bridge functionality
(PDO mapping is not changed, CAN-IDs are subject of change). In addition, it may provide
PDO gateway functionality (PDO mapping is changed).
Figure 3 – Parallel network with cascaded network for a single-shaft lift control system
Theoretically it is possible to use for a multi-shaft lift control system just one CANopen
network (see example in Figure 4). Due to busload and network length requirements, those
systems are normally realized by means of several CANopen network segments (see example
in Figure 5). If PDO gateways are used, all single-shaft lift control networks may be
implemented as lift application 1 (see example in Figure 6).
5 Physical layer
5.1 General
Automatic bit rate detection may be supported. The default bit rate shall be 250 kbit/s, the bit
rate of 125 kbit/s shall be supported, too. Other bit rates as defined in /CiA301/ may be
supported. The bit timing shall be as defined in /CiA301/.
The setting method of the bit rate is manufacturer-specific. It is not recommended to set the
bit time by means of SDO write access.
No specific bus topology is specified. The network may be segmented and/or cascaded.
No specific bus connector is specified. It is recommended to use 9-pin D-sub, RJ45, or open-
style connector. If other connectors are used, it is recommended to apply the pin assignments
as given in /CiA303-1/.
6 Node-ID assignment
6.1 General
The node-ID assignment method is not in the scope of this specification. However, it is not
recommended to set the node-ID by means of SDO write access.
Table 1 shows the recommendation for the shaft lift network node-ID assignment. If a
CANopen device implements several VDs, it is recommended to assign the lowest node-ID.
13 Load-measuring unit
14 to 15 reserved
Table 2 shows the recommendation for the multiple-shaft controller network node-ID
assignment. If a CANopen device implements several VDs, it is recommended to assign the
lowest node-ID.
120 to reserved
124
125 used as floor I/O panel default node-ID (NOTE 2)
126 used for boot-loader (NOTE 2)
127 used for CANopen tool (NOTE 2)
7 Error handling
7.1 Principle
Emergency messages are triggered by internal errors in the physical device and they are
assigned to high priority to ensure that they get access to the bus without latency. By default,
the Emergency messages contain the error field with pre-defined error numbers and
additional information. For further definitions see /CiA301/.
If a serious device failure is detected the physical device shall enter by default autonomously
the NMT pre-operational state. If object 1029 h is implemented, the physical device can be
configured to enter alternatively the NMT stopped state or remain in the current NMT state in
case of a device failure. Device failures shall include the following communication errors:
Devices compliant to this specification may use additional error codes, as specified in Table
3.
If the error code is FF04h , the additional bytes of the EMCY shall not be used for
manufacturer-specific purposes. The use of these bytes is reserved.
8 Character encoding
8.1 General
As the service menus of existing devices are different, no interface for the parameters is
specified. However, a standardized way of transmitting and receiving characters for a text-
based menu is recommended.
The codes compliant to /ISO8859-15/ specified in Table 4 shall be used to control the service
menu.
27 80 1B h 50 h ESC P F1 key
27 81 1B h 51 h ESC Q F2 key
27 82 1B h 52 h ESC R F3 key
27 83 1B h 53 h ESC S F4 key
ESC I Cursor up and Move up cursor, if already in first line, a new line is inserted
insert
ESC J Clear to end of Screen is cleared from the position of the cursor to the bottom
frame