Baumer GXP5W User manual

Baumer IVO GmbH & Co. KG
Dauchinger Strasse 58-62
DE-78056 Villingen-Schwenningen
Phone [phone]
Fax [phone].11 · 174.02.035/4
[email protected] Subject to technical and design modifications.
www.baumer.com Errors and omissions excepted.
Manual
Absolute Encoder with CANopen Lift Protocol
Firmaware version from 1.00

Manual_GXP5_417_Lift_EN.doc 2/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
Contents
Page
1. Introduction 3
1.1. Scope of delivery 3
1.2. Product assignment 3
2. Safety Precautions and Operating Information 4
3. CAN Bus and CANopen Communication 5
3.1. CAN bus 5
3.1.1. CAN bus properties 5
3.2. CANopen 6
3.3. CANopen in lift construction 6
3.4. CANopen communication 7
3.4.1. Communication profile 7
3.4.2. CANopen message structure 7
3.4.3. Service data communication 8
3.4.4. Process data communication 9
3.4.5. Emergency service 10
3.4.6. Network management services 11
3.4.7. Layer setting services 13
3.5. CANopen Lift encoder according to Appl. Profile DSP417 17
3.5.1. Object overview 17
3.5.2. Detailed object description 20
4. Diagnosis and Important Information 34
4.1. Error diagnosis field bus communication 34
4.2. Troubleshooting with field bus 34
4.3. Important information on sensor 35
5. Applications 36
5.1. Setting and reading objects 36
5.2. Configuration 37
5.3. Operation 38
6. Connection Assignment and Commissioning 40
6.1. Mechanical attachment 40
6.2. Electrical connection 40
6.2.1. Description of connections 40
6.2.2. Connection assignment of M12 plug 40
6.2.3. Connection assignment of D-SUB plug 41
6.3. Display elements (status display) 41

Manual_GXP5_417_Lift_EN.doc 3/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
Disclaimer of liability
The present manual was compiled with utmost care, errors and omissions reserved. For this reason
Baumer IVO GmbH & Co. KG rejects any liability for the information compiled in the present manual.
Baumer IVO nor the author will accept any liability for direct or indirect damages resulting from the use of the
present information.
At any time we should be pleased receiving your comments and proposals for further improvement of the
present document.
1. Introduction
1.1. Scope of delivery
Please check the delivery upon completeness prior to commissioning.
Depending on encoder configuration and part number delivery is including:
•Encoder
•CD with describing file and manual (also available as download in the Internet)
1.2. Product assignment
Shaft encoder
Product Product Code Device Name Eds File Product Family
GXP5W 0x28 GXP5 GXP5_417.eds Multiturn
X 700 0x28 GXP5 GXP5_417.eds Multiturn
GXP5W with the Product Code 0x28 is an absolute encoder with a CANopen interface and an implemented
application profile DSP417 (Application Profile for Lift Control Systems).
LIFT

Manual_GXP5_417_Lift_EN.doc 4/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
2. Safety Precautions and Operating Information
Additional information
•The manual is a supplement to the documentation which already exists (catalogs, product information
and assembly manuals).
•It is imperative that the manual is read before commissioning.
Proper use
•The encoder is a precision measuring device. It is used exclusively for the detection of angle positions
and rotations, and the processing and provision of the measured values as electrical output signals for
the next device. The encoder may only be used for this purpose.
Commissioning
•The encoder may only be installed and assembled by a qualified electrician.
•Observe the operating manual of the machine manufacturer.
Safety precautions
•Check all electrical connections before commissioning the system.
•If assembly, electrical connection or other work on the encoder and on the system are not carried out
properly, malfunction or failure of the encoder may result.
•The endangering of persons, damage to the system and damage to operating equipment due to the
failure or malfunction of the encoder must be prevented with suitable safety measures.
•The encoder may not be operated outside the specified limits (see additional documentation).
Failure to observe the safety precautions can lead to malfunctions, damage and injuries!
Transport and storage
•The encoder may only be transported and stored in the original packaging.
•Do not drop the encoder or subject it to major jolts or impacts.
Assembly
•Avoid impacts or shocks to the housing and shaft.
•Do not torque the housing.
•Do not produce a rigid connection between the encoder and drive shafts.
•Do not open the encoder or modify it mechanically.
The shaft, ball bearings, glass plate or electronic parts can be damaged. Safe operation is then no longer
ensured.
Electrical commissioning
•Do not modify the encoder electrically.
•Do not carry out wiring work while the encoder or system is energized.
•The electrical connection may not be connected or disconnected while energized.
•Install the entire system so that it is EMC-compliant. The installation environment and wiring affect the
EMC of the encoder. Install the encoder and the supply lines in separate locations or at a great distance
from wiring with a high interference level (frequency converters, contactors etc.).
•For consumers with high interference levels, provide a separate power supply for the encoder.
•Complete screen the encoder housing and the connection cables.
•Connect the encoder to protective ground and use shielded cables. The cable shield must be connected
to the screw cable terminal or plug. Connection of the protective ground at both ends, the housing via the
mechanical attachment, and the cable shield via devices connected downstream should be aimed for. If
problems occur with ground loops, grounding should be carried out on at least one end.
Failure to observe the above can lead to malfunctions, damage and injuries!

