KHB EN.Cb> Ä.Cb>ä. Communication Manual. Servo Drives K. EtherCAT

Transcription

1 KHB EN.Cb> Ä.Cb>ä Communication Manual Servo Drives K EtherCAT

2 i Contents 1 About this documentation Document history Conventions used Terminology used Notes used Safety instructions General safety information Device and application specific safety instructions Product description Product features Technical data General data and operating conditions Installation Electrical installation Wiring according to EMC (CE typical drive system) Network topology Ethernet connection Commissioning Configuration with an EtherCAT configuration tool Parameter setting CANopen over EtherCAT (CoE) CANopen communication objects supported New communication objects Configuration of the communication interface New and changed CANopen communication objects under CoE CANopen communication objects under CoE that are not supported EtherCAT state machine Differences in the state machine under CANopen and EtherCAT Parameter data transfer Process data transfer Error states Emergency telegram

3 Contents i 8.8 Adaptation of the device description file Structure of the device description file Receive PDO configuration in the RxPDO node Transmit PDO configuration in the TxPDO node Initialisation commands via the Mailbox node Synchronisation with "Distributed clocks" (DC) Index

4 1 About this documentation 0Fig. 0Tab. 0 1 About this documentation Contents This documentation contains descriptions for the EtherCAT bus system for servo inverters of the 931 series. Note! This documentation completes the mounting instructions coming with the 931 servo inverter and the corresponding hardware manual. The mounting instructions and the hardware manual contain safety instructions which must be observed! ƒ The features of the EtherCAT bus system for servo inverters of the 931 series are described in detail. ƒ Furthermore this documentation contains: the most important technical data for EtherCAT communication; information on the installation and commissioning of the EtherCAT network; information on the EtherCAT data transfer, EtherCAT monitoring functions, communication relevant parameters, and different operating modes. The theoretical connections are only explained as far as required for understanding EtherCAT communication for servo inverters of the 931 series. All trade names listed in this manual are trademarks of their respective owners. Validity information The information given in this documentation is valid for servo inverters of the 931 series. Target group This documentation addresses to all persons designing, installing, commissioning, and setting the servo inverters of the 931 series. Tip! Documentation and software updates for further Lenze products can be found on the Internet in the "Services & Downloads" area under 4

5 About this documentation Document history Document history Material number Version Description.Cb> /2010 TD34 First edition Your opinion is important to us! These instructions were created to the best of our knowledge and belief to give you the best possible support for handling our product. If you have suggestions for improvement, please e mail us to: feedback docu@lenze.de Thank you for your support. Your Lenze documentation team 1.2 Conventions used This documentation uses the following conventions to distinguish between different types of information: Type of information Identification Examples/notes Spelling of numbers Decimal separator Point In general, the decimal point is used. For instance: Decimal Standard notation For example: 1234 Hexadecimal 0x[0... 9, A... F] For example: 0x60F4 Binary Nibble Text In quotation marks Point For example: 100 For example: Program name» «PC software For example:»engineer«,»global Drive Control«(GDC) Icons Page reference Reference to another page with additional information For instance: 16 = see page 16 5

6 1 About this documentation Terminology used 1.3 Terminology used Term EtherCAT Standard device Controller Master Slave Station alias address EtherCAT configuration tool HW SW CoE PDO SDO DC Meaning Fieldbus sytem of the EtherCAT Technology Group Lenze controllers with which the bus system can be used. EtherCAT node which takes over the master function in the fieldbus system. EtherCAT node representing a slave in the fieldbus system. By means of the station alias address, a permanent address is assigned to the EtherCAT slave. Software system for real time execution, programming, configuration, and diagnostics of»small Drives Control SDC«control programs Hardware Software CANopen over EtherCAT Process data object Service data object "Distributed clocks" for fieldbus synchronisation 6

7 About this documentation Notes used Notes used The following pictographs and signal words are used in this documentation to indicate dangers and important information: Safety instructions Structure of safety instructions: Danger! (characterises the type and severity of danger) Note (describes the danger and gives information about how to prevent dangerous situations) Pictograph and signal word Danger! Danger! Stop! Meaning Danger of personal injury through dangerous electrical voltage. Reference to an imminent danger that may result in death or serious personal injury if the corresponding measures are not taken. Danger of personal injury through a general source of danger. Reference to an imminent danger that may result in death or serious personal injury if the corresponding measures are not taken. Danger of property damage. Reference to a possible danger that may result in property damage if the corresponding measures are not taken. Application notes Pictograph and signal word Note! Tip! Meaning Important note to ensure troublefree operation Useful tip for simple handling Reference to another documentation 7

8 2 Safety instructions General safety information 2 Safety instructions Note! It is absolutely vital that the stated safety measures are implemented in order to prevent serious injury to persons and damage to material assets. Always keep this documentation to hand in the vicinity of the product during operation. 2.1 General safety information Danger! Disregarding the following basic safety measures may lead to severe personal injury and damage to material assets! ƒ Lenze drive components must only be applied as directed.... must never be commissioned if visibly damaged.... must never be technically modified.... must never be commissioned if incompletely mounted.... must never be operated without the required covers.... can be live, moving and rotating during operation depending on their type of protection. Some surfaces may be hot. ƒ For Lenze drive components only use permitted accessories.... only use original manufacturer spare parts. ƒ All specifications of the corresponding enclosed documentation must be observed. This is vital for a safe and trouble free operation as well as for achieving the specified product features. The procedural notes and circuit details provided in this document are proposals which the user must check for suitability for his application. The manufacturer does not accept any liability for the suitability of the specified procedures and circuit proposals. ƒ Only qualified, skilled personnel is permitted to work on and with Lenze drive components. According to IEC / CENELEC HD 384, these are persons who are familiar with the installation, mounting, commissioning, and operation of the product.... have the qualifications required for their occupation.... know and are able to apply all national regulations for the preventions of accidents, directives and laws applicable on site. 8

