User Manual Anybus X-gateway CANopen DeviceNet ® Doc: HMSI-168-83 Rev: 2.10 Connecting DevicesTM HALMSTAD • CHICAGO • KARLSRUHE • TOKYO • BEIJING • MILANO • MULHOUSE • COVENTRY • PUNE • COPENHAGEN HMS Industrial Networks Mailing address: Box 4126, 300 04 Halmstad, Sweden Visiting address: Stationsgatan 37, Halmstad, Sweden E-mail: [email protected] www.anybus.com Important User Information This document is intended to provide a good understanding of the functionality offered by the Anybus X-gateway CANopen - DeviceNet. The reader of this document is expected to be familiar with high level software design, and communication systems in general. The use of advanced CANopen specific functionality may require in-depth knowledge in CANopen networking internals and/or information from the official CANopen specifications. In such cases, the people responsible for the implementation of this product should either obtain the CANopen specification to gain sufficient knowledge or limit their implementation in such a way that this is not necessary. Also knowledge of DeviceNet is expected. Liability Every care has been taken in the preparation of this manual. Please inform HMS Industrial Networks AB of any inaccuracies or omissions. The data and illustrations found in this document are not binding. We, HMS Industrial Networks AB, reserve the right to modify our products in line with our policy of continuous product development. The information in this document is subject to change without notice and should not be considered as a commitment by HMS Industrial Networks AB. HMS Industrial Networks AB assumes no responsibility for any errors that may appear in this document. There are many applications of this product. Those responsible for the use of this device must ensure that all the necessary steps have been taken to verify that the applications meet all performance and safety requirements including any applicable laws, regulations, codes, and standards. HMS Industrial Networks AB will under no circumstances assume liability or responsibility for any problems that may arise as a result from the use of undocumented features, timing, or functional side effects found outside the documented scope of this product. The effects caused by any direct or indirect use of such aspects of the product are undefined, and may include e.g. compatibility issues and stability issues. The examples and illustrations in this document are included solely for illustrative purposes. Because of the many variables and requirements associated with any particular implementation, HMS Industrial Networks AB cannot assume responsibility for actual use based on these examples and illustrations. Intellectual Property Rights HMS Industrial Networks AB has intellectual property rights relating to technology embodied in the product described in this document. These intellectual property rights may include patents and pending patent applications in the US and other countries. Trademark Acknowledgements Anybus ® is a registered trademark of HMS Industrial Networks AB. All other trademarks are the property of their respective holders. WARNING: This is a class A product. In a domestic environment this product may cause radio interference in which case the user may be required to take adequate measures. ESD Note: This product contains ESD (Electrostatic Discharge) sensitive parts that may be damaged if ESD control procedures are not followed. Static control precautions are required when handling the product. Failure to observe this may cause damage to the product. WARNING: DO NOT REMOVE OR REPLACE USB CONNECTOR WHILE CIRCUIT IS LIVE UNLESS THE AREA IS KNOWN TO BE FREE OF IGNITIBLE CONCENTRATIONS OF FLAMMABLE GASES OR VAPORS. Anybus X-gateway CANopen - DeviceNet User Manual Rev: 2.10 Copyright© HMS Industrial Networks AB Doc: HMSI-168-83 Table of Contents Table of Contents Important User Information Liability........................................................................................................................................... 1 Intellectual Property Rights............................................................................................................... 1 Trademark Acknowledgements......................................................................................................... 1 Preface About This Document Related Documents.................................................................................................................................. 1 Document History ................................................................................................................................... 1 Conventions & Terminology .................................................................................................................. 1 Sales and Support ..................................................................................................................................... 1 Chapter 1 Anybus X-gateway CANopen - DeviceNet Introduction .............................................................................................................................................. 2 Features ...................................................................................................................................................... 3 Functional Overview................................................................................................................................ 4 Data Exchange.......................................................................................................................................... 4 Chapter 2 About the Anybus X-gateway CANopen External View............................................................................................................................................ 6 Status LEDs .............................................................................................................................................. 7 Primary Network ...................................................................................................................................... 8 DeviceNet Connector........................................................................................................................ 8 Switches ........................................................................................................................................... 8 Secondary Network.................................................................................................................................. 9 CANopen Connector ....................................................................................................................... 9 Configuration Switches ..................................................................................................................... 9 USB Connector....................................................................................................................................... 10 Power Connector............................................................................................................................. 10 Hardware Installation............................................................................................................................. 11 CANopen Electronic Data Sheet (EDS) ............................................................................................ 12 DeviceNet Electronic Data Sheet (EDS) ........................................................................................... 12 Chapter 3 Getting Started Chapter 4 CANopen Fieldbus Functionality Supported Fieldbus Services................................................................................................................. 14 Chapter 5 Configuration Module Identification ............................................................................................................................ 15 CANopen Master/Slave Configuration .............................................................................................. 16 II Secondary CANopen Network Configuration .................................................................................. 17 LSS Routine.................................................................................................................................. 17 Configuration of the DeviceNet Adapter Interface.......................................................................... 18 DeviceNet Baud Rate and MACID Configuration........................................................................ 18 Enabling Data Exchange....................................................................................................................... 18 Chapter 6 CANopen Module Specification NMT State Machine............................................................................................................................... 19 Data Exchange........................................................................................................................................ 20 Control Word ................................................................................................................................ 21 Status Word .................................................................................................................................. 22 Example........................................................................................................................................ 24 PDO Functionality ........................................................................................................................ 25 LSS Services............................................................................................................................................. 26 Error Control .......................................................................................................................................... 27 Heartbeat Mechanism .................................................................................................................... 27 Node Guarding.............................................................................................................................. 27 Emergency Object (EMCY)........................................................................................................... 27 Chapter 7 CANopen Supported Objects Static Data Types.................................................................................................................................... 28 Communication Profile Area................................................................................................................ 28 DS301 Communication Profile Objects.......................................................................................... 28 Configuration Manager .................................................................................................................. 30 Network Management Objects ....................................................................................................... 31 Vendor Specific Objects........................................................................................................................ 36 Transmit Buffer ............................................................................................................................. 37 Receive Buffer................................................................................................................................. 38 I/O Buffer Addresses and Object Dictionary Indices Relation ........................................................ 39 General Fieldbus Parameters.......................................................................................................... 40 DeviceNet Specific Parameters........................................................................................................ 40 Appendix A Technical Specification Protective Earth (PE) Requirements................................................................................................... 41 Power Supply .......................................................................................................................................... 41 Environmental Specification ................................................................................................................ 41 Temperature................................................................................................................................... 41 Relative Humidity.......................................................................................................................... 41 EMC (CE) Compliance ......................................................................................................................... 42 UL and ATEX Certification ................................................................................................................. 42 Appendix B Status LED Timing Diagrams Appendix C CANopen Emergency Codes Appendix D Enabling Data Exchange Anybus X-gateway CANopen Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Preface P. About This Document For more information, documentation etc., please visit www.anybus.com P.1 Related Documents Document CíA Draft Standard 301 v4.2 CiA Draft Standard Proposal 302 Part 1-5 DeviceNet Specification, Vol. 1 DeviceNet Specification, Vol. 3 Author CAN in Automation CAN in Automation ODVA ODVA P.2 Document History Revision List Revision 1.00 1.01 1.02 2.00 2.01 2.10 Date 2010-01-17 2011-02-04 2011-03-29 2011-12-01 2013-01-11 Nov 2014 Author(s) KeL KeL KeL KeL KeL SDa Chapter(s) All 6 Multiple Description First official release Minor corrections and updates Minor corrections General rewrite Minor correction Removed references to PORT configuration software P.3 Conventions & Terminology The following conventions are used throughout this manual: • Numbered lists provide sequential steps • Bulleted lists provide information, not procedural steps • The terms ‘Anybus’ or ‘module’ refers to the Anybus X-gateway module. • Hexadecimal values are written in the format NNNNh, where NNNN is the hexadecimal value. • A byte always consists of 8 bits P.4 Sales and Support For general contact information and support, please refer to the contact and support pages at www.anybus.com Anybus X-gateway CANopen to DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 1 1. Anybus X-gateway CANopen - DeviceNet 1.1 Introduction The Anybus X-gateway CANopen is a series of network gateways, used to provide a seamless connection between a primary fieldbus/Ethernet network and a secondary CANopen sub-network. The gateway enables the master of the fieldbus/Ethernet network to exchange data to and from the secondary CANopen sub-network. This makes it possible to integrate CANopen devices into almost any other PLC system and their supported networks. The gateway is based on patented Anybus technology, a proven industrial communication solution used all over the world by leading manufacturers of industrial automation products. Each module offers CANopen master/slave connectivity to one of these industrial networks: EtherCAT, PROFIBUS DPV1, DeviceNet, ControlNet, CANopen, Modbus RTU, EtherNet/IP, PROFINET IO (both RT and IRT) or Modbus TCP. No proprietary configuration software is needed, though dedicated configuration tools are required when setting up the actual industrial network communications. Any standard CANopen configuration tool can be used to configure the CANopen interface. DeviceNet Network (primary network) Master (e.g. PLC) Slave Anybus X-gateway CANopen Slave Slave Slave DeviceNet Network Slave CANopen Master/Slave Slave Slave Slave Slave Device Level with CANopen Slaves (secondary network) The gateways transmit I/O data transparently between the two networks. I/O data from the primary fieldbus/Ethernet network is written into CANopen objects that can be mapped into CANopen PDOs or read via CANopen SDOs and vice versa. The gateway, described in this manual, connects a DeviceNet network with a CANopen network. The module acts as a DeviceNet adapter/slave on the primary network and can act either as a slave or as a master on the sub-network, transmitting I/O data between the networks. The DeviceNet adapter/slave interface, connected to the primary network, is configured with a standard device description file (GSD/EDS) and the standard configuration tool of the master of that network. No programming is required. IMPORTANT: This product acts as a gateway between two industrial networks. One network is a CANopen subnetwork, on which the module either acts as a master or as a slave, depending on configuration. Using the module, this CANopen sub-network is connected to and can exchange data with another kind of industrial network, e.g. PROFIBUS or EtherNet/IP, connected to the module. To make it easier to distinguish the two networks from each other, the CANopen sub-network will be called the secondary network throughout the manual. The other network will be called the primary network. In the product that this manual describes, the primary network is DeviceNet and the secondary network is CANopen. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Anybus X-gateway CANopen - DeviceNet 3 1.2 Features The Anybus CANopen X-gateway acts as an intelligent link between two industrial networks. On the secondary CANopen sub-network, it can perform either as a master (manager) or as a slave (server), depending on configuration, while it always will act as a slave on the primary fieldbus/Ethernet side. The implementation is based on HMS NP30 network microprocessor and is certified by CAN in Automation (CIA) for full conformance to the CANopen DS 301 v4.0.2 standard. CANopen (sub-network, secondary network) • CANopen master (manager) and slave functionality • Connects up to 126 CANopen slave nodes • Complies to the CANopen communication profile DS301 4.2 and DSP302 (part 1-5) • Supports cyclic and acyclic synchronous as well as COS (change of state) PDO message types • 20 kbps... 1 Mbps operation • Heartbeat and node guarding mechanisms • Sync objects • 128 receive and 128 transmit PDOs available • Up to 510 bytes of cyclic data in each direction (PDO) DeviceNet Adapter Features (primary network) • Supports baud rates 125 kbit/s, 250 kbit/s and 500 kbit/s operation • On-board configuration switches • Up to 512 bytes of I/O in each direction (including the control/status word), DeviceNet master dependent • Explicit Messaging (up to 512 bytes in each direction (including the control/status word), DeviceNet master dependent • Polled I/O • Bit-strobed I/O • Change-of-state / Cyclic I/O • Unconnected Message Manager (UCMM, 5 servers) Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Anybus X-gateway CANopen - DeviceNet 4 1.3 Functional Overview DeviceNet network Anybus DeviceNet slave interface Anybus CANopen master/slave interface CANopen network Internally, the X-gateway consists of an intelligent gateway platform, an Anybus CANopen interface1 and an Anybus DeviceNet interface. The CANopen interface and the Anybus DeviceNet interface are interconnected through the intelligent gateway platform, which basically forwards data from one network to the other and vice versa as shown below. This design allows almost any industrial network to be connected to a CANopen master or a slave on a separate CANopen network. 1.4 Data Exchange Control Word Status Word Data To the CANopen Network Data From the CANopen Network CANopen Network Interface DeviceNet Network Interface Status Word Control Word Data From the CANopen Network Data to the Canopen Network DeviceNet network CANopen network Each of the two network interfaces exchanges data on its network through two buffers. The gateway forwards the data between these buffers as shown below. Note that this process is separated from the network data exchange. While the gateway ensures data consistency (where applicable), it does not feature any built-in mechanisms for synchronisation between the primary DeviceNet network and the secondary CANopen network. Each buffer holds up to 512 bytes of data, where the first two bytes on the primary network side always are used for control/status information. The remaining 510 bytes gives the theoretical upper limit for the number of data bytes that can be exchanged in each direction. Please note that the actual number of bytes that can be exchanged is highly application and network dependent and can thus be noticably lower than 510 bytes. Through the dedicated control word, the master on the primary DeviceNet network starts/stops the exchange of data on the secondary CANopen network (the sub-network). It can also reset the gateway if 1. When it is started the first time, the Anybus X-gateway is set as slave on the secondary network. This can be changed during configuration, see “Enabling Data Exchange” on page 45. The module will remember its setting when restarted. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Anybus X-gateway CANopen - DeviceNet 5 needed. The master on the primary DeviceNet network can see the status of the secondary CANopen network in the corresponding status word. The amount of data that shall be exchanged, and the use of the control- and status functionality, is specified separately for each application. This means that even though up to 510 bytes of data can be forwarded to an interface, the amount of data that will actually be exchanged on the primary DeviceNet network is determined by settings of the secondary CANopen network, with consideration taken to the limits of the interface. The available control- and status functionality is described in “Data Exchange” on page 20. Also note that the terminology and definitions used for different types of data vary greatly between different networking systems. All data transported through the Anybus X-gateway CANopen is fast, cyclic data and is simply referred to as ‘I/O Data’ in this document. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 2 2. About the Anybus X-gateway CANopen 2.1 External View A: Status LEDs See also... - “Status LEDs” on page 7 A B B: Primary Network Connectors and Switches This connector (connectors) and, if available, these switches are used to connect the Anybus X-gateway CANopen module to the primary DeviceNet network and to configure that interface. They are described in “Primary Network” on page 8. C: USB connector This connector simulates a COM-port, used for software upgrade of the module. Please note that this connector can not be used for configuration of the module. C D See also... - “Secondary Network” on page 9 F E D: CANopen Connector This connector is used to connect the gateway to the secondary CANopen network. See also... - “CANopen Connector” on page 9 E: Power Connector This connector is used to apply power to the gateway. See also... - “Power Connector” on page 10 F: DIN-rail Connector The DIN-rail mechanism connects the gateway to PE (Protective Earth). See also... - “Hardware Installation” on page 11 Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 About the Anybus X-gateway CANopen 7 2.2 Status LEDs The status LEDs on the front indicate the status of the module as shown in the table below. Their behavior is described in “Status LED Timing Diagrams” on page 43 Status LEDs 1 - 4 indicate the status of the primary DeviceNet network and status LEDs 5 - 6 indicate the status of the secondary CANopen (sub)network and the device. # 1 - DeviceNet network status (NS) 2 - Module status (MS) 3-4 5 - CANopen subnetwork statusa 6 - Device status State Off Green Flashing Green Red Flashing Red Alternating Red/Green Off Green Red Flashing Red Alternating Red/Green (not used) Off Flickering green/red Blinking green Single flash, green On, green Blinking red Single flash, red Double flash, red Triple flash, red Quadruple flash, red Red Off Blinking green On, green Single flash, red Double flash, red Triple flash, red Quadruple flash, red On, red Status Not online Link OK, online, connected Online, not connected Critical link failure Connection timeout Device self-test in progress No power Operational Major fault Minor fault Device self-test in progress 1 2 3 4 5 6 Power off The LSS services are in progress Preoperational state Stopped state Operational state Configuration error Warning limit reached in CAN controller, e.g. bad or no signal on CANopen network Error control event Sync error Data communication timeout Bus off Power off Bootup Running Initialization error Internal timeout Hardware failure Invalid switch settings Fatal error a. This LED shows the status of the secondary CANopen network. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 About the Anybus X-gateway CANopen 8 2.3 Primary Network 2.3.1 DeviceNet Connector The DeviceNet connector (A) has the following pinout: # 1 Signal V- 2 3 4 5 CAN_L SHIELD CAN_H V+ Description Negative bus power supply CAN low Cable shielding CAN high Positive bus power supply 1 B 5 A 2.3.2 Switches Under the lid at B in the picture, configuration switches for baud rate and MACID are found. Baud Rate Configuration Switches 1 and 2 specifies the operating baud rate for the Adapter Interface as follows: Switch 1 OFF OFF ON ON Switch 2 OFF ON OFF ON Switch 3 - Switch 4 - Switch 5 - Switch 6 - Switch 7 - Baudrate 125 kbps 250 kbps 500 kbps (reserved) OFF ON Example: Switch 8 - Baud rate set to 250 kbps. MACID Configuration Switches 3 to 8 specifies the MACID for the Adapter Interface in binary format as follows: Switch 2 ... - Switch 3 OFF OFF OFF ... ON ON ON Example: Switch 4 OFF OFF OFF ... ON ON ON Switch 5 OFF OFF OFF ... ON ON ON Switch 6 OFF OFF OFF ... ON ON ON Switch 7 OFF OFF ON ... OFF ON ON Switch 8 OFF ON OFF ... ON OFF ON Mac ID 0 1 2 ... 61 62 63 ON OFF ON OFF ON OFF Switch 1 ... - MACID set to 42. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 About the Anybus X-gateway CANopen 9 2.4 Secondary Network 2.4.1 CANopen Connector At the bottom of the module you find the CANopen connector for the secondary network. Pin no. 2 5 7 1, 4, 8, 9 3, 6 Description CAN_L Housing, CAN cable shield CAN_H (reserved) CAN GND 1 6 5 (male) 9 This connector is also used to download the CANopen configuration to the module. 2.4.2 Configuration Switches 78 78 456 456 78 9 01 23 9 01 23 9 01 23 456 The on-board switches on the side of the module are used to set the CANopen node address and operating baud rate for the interface on the secondary network. These settings cannot be changed during runtime, i.e. the gateway must be restarted in order for any changes to have effect. A B C Note: When these switches have been set, cover them with the switch covers that accompany the module. Baud Rate The baud rate is set via switch A: Switch Setting 0 1 2 3 4 5 6 7 8, 9 Baud Rate(kbit/s) 20 50 125 250 500 800 1000 Autoa Not available a. The automatic baud rate setting should not be used if there is only a small amount of traffic on the bus. This occurs e.g. if the interface is configured as a CANopen master or if the secondary network is small. Node Address The node address is configured using two rotary switches as follows: Node Address = (Switch B x 10) + (Switch C x 1) Example: To set node address 42, set switch B to ‘4’ and switch C to ‘2’. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 About the Anybus X-gateway CANopen 10 2.5 USB Connector At the bottom of the module, next to the CANopen connector for the secondary network, you find a USB connector that is only used for software upgrade of the module. Pin no. 1 2 3 4 Housing Description +5 V input USBDM (USB communication signals) USBDP (USB communication signals) Signal GND Cable Shield 2 1 3 4 This port can only be used for software upgrade. 2.5.1 Power Connector Pin no. 1 2 Description 24 V DC GND 1 2 Notes: • • Use 60/75 or 75º C copper (CU) wire only. The terminal tightening torque must be between 5... 7 lbs-in (0.5... 0.8 Nm) See also... - “Power Supply” on page 41 Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 About the Anybus X-gateway CANopen 11 2.6 Hardware Installation Perform the following steps when mounting the gateway: 1. Set the Node Address and the baud rate for the secondary CANopen network (see “Configuration Switches” on page 9). 2. Set the Node ID and the baud rate the DeviceNet network (see “Switches” on page 8). 3. Snap the gateway on to the DIN-rail (See “External View” on page 6) The DIN-rail mechanism works as follows: 1 To snap the gateway on, first press it downwards (1) to compress the spring in the DIN-rail mechanism, then push it against the DIN-rail as to make it snap on (2). 2 1 To snap the gateway off, push it downwards (1) and pull it out from the DIN-rail (2), as to make it snap off from the DIN-rail. 2 4. Set the Node Address and the baud rate for the secondary CANopen network (see “Configuration Switches” on page 9). 5. Connect the gateway to the secondary CANopen network. 6. Set the configuration switches for the DeviceNet network. 7. Connect the gateway to the DeviceNet network. 8. Connect the power cable and apply power Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 About the Anybus X-gateway CANopen 12 2.7 CANopen Electronic Data Sheet (EDS) Each device on CANopen is associated with a CANopen Electronic Data Sheet (a.k.a EDS file), which holds a description of the device and its functions. Most importantly, the file describes the object dictionary implementation in the device. This file should be uploaded to the CANopen configuration tool when configuring the secondary CANopen network. The latest version of the EDS file for the Anybus X-gateway CANopen can be downloaded from the HMS web site, ‘www.anybus.com’. 2.8 DeviceNet Electronic Data Sheet (EDS) Each device in a DeviceNet network is associated with an Electronic Data Sheet (an EDS file), which describes the implementation of the product. This file is used by the network configuration tool during network configuration. The latest version of the EDS file for the Anybus X-gateway DeviceNet interface can be downloaded from the HMS web site, ‘www.anybus.com’. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 3 3. Getting Started The purpose of this chapter is to give a short description on how to install the module and get it up and running, transferring I/O data between the primary DeviceNet network and the secondary CANopen sub-network. Note: The CANopen (secondary) sub-network interface is configured prior to the primary DeviceNet network interface. The Anybus X-gateway CANopen - DeviceNet module has to be restarted after this configuration has been finished. Perform the following steps when installing the gateway: 1. Set the CANopen node ID and operating baud rate for the X-gateway on the secondary CANopen network (see “Configuration Switches” on page 9). 2. Set the DeviceNet baud rate and MAC ID, see “Primary Network” on page 8. 3. Snap the gateway on to the DIN-rail (see “Hardware Installation” on page 11). 4. Connect the gateway to the CANopen (secondary) sub-network, using the connector at the bottom of the module. 5. Connect the power cable and apply power. 6. Download the appropriate EDS file from HMS to the external CANopen configuration tool. See “CANopen Electronic Data Sheet (EDS)” on page 12. 7. Decide how much data will be transferred. This amount is always configured for the module’s interface to the secondary network. A description of how the data is mapped to the Anybus X-gateway CANopen is found in “I/O Buffer Addresses and Object Dictionary Indices Relation” on page 39. 8. Consult the “Enabling Data Exchange” on page 45 to configure the module and the secondary CANopen network. 9. Connect the gateway to the primary DeviceNet network. 10. Restart the gateway. 11. Download the appropriate EDS file from HMS. See “DeviceNet Electronic Data Sheet (EDS)” on page 12. 12. The actual configuration of the module is performed while configuring the DeviceNet master/ scanner and the DeviceNet network, see “Configuration of the DeviceNet Adapter Interface” on page 18. The I/O buffers of the module contains 512 bytes, but the amount of I/O data is decided by the CANopen configuration. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 4 4. CANopen Fieldbus Functionality The functionality of the Anybus X-gateway CANopen master/slave on the secondary network is defined by the CANopen DS301 Rev. 4.2 specification and DSP302 (part 1-5). Note: The first time the module starts up, it starts as a slave on the secondary CANopen network. It can be set as master during configuration, see “Enabling Data Exchange” on page 53. This setting can be saved in the module so that it will start as a master the next time. 4.1 Supported Fieldbus Services Communication and parameters in the CANopen protocol are built around objects. There are different services available to communicate with the objects and to perform other CANopen tasks like supervising the network. The following message types and objects are implemented in the Anybus X-gateway CANopen: 1. 2. • NMT (Network Management)1 messages configure and initialize the network, as well as monitor the network and handle errors. If the module is configured as a slave, startup is performed by a master on the network. • CMT (Configuration Manager)1 messages are used for configuration of CANopen devices. This primarily involves PDO parameters and mapping of information. If the module is configured as a slave, the configuration is performed by a master on the network. • PDOs (Process Data Objects) are used for I/O communication. There are 128 Receive PDOs and 128 Transmit PDOs implemented in the Anybus X-gateway CANopen that each can transfer up to 8 bytes. Supported PDO message types are COS (Change of state), Cyclic Synchronous and Acyclic Synchronous.2 • SDOs (Service Data Objects) use asynchronous data transmission and are used to access objects without mapping them to an I/O (PDO) connection. Access is provided to all CANopen objects in the module and in the network nodes (master mode). The SDO messages are used to configure the module and they can transfer more than 8 bytes, which is the upper limit for a PDO. (Expedited Upload/Download Protocol and Segmented Upload/Download Protocol are supported) • A SYNC (Synchronization Object) is used for synchronizing PDO communication. A master can be either a producer or a consumer of the synchronization. A slave can only be a consumer. • The Heartbeat Mechanism helps a device to monitor the status of another node. The module can appear both as heartbeat producer and consumer. • The Node Guarding Protocol provides active surveillance of a slave by the master. Slaves can be configured to expect a node guarding request from the master. • An EMCY (Emergency Object) is used for error reporting when a fatal fault has occurred in the module itself or in other monitored/supervised modules. • LSS (Layer Setting Services)1. An LSS master can configure baud rate and node ID of all slaves that support LSS (i.e. the preconfigured baud rate and node ID of a slave can be changed by a master). Only available when the module is configured as master. The data exchange with the DeviceNet network is limited to 512 bytes, affecting the total number of PDOs that can be used in an application. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 5 5. Configuration This chapter describes the configuration of the secondary CANopen network interface as well as the configuration of the primary DeviceNet network adapter/slave interface of the module. The secondary CANopen network interface is configured prior to the primary DeviceNet network adapter/slave interface. The I/O data sizes configured for the secondary CANopen network decides the data sizes on the primary DeviceNet network adapter/slave interface. 5.1 Module Identification The Anybus X-gateway CANopen to DeviceNet module identifies itself on the network as follows: Description Vendor Code Vendor Name Product Code Product Type Product Type String Product Name Catalog Desc Text Value 90 “HMS Industrial Networks AB” 49 12 “Communications Adapter” “Anybus X-gateway CANopen” “Anybus X-gateway CANopen” “Anybus X-gateway CANopen” Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Configuration 16 5.2 CANopen Master/Slave Configuration The nodes on the secondary CANopen network, including the interface of the Anybus X-gateway on this network, have to be configured using an external CANopen configuration tool running on a computer. The configuration is downloaded to the secondary CANopen network master using a CANopen adapter.1 The module is by default configured as a slave at startup. To enable it to perform as a CANopen master, please set this during configuration, see “Enabling Data Exchange” on page 45 and “NMT Start-up, 1F80h” on page 32. The following parameters have to be defined: Parameter Node Number Description Node ID on the secondary CANopen Network. Allowed values are 1 - 127. Values 1-127 Baud rate This parameter defines the baud rate on the secondary CANopen network. If “Auto” is selected the baud rate will be automatically detected. 20 kbit/s 50 kbit/s 125 kbit/s 250 kbit/s 500 kbit/s 800 kbit/s 1000 kbit/s Auto Set master Set the module to be CANopen master. At startup the module is a slave by default. This can be changed during configuration. This parameter defines the size of the reada- 2 - 512a ble data array on the primary network interface. Data to the primary network from the secondary CANopen network. CANopen input data size CANopen output This parameter defines the size of the writa- 2 - 512a data size ble data array on the primary network interface. Data from the primary network interface to the secondary CANopen network. Comment Node ID (1-99) is set using rotary switches, see “Configuration Switches” on page 9. Node IDs above 99 can be set using the configuration tool or from the CANopen network. Set using rotary switches, see “Configuration Switches” on page 9 Automatic baud rate should only be used if the module is used as a slave on the secondary network. See “NMT Start-up, 1F80h” on page 32. The first 2 bytes in the array are used for the status word, so the maximum data size from the secondary CANopen network is 2 bytes less than the maximum value allowed for this parameter. See object 3000h on page 40. The first 2 bytes in the array are used for the control word, so the maximum data size to the secondary CANopen network is 2 bytes less than the maximum value allowed for this parameter. See object 3001h on page 40. a. The data buffers in the Anybus X-gateway CANopen module can hold 512 bytes of data, but the actual maximum data size is highly dependent on network. Please consult the section on configuration of the controlling network further on in this chapter. Note: The input and output data sizes are configured for the secondary CANopen network interface. The master of the primary network will have to take these values into consideration, as they will be used by the primary DeviceNet network adapter/slave interface of the module. 1. Please contact HMS support for further information, see “Sales and Support” on page 1. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Configuration 17 5.3 Secondary CANopen Network Configuration An external CANopen configuration tool is used to configure the nodes on the secondary CANopen network. Each node can be configured locally or a Concise DCF file can be downloaded to the CANopen network master using a CANopen adapter1. At the next startup the CANopen master will configure the network, if this function was set in the configuration tool during initial configuration. The first time the Anybus X-gateway CANopen is started it starts up as a slave. It can be configured as a master, and if it is, it will continue to start up as a master. 1. Download the EDS file2 for the Anybus X-gateway CANopen from www.anybus.com to your PC. 2. Prepare EDS files for all other nodes present on the secondary network. 3. Open the CANopen configuration tool. 4. Upload the EDS files to the configuration tool. 5. Add nodes to the CANopen network. 6. Configure each node with the necessary parameters. 7. Set Input Data Size in object 3000h and Output Data Size in object 3001h, to define the I/O data size between the secondary CANopen network (sub-network) and the primary DeviceNet network (slave interface). Default values are 16 bytes (14 bytes of data exchanged between the networks + 2 bytes Control/Status Word). See “General Fieldbus Parameters” on page 40. 8. Download the configuration to the CANopen network as Concise DCF to the master or store the configuration locally in each module’s nonvolatile memory. Please consult the user manual for the configuration tool for details and/or contact HMS support, see “Sales and Support” on page 1. For an example, see “Enabling Data Exchange” on page 45. To configure the primary DeviceNet adapter/slave interface, restart the module, and then configure the DeviceNet network using appropriate configuration tools, see below. Please remember that the amount of data that can be exchanged already is decided by the previous configuration of the secondary CANopen network (CANopen objects 3000h and 3001h). The first two bytes of the input data and the output data are always used for status and control information. 5.3.1 LSS Routine If there is a missing slave on the network after the boot timeout (defined in object 1F89h, page 36) the master will initiate the LSS routine. It will send an identify slave request. If one (and only one) slave responds to that message, the master sets the NodeID of that node to the first available NodeID. The master will then send a bootup request to the slave. 1. 2. Please visit www.anybus.com or contact HMS support for further information, see “Sales and Support” on page 1. The EDS file for the Anybus X-gateway CANopen can be downloaded from www.anybus.com. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Configuration 18 5.4 Configuration of the DeviceNet Adapter Interface After the configuration of the CANopen interface has been finalized, the module has to be restarted before the configuration of the DeviceNet adapter interface can be started. The adapter interface is part of a DeviceNet network, and will have to be configured within this. The configuration tool used when configuring the DeviceNet master/scanner and the DeviceNet network will thus have to be used to configure the adapter interface as well. The data arriving from the CANopen master is completely transparent. The interpreting has to be defined by the master of the slave interface.Please note that the size of the I/O data that can be read from and written to the module is defined when configuring the CANopen interface. There are a number of different configuration tools for DeviceNet available on the market. The choice of tool depends on the application and the DeviceNet scanner of the network. An EDS file for the adapter interface is available at ‘www.anybus.com’. An application note, describing how to configure an Anybus DeviceNet adapter/slave interface with RS NetWorx for DeviceNet, is available on the support pages for the Anybus X-gateway CANopen to DeviceNet module at ‘www.anybus.com’. 5.4.1 DeviceNet Baud Rate and MACID Configuration The operating baud rate for the DeviceNet adapter interface is specified by DeviceNet switches 1 and 2, see “Baud Rate Configuration” on page 8. Switches 3 to 8 specify the MACID for the adapter interface in binary format, see “MACID Configuration” on page 8. 5.5 Enabling Data Exchange Once both the interfaces of the X-gateway have been properly configured, the PLC (the master) on the primary network will have to explicitly allow the X-gateway to exchange I/O data, for any I/O data exchange to occur between the primary and secondary networks. To accomplish this, the PLC will write the command “OPERATIONAL” in the control word, see “Control Word” on page 21 for further information. If the module is set as master, it will automatically be available, when the PLC has enabled data exchange. The module will contol the secondary network, using the instructions sent in the control word form the PLC. If the module is set as a slave, it will wait for a request form the master of the seondary network before starting to exchange data. If it has not been enabled by the PLC to exchange data, it will return an error message to the secondary network. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 6 6. CANopen Module Specification 6.1 NMT State Machine The function of the Anybus X-gateway CANopen can be described as a state machine with four states. Power on Initialization Pre-operational Stopped Operational State Initialization Pre-operational Operational Stopped Description When the power is switched on, the module starts initializing. The parameters are set to the so called power-on values, which are the default values or the latest stored values. If parameter values are stored from a previous configuration, these are used. If not, or if a restore_default command is issued, the parameters are reset to the default values according to the communication and device profile specifications. Once initialized, the module automatically enters the pre-operational state. The Anybus Xgateway CANopen can be configured, but no I/O data can be exchanged. In the operational state all communication objects are active. I/O data is communicated according to the configuration made. All communication is stopped, except node guarding and heartbeat, if active. From this state any transition to another state is possible, depending on if a restart, reconfiguration or reset of the module is wanted. The module changes states upon reception of a request from an NMT object, a hardware reset or Module Control Services locally initiated by application events. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 20 6.2 Data Exchange The Anybus X-gateway CANopen allows for the exchange of 512 bytes of data in each direction between the primary network and the X-gateway. The first two bytes (the first word) are allocated for a Control/Status word, decreasing the size of I/O data for CANopen to 510 bytes. The actual amount of data that can be exchanged is highly network dependent, see the section on configuration of the primary DeviceNet network in chapter 5. The control and status words of the module are used by the master of the primary DeviceNet network to control the Anybus X-gateway CANopen and the secondary CANopen network, and to report the status back from this network. The rest of the I/O data area is available in the CANopen vendor specific object area for real-time data transfer using PDOs (Process Data Objects). Note: The functionality of the Control/Status word differs depending on if the Anybus X-gateway CANopen interface is configured as a slave or as a master on the secondary network. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 21 6.2.1 Control Word The control word is used to control the CANopen network of the Anybus X-gateway CANopen. It is triggered on a CoS (Change of State) event. Control Word Byte 0 Toggle bita Cmd, 3 bits Byte 1 CmdExt, 4 bits NodeIDb Effective I/O Data Byte 2 - 510 Data a. The most significant bit in byte 0 is a toggle bit, that is toggled by the controlling network each time a new command is issued. b. If NodeID = 0, the command is valid only for the node that the module constitutes. If NodeID = 128 (80h), the command is valid for the complete secondary CANopen network. Any other NodeID value will specify the single node that the command is valid for. If the Anybus X-gateway CANopen interface is configured as a slave on the secondary network the only allowed value of NodeID is 0. Supported commands The table below shows available commands and their representation in byte 0 of the control word. Toggle Cmd (3 bits) bita 0h CmdExt Name (4 bits) 0h 1h 2h 3h 4h 5h - Fh (Set NMT State) PRE-OPERATIONAL OPERATIONAL RESET NODE RESET COMMUNICATION STOP - 1h Get Node state 2h Get COPM general status 3h - 6h 7h (reserved) (No operation) Master functionality Slave functionality This command sets the NMT state of a CANopen node or the CANopen network, according to the value of NodeID. The NMT state is set by the controlling PLC. If the PLC is running, the NMT state is set to OPERATIONAL. If the PLC is not running, the NMT state is set to PRE-OPERATIONAL.b (reserved) Default: PRE-OPERATIONAL This command requests the state set in object 1F82h, see 34, of the CANopen node or network (depending on the value of NodeID).c d This command requests the general status of the CANopen module No Operation It is recommended to set Cmd to this value, when the module goes offline from the fieldbus. This prevents unwanted behavior of the CANopen network, when the fieldbus comes back online. a. The most significant bit in byte 0 is a toggle bit, that is toggled by the controlling network each time a new command is issued. b. IMPORTANT: The PLC controlling the primary network has to set the X-gateway to OPERATIONAL using the Control Word. If this has not been done, the X-gateway will decline an NMT Set Operational Command on the secondary network by returning an emergency message with the error code FF10h. The same emergency message will be sent when the X-gateway is reset to PRE-OPERATIONAL by the primary network. c. If the module is configured as slave, only NodeID = 0 is allowed. d. Only states of nodes monitored by node guarding or heartbeat can be read from object 1F82h. When started, the module will initialize, and then automatically continue to the state PRE-OPERATIONAL. I/O data will only be exchanged if the module is in the state OPERATIONAL. To make this possible, the PLC controlling the primary network will have to give the command “Set NMT State (OPERA- Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 22 TIONAL)” in the control word. If the module is set as master, it will then administer the secondary network. If the module is set as slave, it will answer to any request from the master of the secondary network to participate in the communication on that network (see footnote in the table above). The command RESET NODE will restore the module to a previously downloaded configuration. RESET COMMUNICATION will restore the communication settings of the module. In both cases the module will return to the INITIALIZATION state. Examples Master/ Control Worda Meaning Slave Slave 01 00h 01h: Allow the module to go to OPERATIONAL if asked by an NMT master. 00h: The command is only valid for the module itself. Master 01 80h 01h Start remote node in the secondary network. 80h The command is valid for all nodes in the secondary network. 01 02h 01h Start remote node. 02h The command is valid for node 2. 04 80h 04h Stop remote node. 80h The command is valid for all nodes in the secondary network. a. The first bit in the control word is toggled for each new command, e.g. changing the first byte from 01h to 81h 6.2.2 Status Word Byte 0 in the status word shows the last valid command and command extension written to the control word, to indicate that the command has been performed. Byte 1 gives the lowest NodeID with error. Please note that there can be one or more nodes, with higher NodeIDs, that also have errors. If NodeID is 0, all nodes are fine. If NodeID is for example 5, it means that there is an error with node 5. Only errors from nodes monitored by the heartbeat mechanism or by node guarding will be reported. Errors from other slaves can not be recognized. Status Word Byte 0 Toggle bita Cmd Rsp, 3 bits Effective I/O Data Byte 1 Byte 2 - 510 CmdExt, 4 bits Error Node Data a. The most significant bit in byte 0 is a toggle bit, that is toggled by the module to mirror the toggle bit of the control word. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 23 Supported commands The table below shows available command responses and their representation in byte 0 of the status word. Toggle CmdRsp CmdExtRsp (3 bits) (4 bits) bita 0h 0h 1h 2h 3h 4h 5h - Fh 1h 0h 1h 2h 3h 4h 5h 6h 7h - Eh Fh 2h Bit: 3h - 6h 7h 0 1 2 3 (reserved) - Name Master Slave (Set NMT State) PRE-OPERATIONAL OPERATIONAL RESET NODE RESET COMMUNICATION STOP (Get Node state) PRE-OPERATIONAL OPERATIONAL RESET NODE RESET COMMUNICATION STOP UNKNOWN MISSING ERROR (Get COPM general status) Response to Set NMT State command. Reflects the command. Response to Set NMT State command. Reflects the command. (reserved) This response reflects the state set in object 1F82h, see 34, of a CANopen node or network (depending on the value of NodeId). This response reflects the state set in object 1F82h, see 34, of the module’s CANopen interface. CAN_BUS_OFF CAN_ERR_PASV ERR_NG_HB ERR_SYNC This response requests the CANopen status of the module Bus off Error passive Node guarding or Heartbeat error Sync error (No operation) Reflects the command a. The most significant bit in byte 0 is a toggle bit, that is toggled by the module to mirror the toggle bit of the control word. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 24 6.2.3 Example The example shows two control words from the primary network master to the module. Each control word includes a command that affects the secondary CANopen network. Each control word is acknowledged by a status word, that contains a response to the command. Note that the first bit in the control word is toggled when a new command is sent, to make sure it is distinguished from the previous command. Primary network master Command (Set node with Node ID 2 to OPERATIONAL) Anybus X-gateway CANopen module Control word [0x 01 0x02] Command 01 0x00] Status word [0x Response Response Control word [0x 01 0x02] (*) New command (Set node with Node ID 3 to OPERATIONAL) 01 0x00] Status word [0x Control word [0x 81 0x03] Command 81 0x00] Status word [0x Response Response (*) The communication is performed in an ongoing ping-pong fashion. The same command is sent repeatedly, but as long as the toggle bit is not changed, the module will ignore the message. A new command is signalled by the toggle bit changing value. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 25 6.2.4 PDO Functionality Real-time data transfer is performed by means of PDOs (Process Data Objects). The PDOs are linked to entries in the Device Object Dictionary and provide the interface to the application objects. The number and length of PDOs in a device are node specific and have to be configured by the CANopen configuration tool. PDOs are used both for data transmission and reception, using so called Transmit-PDOs (TPDOs) and Receive-PDOs (RPDOs). Each PDO corresponds to two entries in the Device Object Dictionary. The PDO parameter object holds information on the COB-ID, the transmission type etc. On recognition of the COB-ID the corresponding PDO mapping object can be identified, to make it possible to transmit/ receive data to/from the correct object in the device. The default settings for the mapping can be changed during configuration. Default PDO Mapping Scheme The module features a simple default mapping scheme with 44 TPDOs and 4 RPDOs. • RPDO RPDO no. 1 2 3 4 5 ... 128 • Default COB IDs 200h + Node ID 300h + Node ID 400h + Node ID 500h + Node ID 80000000h Mapped to... Object index 2100h, subindex 1... 8 Object index 2100h, subindex 9... 16 Object index 2100h, subindex 17... 24 Object index 2100h, subindex 25... 32 Object index 2100h, subindex 33... 40 ... Object index 2103h, subindex 121 ... 126 Relating to... Receive bytes 2... 9 Receive bytes 10...17 Receive bytes 18... 25 Receive bytes 26... 33 Receive bytes 34... 41 ... Receive bytes 506... 511 Mapped to... Object index 2000h, subindex 1... 8 Object index 2000h, subindex 9... 16 Object index 2000h, subindex 17... 24 Object index 2000h, subindex 25... 32 Object index 2000h, subindex 33... 40 ... Object index 2003h, subindex 121 ... 126 Relating to... Transmit bytes 2... 9 Transmit bytes 10... 17 Transmit bytes 18... 25 Transmit bytes 26... 33 Transmit bytes 34... 41 ... Transmit bytes 506... 511 Default State Enabled Disabled TPDO TPDO no. 1 2 3 4 5 ... 128 Default COB IDs 180h + Node ID 280h + Node ID 380h + Node ID 480h + Node ID 80000000h Default State Enabled Disabled For more information on the mapping see “Vendor Specific Objects” on page 36 Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 26 RPDO Transmission Types The RPDOs can be received either in synchronous or asynchronous mode. A synchronization (SYNC) object is transmitted periodically by a synchronization master. The data in synchronous RPDOs are not transferred to the application until after the next SYNC object is received. Asynchronous RPDOs will be transferred directly. The transmission type parameter of a RPDO specifies the triggering mode. Transmission type, RPDO 0 - 240 241 - 253 254 - 255 (Default = 255) Mode RPDO transmission description Synchronous Event driven A received RPDO is transferred to the application after a SYNC object is received. Reserved An RPDO is transmitted without any relation to the SYNC object. TPDO Transmission Types The TPDOs can be transmitted either in synchronous or asynchronous mode. A synchronization (SYNC) object is transmitted periodically by a synchronization master. Synchronous TPDOs are transmitted within a predefined time-window immediately after a configured number of SYNC objects, or after the SYNC object that follows upon a CoS (Change of State event). Asynchronous TPDOs can be transmitted at any time, triggered by a CoS or a cyclic period set in the Event Timer. The transmission type parameter of a TPDO specifies the transmission mode as well as the triggering mode. Transmission type, TPDO 0 1 - 240 241 - 253 254 - 255 (Default = 255) Mode TPDO transmission description Synchronous, acyclic Synchronous, cyclic Event driven A TPDO is triggered by an event, but not transmitted before the occurrence of a SYNC object. A TPDO is transmitted with every n-th SYNC object, where n is a defined number from 1 - 240. Reserved A TPDO is transmitted without any relation to the SYNC object. The transmission is triggered by a CoS event or if a specified time has elapsed without an event. 6.3 LSS Services LSS master functionality according to the CANopen DS305 specification is supported by the module. The module can configure baud rate and node ID of all slaves that support LSS (i.e. the preconfigured baud rate and node ID of a slave can be changed by a master). The module can not act as an LSS slave. An LSS Slave is identified by its LSS address, that consists of Vendor ID, Product Code, Revision Number and Serial Number of the LSS slave module. If there is a missing slave on the network after the boot timeout, the master will initiate the LSS routine, see Network Management Object “Boot Time, 1F89h” on page 36. It will send an identify slave request, using the LSS address of the slave. If one (and only one) slave responds to this request, the master will set the NodeID on that node to the first missing NodeID. It will then send a bootup message to the node. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Module Specification 27 6.4 Error Control It is strongly recommended to monitor the network. The Anybus X-gateway CANopen can use either Heartbeat or Node Guarding. At an error event from any of these, the active I/O data is frozen, as no new data will be available. 6.4.1 Heartbeat Mechanism The Heartbeat Mechanism is used to monitor the nodes in the network and verifies that the nodes are available. A heartbeat producer periodically sends a message. The data part of the frame contains a byte indicating the node status. The heartbeat consumer reads these messages. If a message fails to arrive within a certain time limit (defined in the object directory of the devices, objects 1016h and 1017h, 29), a heartbeat event is registered by the consumer. The ERROR LED on the front of the Anybus X-gateway CANopen and the status word will indicate the event. An EMCY object (8130h) is also transmitted on the CANopen fieldbus. If the module is configured as a slave and is in OPERATIONAL state, it will go to PRE-OPERATIONAL state and wait for the user to take action. If it is in master mode, it will take action according to the settings in the master objects. The Anybus X-gateway CANopen can act both as heartbeat consumer and as heartbeat producer simultaneously. 6.4.2 Node Guarding The NMT Master transmits guarding requests. If an NMT Slave has not responded within a defined time span (node lifetime) or if the communication status of the slave has changed, the master takes appropriate action according to its configuration. If Life guarding (the slave guards the master) is supported, the slave uses the guard time and lifetime factor from its Object Dictionary to determine the node lifetime. If the slave does not receive a guarding request within its lifetime, a node guard event is registered. The ERROR LED on the front of the Anybus X-gateway CANopen will indicate the event. An EMCY object (8130h) is also transmitted on the CANopen fieldbus. If the guard time or the lifetime factor are 0 (default), the Slave does not guard the Master. The guarding can be initiated at boot-up or later. Note: The NMT master can monitor a slave either by heartbeat or by node guarding. Only one of these mechanisms at a time can be active. Heartbeat is preferred and if heartbeat is enabled in a slave, any node guarding for that slave is disabled. 6.4.3 Emergency Object (EMCY) The Emergency Object is used for error reporting on the CANopen network when a fatal fault has occurred. The error codes are saved in a list in the Communication Profile Object 1003h, see page 28, and a message is produced on the CANopen network. A list of emergency error codes, that can be produced by the module, is available in “CANopen Emergency Codes” on page 44. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Chapter 7 7. CANopen Supported Objects The following sections describe the CANopen objects (secondary CANopen network), according to DS301 and DS302, implemented within the module and described in the EDS file. 7.1 Static Data Types The Static Data Types are implemented according to the DS321 specification from CiA (CAN in Automation). 7.2 Communication Profile Area 7.2.1 DS301 Communication Profile Objects The table below shows the objects according to CANopen specification DS301 rev. 4.2. Index Object Name 1000h Device Type 1001h Error register Subindex 00h 00h 00h 00h Description Type of device Error register, connected to the EMCY object. Bit 0 indicates a generic error Number of errors. Writing a 0 to this subindex clears the error list. List of errors. Most recent error at top of list. ID of the sync message Communication cycle period 1003h Predefined error field 00h U32 U32 RW RW Only available if SYNC support is enabled 00h Synchronous Window Length U32 RW 00h The name of the CANopen module Manufacturer hardware version Visible RO string Visible RO string Only available if SYNC support is enabled “Anybus X-gateway CANopen” 00h Manufacturer software version Visible RO string 00h Used together with “Life time U16 factor” to decide the node lifetime in ms If the node has not been U8 guarded within its lifetime (“Life time factor”*”Guard time”), an error event is logged and a remote node error is indicated 01h...10h 1005h COB-ID Sync 1006h Communication Cycle Period 1007h Synchronous Window Length 1008h Manufacturer device name 1009h Manufacturer hardware version 100Ah Manufacturer software version 100Ch Guard time 00h 100Dh Life time factor 00h Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Type U32 U8 Access Notes RO 0000 0000h (No profile) RO - U8 RW U32 RO See “CANopen Emergency Codes” on page 44 for emergency error codes. Current hardware revision Set by HMS RW 0000h (default) RW 00h (default) Doc.Id. HMSI-168-83 CANopen Supported Objects 29 Index Object Name Subindex 1010h Store Parame- 00h ters 01h Description Largest subindex supported Store all parameters Type U8 U32 1011h Restore Param- 00h eters 01h Largest sub index supported Restore all parameters U8 U32 1014h COB-ID EMCY 00h Defines the COB-ID of the U32 Emergency Object Largest subindex supported U8 The consumer heartbeat time U32 defines the expected heartbeat cycle time and has to be higher than the corresponding producer heartbeat time. Monitoring starts after the reception of the first heartbeat. Not used if 0 1016h Consumer 00h Heartbeat Time 01h - 80h 1017h Producer Heart- 00h beat Time 1018h Identity object 00h 01h 02h Access Notes RO 01h RW To save a configuration, write “save” = 73 61 76 65h to this object.a See also “General Fieldbus Parameters” on page 40. RO 01h RW To restore the default values of a configuration, write “load” = 6C 6F 61 64h to this object.a RO RO RW 7Fh Node ID + Heartbeat Time. Bits 31-24: reserved Bits 23-16: Node ID Bits 15-0: Heartbeat Time Value must be a multiple of 1 ms. Up to 127 nodes can be monitored. The time must be at least 10 ms and a multiple of 1 ms 04h 1Bh (HMS Industrial Networks) 18h (Anybus X-gateway CANopen) Current software revision HMS serial number Defines the cycle time of the heartbeat. Not used if 0 Number of entries Vendor ID Product Code U16 RW U8 U32 U32 RO RO RO 03h 04h 00h 01h Revision Number Serial Number Number of entries Communication error U32 U32 U8 U8 RO RO RO RO 02h Profile or manufacturer specific error U8 RO 1400h Receive PDO ... parameter 147Fh 00h 01h 02h Largest subindex supported COB-ID used by PDO Transmission type U8 U32 U8 RO RW RW 1600h Receive PDO ... mapping 167Fh 00h No. of mapped application objects in PDO Mapped object #1 Mapped object #2 Mapped object #3 Mapped object #4 Mapped object #5 Mapped object #6 Mapped object #7 Mapped object #8 U8 RW 00h: Change to Preoperational if currently in NMT state Operational 00h: Change to Preoperational if currently in NMT state Operational 02h See “RPDO Transmission Types” on page 26 - U32 U32 U32 U32 U32 U32 U32 U32 RW RW RW RW RW RW RW RW - 1029h Error behavior object 01h 02h 03h 04h 05h 06h 07h 08h Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 30 Index Object Name 1800h Transmit PDO ... parameter 187Fh 1A00h Transmit PDO ... mapping 1A7Fh Subindex 00h 01h 02h Description Largest subindex supported COB-ID used by PDO Transmission type Type U8 U32 U8 Access RO RW RW 03h 05h 00h Inhibit time Event Timer (ms) No. of mapped application objects in PDO Mapped object #1 Mapped object #2 Mapped object #3 Mapped object #4 Mapped object #5 Mapped object #6 Mapped object #7 Mapped object #8 U16 U16 U8 RW RW RW Notes 05h See “TPDO Transmission Types” on page 26 In steps of 0.1 ms - U32 U32 U32 U32 U32 U32 U32 U32 RW RW RW RW RW RW RW RW - 01h 02h 03h 04h 05h 06h 07h 08h a. Depending on the method of writing to this object, e.g. using a CANopen dongle, the byte order may have to be changed to adapt to the way data is transported on CANopen. 7.2.2 Configuration Manager DS302 part 3: Configuration and program download Network Configuration Objects Index Object Name 1F22h Concise DCF 1F25h Configure Slave Subindex Description Type The concise/compressed DCF files informa- Domain tion is stored in this object. 0 - 128 Subindex 0 is ignored. U32a Subindex i (i = 1 - 127): Request reconfiguration of slave with Node ID equal to subindex i. Subindex 128: Request to reconfigure all slaves. Access RW Sub 0: RO Sub 1 - 128: WO a. To configure the slave with Node ID i, write “conf” = 63 6F 6E 66h to this object (1F25h, subindex i). If this fails, an emergency code is produced (6161h, see “CANopen Emergency Codes” on page 44). Check Configuration The Configuration Manager (CMT) compares signature and configuration with the value from the DCF to decide if a reconfiguration is to be performed or not. The comparison values are stored by the Configuration Manager in these objects: Index 1F26h 1F27h Object Name Subindex Expected 0 - 127 Configuration Date Expected 0 - 127 Configuration Time Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Description Type The date that the Configuration Manager expects to find UNIT32 when comparing signature and configuration. Access RW The time that the Configuration Manager expects to find UINT32 when comparing signature and configuration. RW Doc.Id. HMSI-168-83 CANopen Supported Objects 31 7.2.3 Network Management Objects The NMT master controls the states of the connected network participants, the NMT slaves. It monitors the devices and reports to the application, for example if an NMT slave fails. Please refer to the CANopen specification, see “Related Documents” on page 1. In more complex systems several devices are able to perform as master, which means that the configuration must have an entry defining which device will act as master. Once configured, the objects carry all information needed for the module to act on the network and the application does not need to be accessed to obtain this information. This results in a substantial reduction of the overall implementation and maintenance effort when implementing multiple applications. Index Object Name 1F80h NMT Start-up Subindex Description Defining whether the device is the NMT Master 1F81h Slave Assign- ARRAY Module list: Entry of all slaves to ment be managed, including guarding values and the entry of actions to be taken in event of guarding errors. 1F82h Request NMT ARRAY Remote control initiation of NMT services. For example, tools can use this to request intentional start/ stop of individual slaves. Remote query of the current state. 1F83h Request ARRAY Remote control start/stop of guardGuarding ing. Remote query of the current state 1F84h Device Type ARRAY Expected device types for the Identification slaves 1F85h Vendor Identifi- ARRAY Vendor identifications for the cation slaves 1F86h Product Code ARRAY Product codes for the slaves Type U32 Access RW U32 Sub 0: RO Sub 1 - 127: RW U8 Sub 0: RO Sub 1 - 127: RW Sub 128: WO U8 1F87h Revision Num- ARRAY ber 1F88h Serial Number ARRAY U32 Sub 0: RO Sub 1 - 127: RW Sub 128: WO Sub 0: RO Sub 1 - 127: RW Sub 0: RO Sub 1 - 127: RW Sub 0: RO Sub 1 - 127: RW Sub 0: RO Sub 1 - 127: RW Sub 0: RO Sub 1 - 127: RW RW 1F89h Boot Time VAR Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Revision numbers for the slaves U32 U32 U32 Expected serial numbers for the U32 slaves The maximum time between the U32 start of the boot process and the signalling of successful boot of all mandatory NMT slaves. After this time LSS services are initiated. Doc.Id. HMSI-168-83 CANopen Supported Objects 32 NMT Start-up, 1F80h If a device is to be set up as NMT Master, the master functionality must be enabled in this object. It configures the start-up behavior of the device, and how it will manage the slaves. Note: The Anybus X-gateway CANopen starts up as a slave (bit 0 = 0). For the module to perform as a master, change the value of this bit during configuration and save it to non volatile flash memory by issuing “save” command to subindex 01h in object 1010 (Store Parameters). The setting will take immediate effect, but if not saved, it will be lost at reset or repower. Bit No. 0 Value 0 1 1 0 1 2 0 1 3 0 1 4 0 1 5 6 0 1 7 - 31 - Description NMT Master functionality is disabled. Ignore the rest of the object, except for bits 1 and 3. Ignore object 1F81h. NMT Master functionality is enabled. The device is Master Start only explicitly assigned slaves (if bit 3 = 0) After boot-up, perform the service NMT Start Remote Node All Nodes (if bit 3 = 0) Automatically enter Operational state Do not enter Operational state automatically. Application will decide when to enter Operational state Start-up of slaves allowed (i.e. allowed to send NMT Start Remote Node command) Not allowed to send NMT Start Remote Node command. The application will start the slaves If a mandatory slave generates an Error Control Event, treat the slave individually If a mandatory slave generates an Error Control Event, perform NMT Reset All Nodes (including self) Notes Default Default Default Default If bit 6 = 1, ignore bit 4 If object 1F81h, bit 3 = 1, the network must not be restarted, if a mandatory slave could not be contacted. Not implemented If a mandatory slave generates an Error Control Event, treat the slave according to bit 4 If a mandatory slave generates an Error Control Event, send NMT Stop All Nodes (including self). Ignore bit 4 Reserved (0) Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 33 Slave Assignment, 1F81h This object defines which slaves the Master should monitor, control and/or configure. One entry is made for each assigned slave, with the subindex corresponding to the slave’s Node ID. Bit No 0 1 2 Value 0 1 0 1 3 0 1 4 5 6 7 0 1 - 8 - 15 16 - 31 Description Node with this ID is not a slave Node with this ID is a slave. After configuration the node will be set to Operational Reserved On an Error Control Event or on detection of a new slave, inform the application, but do NOT configure and start the slave On an Error Control Event or on detection of a new slave, inform the application and start the process “Start Boot Slave” Optional slave. The network may be started even if this node could not be contacted. Mandatory slave. The network must not be started if this node could not be contacted during the boot slave process Not implemented Not implemented Not implemented CANopen device may be used without reset to default CANopen device shall be reset to factory defaults by issuing a restore to defaults (object 1011h). 8 bit value for the RetryFactor 16 bit value for the GuardTime If a slave does not answer, the master will retry the request RetryFactor-1 times with an interval of GuardTime. Guarding will be performed only if non zero values are entered for Retry Factor and GuardTime. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 34 Request NMT, 1F82h Each node on the CANopen network can be controlled individually from the fieldbus application by sending this object. The subindex indicates what nodes the request affects: Subindex 0 i (with i = 1...127) 128 Description Largest subindex supported (128) Request NMT Service for the slave with Node ID i. Request NMT Service for all nodes The desired state is given as a numeric value when writing to or reading from the local object dictionary: Value 0 Write access - 1 - 4 5 6 7 127 STOP remote node START remote node RESET NODE RESET COMMUNICATION Enter PRE-OPERATIONAL Read Access NMT state unknown. The node is not configured and/or no node monitoring is activated. CANopen device is missing. The node with this Node ID is configured but the monitoring of the node has failed. NMT state STOPPED NMT state OPERATIONAL NMT state PRE-OPERATIONAL The entire network can be started with one command (subindex 128) Examples • Node 5 should be transferred to the OPERATIONAL state: An SDO write access with the value 5 is executed to object 1F82h subindex 5 in the local object dictionary. When an NMT command is sent, data is cleared. • All the nodes in the network should be transferred to the PRE-OPERATIONAL state: An SDO write access with the value 127 is executed to object 1F82h subindex 128 in the local object dictionary. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 35 Request Guarding, 1F83h Guarding can be initiated from the object dictionary in a similar way. Guarding is initiated with the values stored in “Slave Assignment, 1F81h” on page 33, provided that at the same time no parameters are entered for that node as a Heartbeat Consumer Note: This functionality is only supported in master mode. Subindex 0 i (with i = 1...127) 128 Value 1 0 Description Largest subindex supported (128) Request Guarding for the slave with Node ID i Request Start/Stop Guarding for all nodes. Write access Start guarding Stop guarding Access RO RW WO Read access Slave is guarded Slave is not guarded Example: • Guarding should be started for node 5 (500 ms, Life Time Factor 3): An SDO write access with the value 01F40301h is executed to object 1F81h subindex 5 in the local object dictionary. Guarding is activated by an SDO write access with the value 1 to object 1F83h subindex 5 in the local object dictionary. Bits 31 - 16 15 - 8 Value 01F4h (500) 03h 7-0 01h Explanation The interval with which node 5 will be guarded If node 5 does not answer the guarding will be repeated another RetryFactor -1 times (in this case twice) This value indicates that node 5 is a slave Device Type Identification, 1F84h Each node on the CANopen network is checked against its expected device type. The subindex indicates which node is checked: Subindex 0 i (with i = 1...127) Description Largest subindex supported (127) If the expected device type is not 0 or if the slave is set as mandatory, the module compares expected device type with actual device type (object 1000h, subindex 0) for the slave with Node ID i. If the expected device type is 0, this only gives information about the existence of a node, not which device type it is. If the value is not 0, it is compared to the value read from the node, and boot up of that slave is continued if they match. If they don’t match, the slave will stay in state PRE-OPERATIONAL. Vendor Identification, 1F85h Each node on the CANopen network is checked against its expected vendor. The subindex indicates which node is checked: Subindex 0 i (with i = 1...127) Description Largest subindex supported (127) Compares expected vendor with actual vendor (object 1018h, subindex 1) for the slave with Node ID i. Boot up of that slave is continued only if they match. If they don’t match, the slave will stay in state PRE-OPERATIONAL. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 36 Product Code, 1F86h Each node on the CANopen network is checked against its expected product code. The subindex indicates which node is checked. The node in question is only checked if data is other than zero: Subindex 0 i (with i = 1...127) Description Largest subindex supported (127) Compares expected product code with actual product code (object 1018h, subindex 2) for the slave with Node ID i. Boot up of that slave is continued only if they match. If they don’t match, the slave will stay in state PRE-OPERATIONAL. Revision Number, 1F87h Each node on the CANopen network is checked against its expected revision number. The revision number includes major and minor revision. For a match to occur the major revision has to be exactly the same and the minor revision of the module has to be greater than or equal to the expected minor revision number. The subindex indicates which node is checked. The node in question is only checked if data is other than zero: Subindex 0 i (with i = 1...127) Description Largest subindex supported (127) Compares expected revision number with actual revision number (object 1018h, subindex 3) for the slave with Node ID i. Boot up of that slave is continued only if they match according to the description above. Serial Number, 1F88h Each node on the CANopen network is checked against its expected serial number. The subindex indicates which node is checked. The node in question is only checked if data is other than zero: Subindex 0 i (with i = 1...127) Description Largest subindex supported (127) Compares expected serial number with actual serial number (object 1018h, subindex 4) for the slave with Node ID i. Boot up of that slave is continued only if they match. If they don’t match, the slave will stay in state PRE-OPERATIONAL. Boot Time, 1F89h The network master will wait the assigned time (in ms) for all mandatory slaves to boot. If not all mandatory slaves are ready after this time, the LSS routine will be started, see “LSS Services” on page 26. If the assigned time is 0, the master will wait endlessly. Value (ms) 0 >0 Description Default. No time limit for mandatory slaves to boot Time limit for mandatory slave to boot 7.3 Vendor Specific Objects Vendor specific objects are used to configure the PDOs to the shared memory area. One or several generic data object are connected to each PDO. This is configured during the configuration phase. Application data bytes 0 and 1, i.e. the first two bytes in the input and output buffers, are used for control and status words. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 37 7.3.1 Transmit Buffer This buffer contains data that is transmitted to the secondary CANopen network. Index 2000h 2001h 2002h 2003h 2010h 2011h 2020h Subindex - Type Access STRUCT Name Transmit Byte 1-128 0 1 2 ... 128 0 1 2 ... 128 0 1 2 ... 128 0 1 2 ... 126 0 1 2 ... 128 0 1 2 ... 127 0 1 2 ... 128 U8 U8 U8 ... U8 STRUCT U8 U8 U8 ... U8 STRUCT U8 U8 U8 ... U8 STRUCT U8 U8 U8 ... U8 STRUCT U8 U16 U16 ... U16 STRUCT U8 U16 U16 ... U16 STRUCT U8 U32 U32 ... U32 Number of entries (value=128) Transmit Byte 1 Transmit Byte 2 ... Transmit Byte 128 Transmit Byte 129-256 Number of entries (value=128) Transmit Byte 129 Transmit Byte 130 ... Transmit Byte 256 Transmit Byte 257-384 Number of entries (value=128) Transmit Byte 257 Transmit Byte 258 ... Transmit Byte 384 Transmit Byte 385-510 Number of entries (value=126) Transmit Byte 385 Transmit Byte 386 ... Transmit Byte 510 Transmit Word 1-128 Number of entries (value=128) Transmit Word 1 Transmit Word 2 ... Transmit Word 128 Transmit Word 129-255 area Number of entries (value=127) Transmit Word 129 Transmit Word 130 ... Transmit Word 255 Transmit Long 1-128 area Number of entries (value=128) Transmit Long 1 Transmit Long 2 ... Transmit Long 128 Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW Position in transmit data area (bytes) 2-129 (The first two bytes in the transmit data area are reserved for the Control Word.) 2 3 ,,, 129 130-257 130 131 ... 257 258-385 258 259 ... 385 386-511 386 387 ... 511 2-257 2-3 4-5 ... 256-257 258-511 258-259 260-261 ... 510-511 2-511 2-5 6-9 ... 510-511 (the last two bytes are padded with zeroes) Doc.Id. HMSI-168-83 CANopen Supported Objects 38 7.3.2 Receive Buffer This buffer contains data that is received from the secondary CANopen network. Index 2100h 2101h 2102h 2103h 2110h 2111h 2120h Subindex - Type Access STRUCT Name Receive Byte 1-128 area 0 1 2 ... 128 0 1 2 ... 128 0 1 2 ... 128 0 1 2 ... 126 0 1 2 ... 128 0 1 2 ... 127 0 1 2 ... 128 U8 U8 U8 ... U8 STRUCT U8 U8 U8 ... U8 STRUCT U8 U8 U8 ... U8 STRUCT U8 U8 U8 ... U8 STRUCT U8 U16 U16 ... U16 STRUCT U8 U16 U16 ... U16 STRUCT U8 U32 U32 ... U32 Number of entries (value=128) Receive Byte 1 Receive Byte2 ... Receive Byte 128 Receive Byte 129-256 Number of entries (value=128) Receive Byte 129 Receive Byte 130 ... Receive Byte 256 Receive Byte 257-384 Number of entries (value=128) Receive Byte 257 Receive Byte 258 ... Receive Byte 384 Receive Byte 385-510 Number of entries (value=126) Receive Byte 386 Receive Byte 387 ... Receive Byte 511 Receive Word 1-128 Number of entries (value=128) Receive Word 1 Receive Word 2 ... Receive Word 128 Receive Word 129-255 area Number of entries (value=127) Receive Word 129 Receive Word 130 ... Receive Word 255 Receive Long 1-128 area Number of entries (value=128) Receive Long 1 Receive Long 2 ... Receive Long 128 Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW RO RW RW ... RW Position in receive data area (bytes) 2-129 (The first two bytes in the receive data area are reserved for the Status Word.) 2 3 ,,, 129 130-257 130 131 ... 257 258-385 258 259 ... 385 386-511 386 387 ... 511 2-257 2-3 4-5 ... 256-257 258-511 258-259 260-261 ... 510-511 2-511 2-5 6-9 ... 510-511 (the last two bytes are padded with zeroes) Doc.Id. HMSI-168-83 CANopen Supported Objects 39 7.3.3 I/O Buffer Addresses and Object Dictionary Indices Relation Data in the transmit buffer (bytes 2 - 511, from the primary to the secondary CANopen network) are mapped to three different areas in the Local Object Dictionary. The same data is mapped to each area, but in different data types. For example: application data bytes 2 - 5 are mapped to byte object index 2000h, subindex 1 - 4, to word object index 2010h, subindex 1 - 2 and to double-word (long) object index 2020h, subindex 1. Data from the secondary to the primary CANopen network are handled similarly, but with indices starting at 2100h. Word object Index, subindex Byte object Index, subindex Transmit data area Byte 0 - 1 Control Byte 2 - 9 Byte 2 2000h, 1 Byte 10 - 17 Byte 3 2000h, 2 Byte 18 - 25 Byte 4 2000h, 3 Byte 26 - 33 Byte 5 2000h, 4 Byte 34 - 41 Byte 6 2000h, 5 Byte 7 2000h, 6 Byte 8 2000h, 7 Byte 9 2000h, 8 Byte 10 2000h, 9 Byte 11 2000h, 10 Byte 12 2000h, 11 Byte 13 2000h, 12 Byte 14 2000h, 13 Byte 15 2000h, 14 Byte 16 2000h, 15 Byte 17 2000h, 16 Byte 18 2000h, 17 Byte 19 2000h, 18 Byte 20 2000h, 19 Byte 21 2000h, 20 Byte 22 2000h, 21 Byte 23 2000h, 22 Byte 24 2000h, 23 Byte 25 2000h, 24 Byte 26 2000h, 25 Byte 27 2000h, 26 Byte 28 2000h, 27 Byte 29 2000h, 28 Byte 30 2000h, 29 Byte 31 2000h, 30 Byte 32 2000h, 31 Byte 33 2000h, 32 Byte 464 - 471 Byte 472 2003h, 83 Byte 472 - 479 Byte 473 2003h, 84 Byte 480 - 487 Byte 474 2003h, 85 Byte 488 - 495 Byte 475 2003h, 86 } } } } } } } } } } } } } } } } } } Long object Index, subindex 2010h, 1 2010h, 2 } 2020h, 1 } 2020h, 2 } 2020h, 3 } 2020h, 4 } 2020h, 5 } 2020h, 6 } 2020h, 7 } 2020h, 8 } 2020h, 119 } 2020h, 127 } 2020h, 128* 2010h, 3 2010h, 4 2010h, 5 2010h, 6 2010h, 7 2010h, 8 2010h, 9 2010h, 10 2010h, 11 2010h, 12 2010h, 13 2010h, 14 2010h, 15 2010h, 16 2011h, 111 2011h, 112 Byte 496 - 503 Byte 504 - 511 Byte 506 2003h, 121 Byte 507 2003h, 122 Byte 508 2003h, 123 Byte 509 2003h, 124 Byte 510 2003h, 125 Byte 511 2003h, 126 } } } 2011h, 125 2011h, 126 2011h, 127 *The last two bytes are filled up with zeroes Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 CANopen Supported Objects 40 Note 1: The picture shows the Transmit data area. The Receive data area has the same structure, but with indices for byte objects starting at 2100h. Note 2: The first two bytes are occupied by the control/status word, and are used internally by the Xgateway. These bytes should not be used for data exchange. See also “Control Word” on page 21 and “Status Word” on page 22. 7.3.4 General Fieldbus Parameters Index range 3000h-300Fh is allocated for general fieldbus parameters. Index 3000h Subindex 0 Type U16 3001h 0 U16 Access Name and Description Comment RW Input Data Size (size to DeviceNet) Valid values: 2-512a, default 16 RW Output Data Size (size from Devi- Valid values: 2-512b, default 16 ceNet) a. The first two bytes of the I/O input area are occupied by the Status Word. The rest is available for data exchange on the secondary CANopen (sub)network side, see “I/O Buffer Addresses and Object Dictionary Indices Relation” on page 39 for further information. Also note that the valid data range may differ depending on the slave interface. b. The first two bytes of the I/O output area are occupied by the Control Word. The rest is available for data exchange on the secondary CANopen (sub)network side, see “I/O Buffer Addresses and Object Dictionary Indices Relation” on page 39 for further information. Also note that the valid data range may differ depending on the slave interface. Note: Writing to object 1010h (Store Parameters, see 29), will verify the input/output data sizes, stored in these objects, against the current fieldbus limitations. If the data sizes do not comply, an error will be generated (error code 6600h, see “CANopen Emergency Codes” on page 44). 7.3.5 DeviceNet Specific Parameters Index range 3030h-303Fh is allocated for DeviceNet specific parameters. For this version of the module, they are not used and the index range is reserved for future use. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Appendix A A. Technical Specification A.1 Protective Earth (PE) Requirements The product must be connected to protective earth (PE) via the DIN-rail connector in order to achieve proper EMC behavior. HMS Industrial Networks does not guarantee proper EMC behavior unless these PE requirements are fulfilled. A.2 Power Supply Supply Voltage The gateway requires a regulated 24 V ±10 % DC power source. Power Consumption Typical: 100 mA at 24 V. Maximum: 150 mA at 24 V A.3 Environmental Specification A.3.1 Temperature Operating -25º to +55º Celsius (Test performed according to IEC-60068-2-1 and IEC 60068-2-2.) Non Operating -40º to +85º Celsius (Test performed according to IEC-60068-2-1 and IEC 60068-2-2.) A.3.2 Relative Humidity The product is designed for a relative humidity of 5 to 95% non condensing. Test performed according to IEC 60068-2-30. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Technical Specification 42 A.4 EMC (CE) Compliance EMC compliance testing has been conducted according to the Electromagnetic Compatibility Directive 2004/108/EC. For more information please consult the EMC compliance document, see product/support pages for Anybus X-gateway CANopen - DeviceNet at www.anybus.com. A.5 UL and ATEX Certification The Anybus X-gateway CANopen - DeviceNet is HazLoc, UL and cUL certified according to file no. E203255. For more information please consult www.ul.com. ATEX testing has been conducted according to Demko 11 ATEX 1062548. For more information please see product/support pages for Anybus X-gateway CANopen - DeviceNet at www.anybus.com. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Appendix B B. Status LED Timing Diagrams The LEDs on the front of the module change their behavior according to the status of the module. This appendix gives the timing diagrams for the different indications, described in “Status LEDs” on page 7. 50 ms On Flickering LED Off 50 ms On Blinking LED 200 ms 200 ms Off On Single flash LED 200 ms 1000 ms Off On Double flash LED 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 200 ms 1000 ms Off On Triple flash LED 1000 ms Off On Quadruple flash LED 200 ms 200 ms 1000 ms Off When LSS services are in progress, both the ERR LED (red) and the RUN LED (green) are flickering. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Appendix C C. CANopen Emergency Codes Below is a list of the CANopen emergency codes that can be produced by the Anybus X-gateway CANopen. The error codes, that have been produced, can be read from the list in the Communication Profile Object at index 1003h, see 28. Error Code 0000h 6161h 6600h 8110h 8120h 8130h 8140h 8210h 8220h FF10h Description Error reset or no error. Software error, only valid in master mode. For additional information, see table below. Hardware error CAN overrun (objects lost). CAN in error passive mode. Life guard error or heartbeat error. Recovered from bus off. PDO not processed due to length error. PDO length exceeded. (Only valid in slave mode) The control word has been set to no longer allow the module to enter OPERATIONAL state, but the sub-network is in OPERATIONAL state or a CANopen master attempts to set the module in OPERATIONAL state, while the control word is set not to allow OPERATIONAL state. These codes conform to the CANopen standard. Software error codes (6161h) When an emergency code 6161h is produced, additional information is stored in the Communication Profile Object, index 1003h. 31 16 15 Additional Information Error Code Node Id (if available) Error code 00h 01h 02h 03h 04h 05h 06h 07h 08h 0 Emergency error code 61h 61h Description No software error detected. Tag for CMT record not available. Cache management inconsistent. SDO could not be transmitted. Configuration entry inconsistent. Check sum error. Data could not be written to non-volatile memory. SDO timeout. SDO error. Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83 Appendix D D. Enabling Data Exchange To enable the X-gateway to exchange data with the primary network, the PLC controlling the primary network will have to add, initialize and set the fieldbus interface of the module in operational mode. To start the data exchange with the secondary network, the command “OPERATIONAL” must be sent from the primary network to the secondary network, using the Control Word. If the module is set as slave, this will allow the the module to receive and accept a request from the NMT master of the secondary network to participate in the communication on the secondary network. The module will return an error message if it is not set to OPERATIONAL by the primary network. If the module is set as master, it will control the operational states of all nodes on the secondary network via the control word. See also .... • “Enabling Data Exchange” on page 19 • “Control Word” on page 23 • “Examples” on page 24 Anybus X-gateway CANopen - DeviceNet Doc.Rev. 2.10 Doc.Id. HMSI-168-83
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
advertisement
© 2021