Manual_GXP5_417_Lift_EN.doc 5/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
3. CAN Bus and CANopen Communication
3.1. CAN bus
The CAN bus (CAN: Controller Area Network) was originally developed by Bosch and Intel for fast,
inexpensive data transmission in motor vehicle technology. Today the CAN bus is also used in industrial
automation.
The CAN bus is a field bus (the standards are defined by the association CAN in Automation (CiA)) via which
devices, actuators and sensors of different manufacturers can communicate with each other.
3.1.1. CAN bus properties
• Data rate of 1 Mbaud with a network range of up to 40 m (130 ft)
• Network connected at both ends
• Bus medium twisted-pair cables
• Real-time capability: defined maximum wait time for high-priority messages.
• Theoretically 127 nodes to a bus, however physically only 32 (due to the driver used).
• Securing of network-wide data consistency. Faulty messages are made known to all network nodes as
faulty.
• Message-oriented communication
The message is marked with an identifier. All network nodes check whether the message is relevant for
them using the identifier.
• Broadcasting, multicasting
All network nodes receive every message simultaneously, enabling synchronization.
• Multi-master capability
Every node in the field bus can send and receive data independently without being dependent on a priority
of the master. Each can begin its message if the bus is not busy. In the case of simultaneous transmission
of messages, the node with the highest priority prevails.
• Assignment of priorities to messages
The identifier specifies the priority of the message. As a result, important messages can be transmitted
quickly via the bus.
• Residual error probability
Safe-guarding methods in the network reduce the probability of an undetected, faulty data transmission to
below 10 -11. A virtually 100 % reliable transmission can be assumed.
• Operation monitoring
Localization of defective or failed stations. The CAN protocol contains an operation monitoring function of
network nodes. The operation of defective network nodes is restricted, or they are completely decoupled
from the network.
• Data transmission with a short error recovery time
Due to several error detection mechanisms, falsified messages are recognized with a high probability. If an
error is detected, then the message is automatically retransmitted.
Several network nodes are interconnected via a bus cable. Each network node can send and receive
messages. The data are transmitted serially between the network nodes.
Examples of network nodes for CAN bus devices are:
• Automation devices, e.g. PLC
• PCs
• Input/output modules
• Drive controllers
• Analysis devices, e.g. a CAN monitor
• Operating and input devices as human-machine interface (HMI)
• Sensors and actuators

Manual_GXP5_417_Lift_EN.doc 6/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
3.2. CANopen
Under the technical direction of the Steinbeis Transfer Center for Automation, the CANopen profile was
developed on the basis of the Layer 7 specification CAL (CAN Application Layer). Compared to CAL,
CANopen only contains the functions suitable for this application. CANopen therefore represents a subset of
CAL optimized for the application and enables simplified system design and the use of simplified devices.
CANopen is optimized for rapid data exchange in real-time systems.
The CAN in Automation (CiA) organization is responsible for the applicable standards of the corresponding
profiles.
CANopen enables:
• Simple access to all device and communication parameters
• Synchronization of several devices
• Automatic network configuration
• Cyclical and event-controlled process data traffic
CANopen consists of four communication objects (COB) with different properties:
• Process data objects for real-time data (PDO)
• Service data objects for parameter and program transmission (SDO)
• Network management (NMT, Heartbeat)
• Predefined objects (for synchronization, emergency message)
All device and communication parameters are structured in an object directory. An object comprises the
name of the object, data type, number of sub-indices, structure of the parameters and the address.
According to the CiA, this object directory is divided into three different parts: communication profile, device
profile and a manufacturer-specific profile (see Object directory).
3.3. CANopen in lift construction
CANopen is a standardized application for distributed, industrial automation systems based on CAN and on
the communication standard CAL. CANopen is a standard of the CAN in Automation (CiA) and already found
extremely broad acceptance shortly after it became available. In Europe CANopen can be considered the
decisive standard for the realization of industrial CAN-based system solutions.
The responsibility was turned over to the organization CAN-in-Automation, which coordinates all work on the
CANopen system worldwide. Within the CiA a special interest group (SIG) "Lift" was founded. The task of this
SIG is the checking of the existing profiles for their suitability for lift construction and their expansion or
redefinition. Within the SIG "Lift" various working groups for the individual profiles were specified.