9 Safety instructions Device and application specific safety instructions Device and application specific safety instructions ƒ Only use cables that comply with the given specifications. Documentation for the standard device, control system, plant/machine All the other measures prescribed in this documentation must also be implemented. Observe the safety instructions and application notes stated in this manual. 9

10 3 Product description Product features 3 Product description 3.1 Product features ƒ EtherCAT in accordance with IEEE 802.3u ( 100Base TX ) with 100Mbps ( full duplex ) ƒ Star and line topology ƒ Connector: two M12 sockets, shielded and D coded, 4 pole ƒ Electrically isolated EtherCAT interface ƒ Communication cycle: 1.6ms task ƒ Max. 127 slaves ƒ EtherCAT slave implementation is based on the FPGA image ESC10 10

11 Technical data General data and operating conditions 4 4 Technical data 4.1 General data and operating conditions Field Communication profile Values EtherCAT Communication medium S/FTP (Screened Foiled Twisted Pair, ISO/IEC or EN 50173), CAT 5e Interface 2 M12 sockets, standard Ethernet (in accordance with IEEE 802.3), 100Base TX (Fast Ethernet) Network topology Line, star Number of nodes Max. 127 Max. cable length 100 m (typical) Node type EtherCAT slave Baud rate 100 Mbps Conformities, approvals CE 11

12 5 Installation Electrical installation Wiring according to EMC (CE typical drive system) 5 Installation 5.1 Electrical installation Wiring according to EMC (CE typical drive system) For wiring according to EMC requirements observe the following points: Note! ƒ Separate control cables/data lines from motor cables. ƒ Connect the shields of control cables/data lines at both ends in the case of digital signals. ƒ Use an equalizing conductor with a cross section of at least 16 mm 2 (reference: PE) to avoid potential differences between the bus nodes. ƒ Observe the other notes concerning EMC compliant wiring given in the documentation for the standard device. Wiring procedure 1. Observe bus topology. 2. Observe notes and wiring instructions in the documents for the control system. 3. Only use cables that comply with the given specifications. 12

13 Installation Electrical installation Network topology Network topology EtherCAT supports line and switch topologies. Line topology M SD SD SD Fig. 5 1 ƒ ƒ ƒ Line topology M Master SD Slave Device The devices are interconnected successively. For correct operation it is necessary that the Ethernet sockets IN and OUT are assigned correctly. The direction of data transmission is from the master to the slaves. E94AYCET006 Tip! The termination of the last node is effected automatically by the slave. Switch topology M S SD SD Fig. 5 2 Switch topology M Master S Switch SD Slave Device E94AYCET006 The wiring can also be carried out in a star structure via an appropriate switch. For this, observe the additional runtimes. 13

14 5 Installation Electrical installation Ethernet connection Ethernet connection For connection to the EtherCAT bus system a commercially available 4 pole standard Ethernet cable is suitable. Pin assignment M12 socket Pin Signal Ethernet cable specifications 1 1 Tx + 2 Rx + 3 Tx 931K_001 4 Rx Note! Only use cables complying with the below specifications. Specification of the Ethernet cable Ethernet standard Standard Ethernet (in accordance with IEEE 802.3), 100Base TX (Fast Ethernet) S/FTP (Screened Foiled Twisted Pair, ISO/IEC or EN 50173), CAT 5e Cable type Damping 23.2 db (at 100 MHz and per 100 m) Crosstalk damping 24 db (at 100 MHz and per 100 m) Return loss 10 db (per 100 m) Surge impedance 100 Design of the Ethernet cable Fig. 5 3 Design of the Ethernet cable (S/FTP, CAT 5e) A Cable insulation B Braid C Foil shielding of the core pairs TP1... TP4 Twisted core pairs E94YCEP016 14

15 Commissioning Configuration with an EtherCAT configuration tool 6 6 Commissioning 6.1 Configuration with an EtherCAT configuration tool For commissioning the EtherCAT network the following configuration tool is required: ƒ Lenze»Small Drives Control SDC«This is a software system for real time execution, programming, configuration, and diagnostics of control programs. ƒ ƒ The basic parameters of the EtherCAT bus system are stored in the internal configuration memory and can be used by the master for the node detection. During the search for nodes (bus scan) the corresponding device descriptions are used. 15

16 7 Parameter setting 7 Parameter setting The EtherCAT interface is parameterised under the menu Parameters Fieldbus EtherCAT Operating parameters: For activating the EtherCAT interface the following parameter has to be set: 931K_100 ƒ Basic node number In order to unambiguously identify the nodes in the network, a node number which may only appear once in the network must be assigned to each node. Via this node number the device is addressed. As an additional option there is the possibility of basing the node number of the 931K servo position controller on the external configuration. After the reset the input combination of the digital inputs DIN0...DIN3 is added once to the basic node number. Finally the EtherCAT protocol in the 931K servo position controller can be activated. Please note that you can only alter the parameters mentioned when the protocol is deactivated. Note! Please note that the parameterisation of the EtherCAT functionality is only preserved after a reset if the parameter set has been saved in the 931K servo position controller. EtherCAT communication can also be monitored in the Small Drives Control via the PDO editor Parameters Fieldbus EtherCAT PDO editor. In a first step only communication should be monitored via this field. During the initialisation the control defines the PDO data transfer area and, depending on the XML device description and start up settings of the control, assigns a data area (different objects). The following graphic representation shows the PDO area which is displayed when the ex works settings are maintained. In the NMT status field it can be viewed that the device is in the "Pre operational" state. It is not connected to a control and is not "activated". 16

17 Parameter setting 7 931K_101 If the device was triggered via an EtherCAT control with the corresponding XML file and is active, the displays of the PDO editor change. 931K_102 The "NMT status" field indicates that the device is Operational. The output stage is active and the drive can be actuated with setpoints. The data input range (receive PDOs) and the data output range (transmit PDOs) have been changed by the control according to the selections of the XML file of the devices. The current parameters of the device in the input range are shown in brackets behind the objects. If an object in the left field of the PDO editor is selected using the cursor, the values are also shown in the editor field down to the right. 17

18 8 CANopen over EtherCAT (CoE) CANopen communication objects supported 8 CANopen over EtherCAT (CoE) 8.1 CANopen communication objects supported As already described in the previous chapters, the user protocols are tunneled via EtherCAT. For the CANopen over EtherCAT (CoE) protocol supported by the 931K most objects for the communication layer are supported by EtherCAT in accordance with the CiA DS301 standard. These are mostly objects for establishing communication between the master and the slave. For the CANopen motion profile in accordance with CiA DSP402 most objects are supported that can also be operated via the standard CANopen fieldbus. Basically the following services and object groups are supported by the EtherCAT CoE implementation in the 931K servo position controller: Object Description SDO Service Data Object Are used for the standard parameterisation of the controller. PDO Process Data Object Quick exchange of process data (e.g. actual speed) possible. EMCY Emergency Message Transfer of error messages. The individual objects that can be addressed via the CoE protocol in the 931K servo position controller are transferred to the existing CANopen implementation within the controller and are processed there. 8.2 New communication objects However, some new CANopen objects were added to the CoE implementation under EtherCAT, which are required for the specific connection via CoE. This results from the altered communication interface between the EtherCAT protocol and the CANopen protocol. There a so called sync manager is used to control the transmission of PDOs and SDOs via the two EtherCAT transfer types (mailbox and process data protocol). Furthermore some CANopen objects of the 931K, which are provided under a standard CANopen connection, are not supported in the case of a CoE connection via EtherCAT. 18

19 CANopen over EtherCAT (CoE) New communication objects Configuration of the communication interface Configuration of the communication interface The EtherCAT protocol uses two different transfer types for the transmission of the device and user protocols, like for instance the CANopen over EtherCAT (CoE) protocol used by the 931K. These two transfer types are the mailbox telegram protocol for acyclic data and the process data telegram protocol for the transmission of cyclic data. For the CoE protocol these two transfer types are used for the different CANopen transfer types. They are used as follows: ƒ ƒ Mailbox telegram protocol This transfer type serves to transmit the Service Data Objects (SDOs) defined under CANopen. In EtherCAT they are transferred to SDO frames. Process data telegram protocol This transfer type serves to transmit the Process Data Objects (PDOs) defined under CANopen, which are used to exchange cyclic data. In EtherCAT they are transferred to PDO frames. Basically all PDOs and SDOs can be used via these two transfer types just in the way they are defined for the CANopen protocol for the 931K. For this, please refer to the CANopen 931E/K communication manual. However, the parameterisation of the PDOs and SDOs for transmitting the objects via EtherCAT is different to the settings that have to be made under CANopen. In order to integrate the CANopen objects which are to be exchanged between the master and slave via PDO or SDO transfers into the EtherCAT protocol, a so called sync manager is implemented under EtherCAT. This sync manager serves to integrate the data of the PDOs and SDOs to be transmitted in the EtherCAT telegrams. For this purpose the sync manager provides several sync channels which can transfer a CANopen data channel (receive SDO, transmit SDO, receive PDO, or transmit PDO) to the EtherCAT telegram in each case. ESC10 SYNC-Kanal 0 Receive SDO EtherCAT Bus SYNC-Kanal 1 SYNC-Kanal 2 SYNC-Kanal 3 Transmit SDO Receive PDO (1/2) Transmit PDO (1/2) 931K_002 All objects are sent via so called sync channels. The data of these channels are automatically integrated in the EtherCAT data stream and are transferred. The EtherCAT implementation in the 931K servo position controller supports four of these sync channels. Therefore, in contrast to CANopen, an additional mapping of the SDOs and PDOs to the sync channels is required. This is effected via the so called sync manager objects (objects 0x1C00 and 0x1C10 to 0x1C13). These objects are specified in the following: The 931K is provided with four individual sync channels. The assignment of these sync 19