Manual_GXP5_417_Lift_EN.doc 7/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
3.4. CANopen communication
3.4.1. Communication profile
The communication between the network nodes and the master (PC/controller) is carried out via object
directories and objects. The objects are addressed via a 16-bit index. The CANopen communication profile
DS 301 standardizes the various communication objects. Accordingly, they are divided into several groups:
• Process data objects (PDO) for the real-time transmission of process data
• Service data objects (SDO) for the write and read access to the object directory
• Objects for the synchronization and error display of CAN nodes:
SYNC object (synchronization object) for the synchronization of network nodes
EMCY object (emergency object) for the error display of a device or its periphery
• Network management (NMT) for the initialization and network control
• Layer setting services (LSS) for the configuration by means of a serial number, revision number etc. within
an
existing network
3.4.2. CANopen message structure
The first part of a message is the COB-ID (identifier).
Structure of the 11-bit COB-ID:
Function Code Node-ID
4-bit Function Code 7-bit Node-ID
The function code provides information on the type of message and the priority
The lower the COB-ID, the higher the priority of the message.
Broadcast messages:
Function Code COB-ID
NMT 0
SYNC 80h
Peer to peer messages:
Function Code COB-ID
Emergency 80h + Node-ID
PDO1 (tx)1) 17Bh+ Lift number * 10 + PosUnit
SDO (tx)1) 580h + Node-ID
SDO (rx)1) 600h + Node-ID
Heartbeat 700h + Node-ID
LSS (tx) 1) 7E4h
LSS (rx) 1) 7E5h 1): (tx) and (rx) from the
standpoint of the encoder
The node ID can be freely selected via the CANopen bus between 1 and 127 (if rotary switch = 0). The
encoders are shipped with a node ID = 1.
A change is made with the service data object 2101h or via LSS.
A CAN telegram consists of the COB-ID and up to 8 bytes of data:
COB-ID DLC Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
Xxx x xx xx xx xx xx xx xx xx
The exact telegrams will be listed in detail later.

Manual_GXP5_417_Lift_EN.doc 8/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
3.4.3. Service data communication
The service data objects comply with the CiA standards. An object can be accessed via an index and
subindex. The data can be requested or, if necessary, written to the object.
General information on the SDOs
Structure of an SDO telegram:
COB-ID DLC Command Object L Object H Subinde
x
Data 0 Data 1 Data 2 Data 3
An SDO COB-ID consists of the following:
Master -> Encoder : 600h + Node-ID
Encoder -> Master : 580h + Node-ID
DLC (data length code) designates the length of the telegram. This consists of the following:
1 byte command + 2 bytes object + 1 byte subindex + number of data bytes (0 - 4).
The command byte specifies whether data are read or set and how many data bytes are concerned:
SDO Command Description Data Length
22h Download Request Max. 4 bytes Send parameters to encoder
23h Download Request 4 bytes
2Bh Download Request 2 bytes
2Fh Download Request 1 byte
60h Download Response - Confirmation of adoption to Master
40h Upload Request - Request parameters from encoder
42h Upload Response Max. 4 bytes Parameters to Master with max. 4 bytes
43h Upload Response 4 bytes
4Bh Upload Response 2 bytes
4Fh Upload Response 1 byte
80h Abort Message - Encoder signals error code to Master
An abort message indicates an error in the CAN communication. The SDO command byte is 80h. The
object and the subindex are those of the desired object. The error code is present in byte 5 - 8.
ID DLC Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
580h + Node-
ID
8 80h Object L Object H Subinde
x
ErrByte 0 ErrByte 1 ErrByte 2 ErrByte 3
Byte 8 - 5 results in the SDO abort message (Byte 8 = MSB).
The following messages are supported:
05040001h : Command byte is not supported
06010000h : Incorrect access to an object
06010001h : Read access to Write Only
06010002h : Write access to Read Only
06020000h : Object is not supported
06090011h : Subindex is not supported
06090030h : Value outside limits
06090031h : Value too large
08000000h : General error
08000020h : Incorrect memory signature ("save")
08000021h : Data cannot be saved