20 8 CANopen over EtherCAT (CoE) New communication objects Configuration of the communication interface channels to the individual transfer types is fixed and cannot be changed by the user. The assignment is as follows: ƒ ƒ ƒ ƒ Sync channel 0: mailbox telegram protocol for incoming SDOs (master slave) Sync channel 1: mailbox telegram protocol for outgoing SDOs (master slave) Sync channel 2: process data telegram protocol for incoming PDOs (master slave) Here object 0x1C12 is to be observed. Sync channel 3: process data telegram protocol for outgoing PDOs (master slave) Here object 0x1C13 is to be observed. The parameterisation of the individual PDOs is set via the objects 0x1600 and 0x1601 (receive PDOs) and 0x1A00 and 0x1A01 (transmit PDOs). The parameterisation of the PDOs in the delivery status is carried out via the control system. However, it can also be carried out via the PDO editor of the SDC. Basically the setting of the sync channels and the configuration of the PDOs can only be carried out in the "Pre operational state. Note! EtherCAT does not allow for carrying out the parameterisation of the slave on one s own. For this purpose the device description files are provided. They contain the entire parameterisation, including the PDO parameterisation, which is used like this by the master during the initialisation. Therefore all changes of the parameter setting should not be carried out manually, but in the device description files. For this purpose the sections of the device description files that are important to the user are specified in the following chapters. For most applications Lenze provides complete device description files for the 931K. Note! The sync channels described here do NOT comply with the sync telegrams known from CANopen. CANopen sync telegrams can furthermore be transferred as SDOs via the SDO interface implemented under CoE, however, they have no direct impact on the sync channels described above. 20

21 CANopen over EtherCAT (CoE) New communication objects New and changed CANopen communication objects under CoE New and changed CANopen communication objects under CoE The following table provides an overview of the indexes and subindexes used for the CANopen compatible communication objects which have been added for the EtherCAT fieldbus system in the range of 0x1000h to 0x1FFFh. They mainly replace the communication parameters in accordance with the CiA standard DS301. Identifier Name Meaning 0x1000 Device type Identifier of the device control 0x1018 Identity Object Vendor ID, product code, revision serial number 0x1100 EtherCAT fixed station address Fixed address that is assigned to the slave by the master during the initialisation 0x RxPDO Mapping Identifier of the 1. receive PDO 0x RxPDO Mapping Identifier of the 2. receive PDO 0x1A00 1. TxPDO mapping Identifier of the 1. transmit PDO 0x1A01 2. TxPDO mapping Identifier of the 2. transmit PDO 0x1C00 Sync Manager Communication type Object for the configuration of the individual sync channels (SDO or PDO transfer) 0x1C10 0x1C11 0x1C12 0x1C13 Sync Manager PDO Mapping for Sync channel 0 Sync Manager PDO Mapping for Sync channel 1 Sync Manager PDO Mapping for Sync channel 2 Sync Manager PDO Mapping for Sync channel 3 Assignment of sync channel 0 to a PDO/SDO (Channel 0 is always reserved for the mailbox receive SDO transfer) Assignment of sync channel 1 to a PDO/SDO (Channel 1 is always reserved for the mailbox transmit SDO transfer) Assignment of sync channel 2 to a PDO (Channel 2 is reserved for receive PDOs) Assignment of sync channel 3 to a PDO (Channel 3 is reserved for transmit PDOs) In the following chapters the objects 0x1C00 and 0x1C10 to 0x1C13 are specified, since they are only defined and implemented under the EtherCAT CoE protocol and thus cannot be found in the CANopen manual. Note! ƒ The 931K servo position controller with the EtherCAT technology module supports two receive PDOs (RxPDO) and two transmit PDOs (TxPDO). ƒ The objects 0x1008, 0x1009, and 0x100A are not supported by the 931K since plain text strings cannot be read by the servo position controller. 21

22 8 CANopen over EtherCAT (CoE) New communication objects New and changed CANopen communication objects under CoE Object 0x1100 EtherCAT fixed station address Via this object a definite address is assigned to the slave during the initialisation phase. The object has the following meaning: EtherCAT fixed station address Index 0x1100 Name EtherCAT fixed station address Object code VAR Data type UINT16 EtherCAT fixed station address Access RO PDO Mapping no Value Range 0 Default Value 0 Object 0x1C00 Sync Manager Communication Type Via this object the transfer type for the different channels of the EtherCAT sync manager can be read out. Since the 931K only supports the first four sync channels under the EtherCAT CoE protocol, the following objects can only be read. Therefore the configuration of the sync manager is fixedly configured for the 931K. The objects have the following meaning: Sync Manager Communication Type Index 0x1C00 Name Sync Manager Communication Type Object code Array Data type UINT8 Sync Manager Communication Type Subindex 0 Description Number of used Sync Manager Channels Access ro PDO Mapping no Value Range 4 Default Value 4 Sync Manager Communication Type Subindex 1 Description Communication Type Sync Channel 0 Access ro PDO Mapping no Value Range 1: Mailbox Receive (Master Slave) Default Value 1: Mailbox Receive (Master Slave) 22

23 CANopen over EtherCAT (CoE) New communication objects New and changed CANopen communication objects under CoE 8 Sync Manager Communication Type Subindex 2 Description Communication Type Sync Channel 1 Access ro PDO Mapping no Value Range 2: Mailbox Transmit (Master Slave) Default Value 2: Mailbox Transmit (Master Slave) Sync Manager Communication Type Subindex 3 Description Communication Type Sync Channel 2 Access ro PDO Mapping no Value Range 0: unused 3: Process Data Output (TxPDO / Master Slave) Default Value 3 Sync Manager Communication Type Subindex 4 Description Communication Type Sync Channel 3 Access ro PDO Mapping no Value Range 0: unused 4: Process Data Output (TxPDO / Master Slave) Default Value 4 23

24 8 CANopen over EtherCAT (CoE) New communication objects New and changed CANopen communication objects under CoE Object 0x1C10 Sync Manager Channel 0 (Mailbox Receive) Via this object a PDO for sync channel 0 can be configured. Since sync channel 0 is always assigned by the mailbox telegram protocol, this object cannot be changed by the user. Thus the object always has the following values: Sync Manager Channel 0 (Mailbox Receive) Index 0x1C10 Name Sync Manager Channel 0 (Mailbox Receive) Object code Array Data type UINT8 Sync Manager Channel 0 (Mailbox Receive) Subindex 0 Description Number of assigned PDOs Access ro PDO Mapping no Value Range 0 (no PDO assigned to this channel) Default Value 0 (no PDO assigned to this channel) Note! The name "Number of assigned PDOs that is defined for subindex 0 of these objects by the EtherCAT specification is misleading here, as the sync manager channels 0 and 1 are always assigned by the mailbox telegram. In this telegram type SDOs are always transmitted under EtherCAT CoE. Subindex 0 of these objects thus remains unused. Object 0x1C11 Sync Manager Channel 1 (Mailbox Send) Via this object a PDO for sync channel 1 can be configured. Since sync channel 1 is always assigned by the mailbox telegram protocol, this object cannot be changed by the user. Thus the object always has the following values: Sync Manager Channel 1 (Mailbox Send) Index 0x1C11 Name Sync Manager Channel 1 (Mailbox Send) Object code Array Data type UINT8 Sync Manager Channel 1 (Mailbox Send) Subindex 0 Description Number of assigned PDOs Access ro PDO Mapping no Value Range 0 (no PDO assigned to this channel) Default Value 0 (no PDO assigned to this channel) 24

25 CANopen over EtherCAT (CoE) New communication objects New and changed CANopen communication objects under CoE 8 Object 0x1C12 Sync Manager Channel 2 (Process Data Output) Via this object a PDO for sync channel 2 can be configured. Sync channel 2 is fixedly provided for the reception of receive PDOs (master slave). In this object the number of PDOs has to be set under subindex 0, which are assigned to this sync channel. In subindexes 1 to 2 the object number of the PDO is then entered which is to be assigned to the channel. For this only the object numbers of the previously configured receive PDOs can be used (0x1600 and 0x1601). Sync Manager Channel 2 (Process Data Output) Index 0x1C12 Name Sync Manager Channel 2 (Process Data Output) Object code Array Data type UINT16 Sync Manager Channel 2 (Process Data Output) Subindex 0 Description Number of assigned PDOs Access RW PDO Mapping no Value Range 0: no PDO assigned to this channel 1: one PDO assigned to this channel 2: two PDOs assigned to this channel Default Value 2: two PDOs assigned to this channel Sync Manager Channel 2 (Process Data Output) Subindex 1 Description PDO Mapping object Number of assigned RxPDO Access rw PDO Mapping no Value Range 0x1600: first Receive PDO 0x1601: second Receive PDO Default Value 0x1600: first Receive PDO Sync Manager Channel 2 (Process Data Output) Subindex 2 Description PDO Mapping object Number of assigned RxPDO Access rw PDO Mapping no Value Range 0x1600: first Receive PDO 0x1601: second Receive PDO Default Value 0x1601: second Receive PDO Object 0x1C13 Sync Manager Channel 3 (Process Data Input) Via this object a PDO for sync channel 3 can be configured. Sync channel 3 is is fixedly provided for the transmission of transmit PDOs (master slave). In this object the number of PDOs has to be set under subindex 0, which are assigned to this sync channel. In subindexes 1 to 2 the object number of the PDO is then entered which is to be assigned to the channel. For this only the object numbers of the previously configured transmit PDOs can be used (0x1A00 and 0x1A01). 25

26 8 CANopen over EtherCAT (CoE) New communication objects New and changed CANopen communication objects under CoE Sync Manager Channel 3 (Process Data Input) Index 0x1C13 Name Sync Manager Channel 3 (Process Data Input) Object code Array Data type UINT8 Sync Manager Channel 3 (Process Data Input) Subindex 0 Description Number of assigned PDOs Access rw PDO Mapping no Value Range 0: no PDO assigned to this channel 1: one PDO assigned to this channel 2: two PDOs assigned to this channel Default Value 2: two PDOs assigned to this channel Sync Manager Channel 3 (Process Data Input) Subindex 1 Description PDO Mapping object Number of assigned TxPDO Access rw PDO Mapping no Value Range 0x1A00: first Transmit PDO 0x1A01: second Transmit PDO Default Value 0x1A00: first Transmit PDO Sync Manager Channel 3 (Process Data Input) Subindex 2 Description PDO Mapping object Number of assigned TxPDO Access rw PDO Mapping no Value Range 0x1A00: first Transmit PDO 0x1A01: second Transmit PDO Default Value 0x1A01: second Transmit PDO 26