Manual_GXP5_417_Lift_EN.doc 9/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
Example SDOs
Request for a value from the Master by the Slave
A frequent request is for the position. ÆObject 6383h Subindex 1
COB-ID DLC Command Object L Object H Subinde
x
Data 0 Data
1
Data
2
Data
3
600h+Node-ID 8 40h 83h 63h 01 x x x x
Response of the Slave to the request for a value
The position is 4 bytes long, and the exact values are specified under Object 6383h Subindex 1.
COB-ID DLC Command Object L Object H Subinde
x
Data 0 Data
1
Data
2
Data
3
580h+Node-ID 8 43h 83h 63h 01 a b c d
Writing of a value from the Master to the Slave
A position can be set with Preset. ÆObject 6382h
COB-ID DLC Command Object L Object H Subinde
x
Data 0 Data
1
Data
2
Data
3
600h+Node-ID 8 22h 82h 63h 01 a b c d
Response of the Slave to the writing of a value
COB-ID DLC Command Object L Object H Subinde
x
Data 0 Data
1
Data
2
Data
3
580h+Node-ID 8 60h 82h 63h 01 0 0 0 0
3.4.4. Process data communication
Process data objects are used for real-time data exchange for process data, e.g. the position or the operating
status. PDOs can be transmitted synchronously or cyclically (asynchronously). The encoder supports PDO1
.. This supplies the current encoder position and its speed, and is defined in Objects 1906h and 1B06hh.
Synchronous
To transmit the process data synchronously, a value between 1 and F0h (=240) must be entered in the object
1906h Subindex 2. If the value is now 3, the PDO is transmitted to every third Sync telegram (with a value of
1 it is transmitted to every Sync telegram) until 0 is entered in the object 2800h 0. If, for example, a 5 is
entered there, the PDO is still written to every third Sync telegram, however a total of only 5 times. In
accordance with this, the 15th Sync telegram is followed by the last PDO. The counter for the number of
PDOs to be transmitted is reset via a position change or the NMT reset. This means the position is
transmitted 5 times unless it changes. If the position changes, it is transmitted again 5 times.
In the synchronous mode, the PDOs are requested by the Master via the Sync telegram:
Byte 0 Byte 1
COB-ID = 80 0
Cyclical (asynchronous)
If the PDOs are to be transmitted cyclically, the value FFh must be written to Object 1906h Subindex 2. In
addition, the cycle time in milliseconds must be entered in the same object, Subindex 5. The entered time is
rounded off to 1ms. If the value 0 ms is saved, the PDOs are not transmitted and the function is deactivated.
Another option is provided by Object 2800h. If the value is 0, the cyclical transmission runs as described
above. If the value is 1, it is cyclically checked whether a change has been made in the value. If not, no
transmission takes place. If the value is 4, the PDO is transmitted 4 times per cycle if a change exists.

Manual_GXP5_417_Lift_EN.doc 10/41 Baumer IVO GmbH & Co. KG
04.05.11 Villingen-Schwenningen, Germany
Overview
The following table provides a summary of the various transmission types of PDOs:
1906h
Sub2 Sub5 2800h Brief Description
FFh 3ms 0 Cyclical transmission every 3 ms
FFh 5ms 2 The PDO is sent double every 5 ms if a change is present.
FFh 0ms 0 PDO transmission is deactivated
FFh 0ms 2 PDO transmission is deactivated
3 xxx 0 Transmit for every third Sync telegram
3 xxx 2Bh Every third Sync telegram, but only 43 times total (=2Bh).
PDO
PDO1 telegram structure:
ID DLC Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6
18Ch 4 Xx Xx Xx Xx Xx Xx
ID : 17Bh+ Lift number * 10 + PosUnit
Length : 6 data bytes
Byte1 - 4 : Current position in increments
Byte 5 - 6 : Speed
3.4.5. Emergency service
Internal device error or bus problems trigger an emergency message:
COB-ID DLC Byte0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
Error Code80h+Node-ID 8
00h 01h
Error Register
1001h
Alarms 63C7h Warning 63C5h n.u.
Byte 0..1: Error Codes
Error Code (hex) Meaning
0000 Error Reset or No Error
1000 Generic Error
Byte 2: Error Register
Bit Meaning
0 Generic Error
Byte 3..4 Alarms
Bit Meaning Value = 0 Value = 1
0 Position error active No Yes
Byte 5..6 Warning
Bit Meaning Value = 0 Value = 1
2 CPU watchdog status OK Reset carried out
4 Battery charge OK Charge too low
Byte 7: Not in use