27 CANopen over EtherCAT (CoE) New communication objects CANopen communication objects under CoE that are not supported CANopen communication objects under CoE that are not supported When the 931K is connected under CANopen over EtherCAT, some CANopen objects are not supported, which are available in the case of a direct connection of the 931K via CANopen. These objects are listed in the following table: Identifier Name Meaning 0x1008 Manufacturer Device Name Device name (not supported by 931K) (String) 0x1009 Manufacturer Hardware HW version (not supported by 931K) Version (String) 0x100A Manufacturer Software SW version (not supported by 931K) Version (String) 0x6089 position_notation_index Specifies the number of decimal positions for displaying position values in the control 0x608A position_dimension_index Specifies the unit for displaying position values in the control 0x608B velocity_notation_index Specifies the number of decimal positions for displaying speed values in the control 0x608C velocity_dimension_index Specifies the unit for displaying speed values in the control 0x608D acceleration_notation_index Specifies the number of decimal positions for displaying acceleration values in the control 0x608E acceleration_dimension_index Specifies the unit for displaying acceleration values in the control 0x60C4 interpolated_data_ configuration Defines a data buffer for the position data in the interpolating mode Note! Objects 0x6089 to 0x608E have no direct influence in the current CANopen implementation for the 931K servo position controller. Therefore these objects can be dispensed with in the EtherCAT CoE implementation. 27

28 8 CANopen over EtherCAT (CoE) EtherCAT state machine CANopen communication objects under CoE that are not supported 8.3 EtherCAT state machine Like in nearly all fieldbus interface connections for servo position controllers, the slave connected (in this case the 931K servo position controller) first has to be initialised by the master before it can be used by the master in an application. For this purpose a state machine is implemented, defining a fixed procedure for such an initialisation. Such a state machine is also defined for the EtherCAT interface. Change overs between the individual states of the state machine may only take place between specific states and are always initiated by the master. A slave may not carry out a state change on its own initiative. The individual states and the permissible state changes are described in the following tables and illustrations. Init (IP) (PI) Pre-Operational (SI) (OI) (PS) (SP) (OP) Safe-Operational (SO) (OS) Operational Status Power on Init Pre operational Safe operational Operational Description 931K_003 The device has been switched on. It initialises itself and switches directly to the "Init state. In this state the EtherCAT fieldbus is synchronised by the master. This also includes establishing asynchronous communication between the master and the slave (mailbox telegram protocol). There is no direct communication between the master and the slave yet. If all devices which are connected to the bus have been configured, a change over to the "Pre operational state is effected. In this state asynchronous communication between the master and the slave is active. This state is used by the master to establish possible cyclic communication via PDOs and carry out required parameter settings via acyclic communication. If this state has been passed through in an error free manner, the master changes to the "Safe operational state. This state is used to set all devices that are connected to the EtherCAT bus to a safe state. In doing this, the slave sends current actual values to the master, however, it ignores new setpoints from the master and uses safe default values instead. If this state has been passed through in an error free manner, the master changes to the "Operational state. In this state both acyclic and cyclic communication are active. Master and slave exchange setpoint data and actual value data. In this state the 931K can be enabled and traversed via the CoE protocol. Between the individual states only the following transitions are permissible. 28

29 CANopen over EtherCAT (CoE) EtherCAT state machine CANopen communication objects under CoE that are not supported 8 Status transition IP PI PS SP SO OS OP SI OI Status Start of acyclic communication (mailbox telegram protocol) Stop of acyclic communication (mailbox telegram protocol) Start of cyclic communication (process data telegram protocol) Slave sends actual values to the master Slave ignores setpoints from the master and uses internal default values Stop of cyclic communication (process data telegram protocol) Slave stops sending actual values to the master Slave evaluates current setpoint selections of the master Slave ignores setpoints from the master and uses internal default values Stop of cyclic communication (process data telegram protocol) Slave stops sending actual values to the master Master stops sending setpoints to the slave Stop of cyclic communication (process data telegram protocol) Stop of acyclic communication (mailbox telegram protocol) Slave stops sending actual values to the master Master stops sending setpoints to the slave Stop of cyclic communication (process data telegram protocol) Stop of acyclic communication (mailbox telegram protocol) Slave stops sending actual values to the master Master stops sending setpoints to the slave Note! In addition to the states listed here, in the EtherCAT state machine the "Bootstrap" state is specified. This state is considered to load a new firmware in the slave during the EtherCAT protocol is running. Since a firmware download in the case of the 931K servo position controller is carried out via the RS232 interface, this state is not implemented for the 931K servo position controller. 29

30 8 CANopen over EtherCAT (CoE) EtherCAT state machine Differences in the state machine under CANopen and EtherCAT Differences in the state machine under CANopen and EtherCAT When the 931K is operated via the EtherCAT CoE protocol, instead of the CANopen state machine the EtherCAT state machine is used. In some points it differs from the CANopen state machine. The differences between the response of the CANopen and EtherCAT state machines are specified in the following: ƒ ƒ ƒ No direct transition from Pre operational to Power on No "Stopped" state, but a direct transition to the "Init" state Additional state: Safe operational CANopen State Power on Init Safe operational Operational EtherCAT State Power on (initialisation) Stopped Operational 30

31 CANopen over EtherCAT (CoE) Parameter data transfer Differences in the state machine under CANopen and EtherCAT Parameter data transfer All data of an SDO transfer in the case of CoE are transmitted via SDO frames. Structure of an EtherCAT SDO frame Mailbox Header CoE Header SDO control byte Index Subindex Data Data 6 bytes 2 bytes 1 byte 2 bytes 1 byte 4 bytes 1... n bytes SDO frame area Description Mailbox Header Data for mailbox communication ( length, address, and type ) CoE Header Identification of the CoE service SDO control byte Identification for a read or write command Index Main index of the CANopen communication object Subindex Subindex of the CANopen communication object Data Data contents of the CANopen communication object Data (optional) Further optional data This option is not supported by the 931K servo position controller since only standard CANopen objects can be addressed. The maximum size of these objects is 32 bits. In order to transmit a standard CANopen object via such an SDO frame, the actual CANopen SDO frame is packed and transmitted within an EtherCAT SDO frame. Standard CANopen SDO frames can be used for: ƒ Initialisation of the SDO download ƒ Download of the SDO segment ƒ Initialisation of the SDO upload ƒ Upload of the SDO segment ƒ Abort of the SDO transfer ƒ SDO upload expedited request ƒ SDO upload expedited response Note! All transfer types specified above are supported by the 931K servo position controller. Since only the standard CANopen objects the size of which is limited to 32 bits (4 bytes) can be addressed if the CoE implementation of the 931K is used, the transfer types are only supported up to a maximum data length of 32 bits (4 bytes). 31

32 8 CANopen over EtherCAT (CoE) Process data transfer Differences in the state machine under CANopen and EtherCAT 8.5 Process data transfer The Process Data Objects (PDO) serve to the cyclic transmission of setpoint and actual value data between the master and the slave. They have to be configured by the master before the slave is operated in the "Pre operational state. Afterwards they are transferred to PDO frames. These PDO frames have the following structure. Structure of an EtherCAT PDO frame Process Data (Standard CANopen PDO frame) Process Data (optional) 1 8 bytes 1... n bytes PDO frame area Process Data Process Data (optional) Description Data contents of the PDO (Process Data Object) Further optional data contents of further PDOs (Process Data Object) In order to transfer a PDO via the EtherCAT CoE protocol, the transmit and receive PDOs additionally to the PDO configuration (PDO mapping) have to be assigned to a transmission channel of the sync manager. The data exchange of PDOs for the 931K servo position controller exclusively takes place via the EtherCAT process data telegram protocol. Note! The transmission of CANopen process data (PDOs) via acyclic communication (mailbox telegram protocol) is not supported by the 931K servo position controller. Since within the 931K servo position controller all the data exchanged via the EtherCAT CoE protocol are directly transferred to the internal CANopen implementation, the PDO mapping is also carried out as described in the 931E/K CANopen manual. Object Dictionary Mapping Object Index 1ZZZh 1ZZZh 1ZZZh Sub 01h 02h 03h Object contents 6TTTh TTh 6UUUh UUh 6WWWh WWh PDO_1 PDO-Length: 32 Bit Object A Object B Object D Application Object 6TTTh TTh 6UUUh UUh 6VVVh VVh 6WWWh WWh 6XXXh 6YYYh 6ZZZh XXh YYh ZZh Object A Object B Object C Object D Object E Object F Object G 931K_004 The simple transfer of the data received via CoE to the CANopen protocol implemented in 32

33 CANopen over EtherCAT (CoE) Process data transfer Differences in the state machine under CANopen and EtherCAT 8 the 931K, apart from the mapping of the CANopen objects, also allows for using the objects for the CANopen protocol available for the 931K transmission type of the PDOs for the PDOs to be parameterised. An exception to this is the "Sync message" transmission type. This transmission type cannot be used under the EtherCAT CoE implementation for the 931K servo position controller, as EtherCAT CoE does not offer any equivalent telegrams for the sync telegrams defined under CANopen, and the FPGA block ESC10 used in the 931K servo position controller does not support synchronisation via the "Distributed Clocks" specified under EtherCAT. For further information please refer to the CANopen manual of the 931K servo position controller. Note! The 931K servo position controller with the EtherCAT technology module supports the functions: ƒ Cyclic PDO frame telegram by the process data telegram protocol. Note! The 931K servo position controller with the EtherCAT technology module supports two receive PDOs (RxPDO) and two transmit PDOs (TxPDO). The two RxPDOs or the two TxPDOs have to be mapped to a sync channel of the sync manager, respectively. 33

34 8 CANopen over EtherCAT (CoE) Error states Differences in the state machine under CANopen and EtherCAT 8.6 Error states The EtherCAT CoE implementation for the 931K servo position controller monitors the following error states of the EtherCAT fieldbus: ƒ ƒ FPGA is not ready when the system is started A bus error has occurred ƒ An error on the mailbox channel has occurred. The following errors are monitored here An unknown service is requested A protocol different from CANopen over EtherCAT (CoE) is to be used An unknown sync manager is addressed All these errors are included in the list of error messages for the 931K servo position controller. If one of the above mentioned errors occurs it is transferred to the control via a standard emergency frame. Note! The 931K servo position controller with EtherCAT supports the function: ƒ Due to an event, Application Controller transfers a defined error message number (Error Control frame telegram from the controller) 34

35 CANopen over EtherCAT (CoE) Emergency telegram Differences in the state machine under CANopen and EtherCAT Emergency telegram Via the EtherCAT CoE emergency frame error messages are exchanged between the master and the slave. The CoE emergency frames serve to directly transfer the emergency messages defined under CANopen. The CANopen telegrams, like also in the cases of the SDO and PDO transmission, are simply tunneled through the CoE emergency frames. Structure of an EtherCAT emergency frame Mailbox Header CoE Header Error code Error register Data Data (optional) 6 bytes 2 bytes 2 bytes 1 byte 5 bytes 1... n bytes Emergency frame area Description Mailbox Header Data for mailbox communication ( length, address, and type ) CoE Header Identification of the CoE service Error code Error code of the CANopen EMERGENCY message Error register Error register of the CANopen EMERGENCY message Data Data contents of the CANopen EMERGENCY message Data (optional) Further optional data Since the CoE implementation for the 931K servo position controller only supports the standard CANopen emergency frames, the Data (optional) field is not supported. As here also a simple transfer of the emergency messages received and transmitted via CoE to the CANopen protocol implemented in the 931K servo position controller takes place, all error messages can be looked up in the CANopen manual for the 931K servo position controller. 35

36 8 CANopen over EtherCAT (CoE) Adaptation of the device description file Structure of the device description file 8.8 Adaptation of the device description file Under EtherCAT each device is described by means of a device description file. This file can be used for a simple connection of the EtherCAT devices to an EtherCAT control. This file contains the complete parameter setting of the slave, including the parameter setting of the sync manager and of the PDOs. Therefore the configuration of the slave can be changed via this file. For the 931K servo position controller Lenze has created such a device description file. It can be downloaded from the Lenze homepage. In order to enable the user to adapt this file to his or her application, its contents are described in greater detail here Structure of the device description file The EtherCAT device description file is created in the XML format. This format provides the advantage that it can be read and edited using a standard text editor. An XML file always has a tree structure within which individual branches are defined by nodes. These nodes have a starting and an end mark. A node can contain an optional number of subnodes. The device description file for the 931K servo position controller under EtherCAT CoE is divided into the following subnodes: Main nodes of the device description file Node designation Meaning Adaptable Vendor This node contains the manufacturer s name and ID of the device No which this description file belongs to. Additionally the binary code of a bitmap with the manufacturer s logo is included. Descriptions This subnode contains the actual device description including the configuration and initialisation. To some extent Subnodes of the Descriptions node Node designation Meaning Adaptable Groups This node contains the allocation of the device to a device group. These No groups are defined and must not be changed by the user. Devices This subnode contains the actual description of the device. To some extent The following table solely describes the subnodes of the Descriptions node which are required for the parameterisation of the 931K servo position controller under CoE. All other nodes are fixed and must not be changed by the user. 36

37 CANopen over EtherCAT (CoE) Adaptation of the device description file Structure of the device description file 8 Important subnodes of the Descriptions node Node designation Meaning Adaptable RxPDO Fixed=... This node contains the PDO mapping and the assignment of the PDO Yes to the sync manager for receive PDOs TxPDO Fixed=... This node contains the PDO mapping and the assignment of the PDO Yes to the sync manager for transmit PDOs Mailbox Under this node commands can be defined which are transferred by the master to the slave during the phase transition from "Pre operational to "Operational via SDO transfers. Yes Since solely the nodes from the "Important subnodes of the Description node" table are important to the user for adapting the device description file, they are described in detail in the following chapters. The remaining contents of the device description file are fixed and must not be changed by the user. Stop! If changes on contents and nodes other than the RxPDO, TxPDO and mailbox nodes are carried out in the device description file, faultless operation of the device can no longer be guaranteed. 37

38 8 CANopen over EtherCAT (CoE) Adaptation of the device description file Receive PDO configuration in the RxPDO node Receive PDO configuration in the RxPDO node The RxPDO node serves to define the mapping for the receive PDOs and their assignment to a channel of the sync manager. A typical entry in the device description file for the 931K servo position controller can be as follows: <RxPDO Fixed="1" Sm="2"> <Index>#x1600</Index> <Name>Outputs</Name> <Entry> <Index>#x6040</Index> <SubIndex>0</SubIndex> <BitLen>16</BitLen> <Name>Controlword</Name> <DataType>UINT</DataType> </Entry> <Entry> <Index>#x6060</Index> <SubIndex>0</SubIndex> <BitLen>8</BitLen> <Name>Mode_Of_Operation</Name> <DataType>USINT</DataType> </Entry> </RxPDO> As it can be seen in the above example, such an entry describes the entire mapping of the receive PDO in detail. The first great block indicates the object number of the PDO and its type. Then a list of all CANopen objects follows which are to be mapped into the PDO. Nodes in the configuration of the receive PDO Node designation Meaning Adaptable RxPDO Fixed="1" This node directly describes the state of the receive PDO and its No Sm="2" assignment to the sync manager. The entry Fixed="1" indicates that the mapping of the object cannot be changed. The entry Sm="2" indicates that the PDO is to be assigned to sync channel 2 of the sync manager. Index This entry contains the object number of the PDO. Here the first Yes receive PDO is configured under the object number 0x1600. Name The name indicates whether this PDO is a receive PDO (outputs) or a No transmit PDO (inputs). For a receive PDO this value always has to be set to "Output. Entry The Entry node in each case contains a CANopen object that is to be mapped into the PDO. An Entry node contains the index and subindex of the CANopen object to be mapped, and its name and data type. Yes The sequence and mapping of the individual CANopen objects for the PDO corresponds to the sequence in which they are specified via the "Entry" inputs in the device description file. The individual subnodes of an "Entry" node are specified in the following tables: 38