Anybus AB7307 X-gateway – CANopen Master – PROFINET-IO Device User Manual

Add to my manuals
54 Pages

advertisement

Anybus AB7307 X-gateway – CANopen Master – PROFINET-IO Device User Manual | Manualzz
User Manual
Anybus X-gateway CANopen
PROFINET
®
Doc.Id. HMSI-168-91
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 - PROFINET.
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
PROFINET 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 - PROFINET User Manual
Rev 2.10
Copyright© HMS Industrial Networks AB
Doc: HMSI-168-91
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 - PROFINET
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
PROFINET Connector (Network Access Port).............................................................................. 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
PROFINET Generic Station Description (GSD file) ...................................................................... 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 PROFINET Interface ...................................................................................... 18
Data Exchange.............................................................................................................................. 18
PROFINET IO Data ................................................................................................................. 18
........................................................................................................... Modbus/TCP (Read-Only)19
Configuration ................................................................................................................................. 20
IP Settings ..................................................................................................................................... 20
Enabling Data Exchange....................................................................................................................... 22
Chapter 6
CANopen Module Specification
NMT State Machine............................................................................................................................... 23
Data Exchange........................................................................................................................................ 24
Control Word ................................................................................................................................ 25
Status Word .................................................................................................................................. 26
Example........................................................................................................................................ 28
PDO Functionality ........................................................................................................................ 29
LSS Services............................................................................................................................................. 30
Error Control .......................................................................................................................................... 31
Heartbeat Mechanism .................................................................................................................... 31
Node Guarding.............................................................................................................................. 31
Emergency Object (EMCY)........................................................................................................... 31
Chapter 7
CANopen Supported Objects
Static Data Types.................................................................................................................................... 32
Communication Profile Area................................................................................................................ 32
DS301 Communication Profile Objects.......................................................................................... 32
Configuration Manager .................................................................................................................. 34
Network Management Objects ....................................................................................................... 35
Vendor Specific Objects........................................................................................................................ 40
Transmit Buffer ............................................................................................................................. 41
Receive Buffer................................................................................................................................. 42
I/O Buffer Addresses and Object Dictionary Indices Relation ........................................................ 43
General Fieldbus Parameters.......................................................................................................... 44
PROFINET Specific Parameters .................................................................................................. 44
Appendix A Technical Specification
Protective Earth (PE) Requirements................................................................................................... 45
Power Supply .......................................................................................................................................... 45
Environmental Specification ................................................................................................................ 45
Temperature................................................................................................................................... 45
Relative Humidity.......................................................................................................................... 45
EMC (CE) Compliance ......................................................................................................................... 46
UL and ATEX Certification ................................................................................................................. 46
Anybus X-gateway CANopen
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
III
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-91
Preface
P. About This Document
For more information, documentation etc., please visit www.anybus.com
P.1 Related Documents
Document
CiA Draft Standard 301 v4.2
CiA Draft Standard Proposal 302 Part 1-5
PROFINET IO Specification
PROFINET Technology and Application
PROFIBUS Guideline, Identification & Maintenance Functions
Open Modbus/TCP Specification
Author
CAN in Automation
CAN in Automation
PROFIBUS Nutzerorganisation e.V. (PNO)
PROFIBUS Nutzerorganisation e.V. (PNO)
PROFIBUS Nutzerorganisation e.V. (PNO)
Schneider Automation
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-20
2013-01-11
Nov 2014
Author(s)
KeL
KeL
KeL
KeL
KeL
SDa
Chapter(s)
6, 7
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 PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Chapter 1
1. Anybus X-gateway CANopen - PROFINET
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.
PROFINET IO Network (primary network)
Master
(e.g. PLC)
Slave
Anybus X-gateway
CANopen
Slave
Slave
Slave
PROFINET IO
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 PDOsor read via CANopen SDOs and vice versa.
The gateway, described in this manual, connects a PROFINET network with a CANopen network. The
module acts as a PROFINET 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 PROFINET 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 PROFINET and the secondary
network is CANopen.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Anybus X-gateway CANopen - PROFINET 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)
PROFINET Features (primary network)
General
•
100 Mbit operation in full duplex
•
Built in file system with per-user security framework
•
Modbus/TCP Server (Read-only)
•
Real-Time (RT) communication
•
Cyclic data exchange (2 - 512 ms cycle time)
•
Acyclic Data exchange (Record Data Requests, not supported by the Anybus X-gateway CANopen)
•
Up to 64 slots / 1 sub-slot
•
Up to 512 bytes of I/O in each direction
•
DCP support (Discovery and Configuration Protocol)
•
LLDP (Linked Layer Discovery Protocol)
Supported PROFINET Features
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Anybus X-gateway CANopen - PROFINET 4
1.3 Functional Overview
PROFINET IO network
PROFINET IO network
slave interface
Anybus CANopen
master/slave interface
CANopen network
Internally, the X-ggateway consists of an intelligent gateway platform, an Anybus CANopen interface1
and an Anybus PROFINET interface. The CANopen interface and the Anybus PROFINET 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
PROFINET IO Network Interface
Status Word
Control Word
Data From
the CANopen
Network
Data to
the Canopen
Network
PROFINET IO 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 PROFINET 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 PROFINET network starts/stops the
exchange of data on the secondary CANopen network (the sub-network). It can also reset the gateway
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, and will be remembered when restarting.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Anybus X-gateway CANopen - PROFINET 5
if needed. The master on the primary PROFINET 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 PROFINET
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 24. 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 PROFINET 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 47
Status LEDs 1 - 4 indicate the status of the primary PROFINET network and status
LEDs 5 - 6 indicate the status of the secondary CANopen (sub)network and the device.
#
State
1 - Communication Off
Status
Single flash, green
Green
2 - Module Status
Off
Green
Single flash, green
Double flash, green
Single flash, red
Triple flash, red
Quadruple flash, red
Off
Green
Flickering green
4 - not used
5 - CANopen subnet Off
Flickering green/red
statusa
Blinking green
Single flash, green
On, green
Blinking red
Single flash, red
3 - Link/Activity
6 - Device status
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
Off line
On-line, STOP (connection established, IO
controller in STOP state)
On-line, RUN (connection established, IO
controller in RUN state)
Not initialized
No error, initialized
Diagnostic data available
Blink, used to identify the device
Configuration error
No Station Name or no IP Address
assigned
Failed to initialize PROFINET IO
No link
Link established
Exchanging packets
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
About the Anybus X-gateway CANopen 8
2.3 Primary Network
2.3.1 PROFINET Connector (Network Access Port)
Pin no
1
2
3
6
4, 5, 7, 8
Description
TD+
TDRD+
RD(reserved)
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
1
8
Doc.Id. HMSI-168-91
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 45
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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. 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
3. Connect the gateway to the secondary CANopen network.
4. Connect the gateway to the PROFINET network.
5. Connect the power cable and apply power
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 PROFINET Generic Station Description (GSD file)
Each device in a PROFINET network is associated with a Generic Station Description (a GSD 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 GSD file for the Anybus X-gateway PROFINET interface, can be downloaded
from the HMS web site, ‘www.anybus.com’ or obtained by contacting HMS.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 PROFINET network and the secondary CANopen
sub-network.
Note: The CANopen (secondary) sub-network interface is configured prior to the primary PROFINET
network interface. The Anybus X-gateway CANopen - PROFINET 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. Snap the gateway on to the DIN-rail (See “Hardware Installation” on page 11).
3. Connect the gateway to the CANopen (secondary) sub-network, using the connector at the bottom of the module.
4. Connect the power cable and apply power.
5. Download the appropriate EDS file from HMS to the external CANopen configuration tool. See
“CANopen Electronic Data Sheet (EDS)” on page 12.
6. 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
43.
7. Configure the module and the secondary CANopen network.
8. Connect the gateway to the primary PROFINET network.
9. Restart the gateway.
10. Download the appropriate Generic Station Description (GSD) file from HMS. See “PROFINET Generic Station Description (GSD file)” on page 12.
11. The actual configuration of the module is performed while configuring the PROFINET master
and the PROFINET network, see “Configuration of the PROFINET 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 PROFINET network is limited to 512 bytes, affecting the total number of PDOs that can be used in an
application.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Chapter 5
5. Configuration
This chapter describes the configuration of the secondary CANopen network interface as well as the
configuration of the primary PROFINET network adapter/slave interface of the module. The secondary CANopen network interface is configured prior to the primary PROFINET network adapter/slave
interface. The I/O data sizes configured for the secondary CANopen network decides the data sizes on
the primary PROFINET network adapter/slave interface.
5.1 Module Identification
The Anybus X-gateway CANopen master to PROFINET module identifies itself on the network as follows:
Description
Vendor ID
Vendor Name
Main Family
Product Family
Device ID
Order Number
Value
010Ch
“HMS Industrial Networks”
“Gateway”
“X-gateway COPM”
000Ah
“X-gateway COPM”
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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.
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 36.
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 44.
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 44.
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 PROFINET 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 PROFINET
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 44.
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.
To configure the primary PROFINET adapter/slave interface, restart the module, and then configure
the PROFINET 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 40) 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Configuration 18
5.4 Configuration of the PROFINET Interface
5.4.1 Data Exchange
The first two bytes of the I/O area are used for the status/control word. Thus the slave interface exchanges up to 510 bytes of I/O data in each direction
The control and status words are used by the PROFINET master to control the CANopen network and
to read the status of the CANopen network. The contents of the control and status words are described
in “Data Exchange” on page 24
The amount of data that is exchanged as I/O Data is specified when configuring the CANopen master
interface. The data arriving from the CANopen master is completely transparent. The interpretation has
to be defined by the master of the slave interface, in this case PROFINET.
See also...
•
“CANopen Master/Slave Configuration” on page 16
•
“Data Exchange” on page 24
5.4.2 PROFINET IO Data
PROFINET is the open Industrial Ethernet standard for Automation from PROFIBUS International.
The PROFINET IO adapter provides PROFINET IO Soft Real-Time Communication.
As with most fieldbus systems, PROFINET makes a distinction between fast cyclical data, a.k.a. ‘IO Data’, and acyclical data, called ‘Record Data’. The Anybus X-gateway CANopen does however not support Record Data. PROFINET IO Data corresponds to the ‘I/O Data’ in the Anybus X-gateway
CANopen.
PROFINET IO Data is exchanged cyclically and is built up by I/O modules. In the case of the Anybus
X-gateway, the actual I/O module configuration is adopted from the I/O Controller/Supervisor, provided that their total size does not exceed the IO sizes specified in the Gateway Config Interface. The
modules are mapped to the Input- and Output Buffers in the order of their slot number.
The amount of I/O data to be exchanged is defined when configuring the CANopen master interface.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Configuration 19
5.4.3 Modbus/TCP (Read-Only)
General
The Modbus/TCP protocol is an implementation of the standard Modbus protocol running on top of
TCP/IP. The same function codes and addressing model are used. The built in Modbus/TCP server
provides read-only access to the Input- and Output Buffers via a subset of the functions defined in the
Modbus/TCP specification.
All Modbus/TCP messages are received/transmitted on TCP port no. 502. For detailed information regarding the Modbus/TCP protocol, consult the Open Modbus Specification.
Data Representation (Modbus/TCP Register Map)
The following function codes are implemented:
Modbus Function
Read Input Registers
Read Holding Registers
Function Code
4
3
Associated with...
Input Buffer
Output Buffer
The Input & Output Buffers are mapped to Modbus registers as follows:
Register Type
Input Registers (3xxxx)
Output Registers (4xxxx)
Register #
a
0x0000
0x0001
0x0002
0x0003
0x0004
...
0x00FF
0x0000b
0x0001
0x0002
0x0003
0x0004
...
0x00FF
Associated with...
Input Buffer
Location
0x000...0x001
Output Buffer
0x002...0x003
0x004...0x005
0x006...0x007
0x008...0x009
...
0x1FE...0x1FF
0x000...0x001
0x002...0x003
0x004...0x005
0x006...0x007
0x008...0x009
...
0x1FE...0x1FF
a. Input Register 0x0000 is occupied by the Status Word.
b. Output Register 0x0000 is occupied by the Control Word.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Configuration 20
5.4.4 Configuration
After the configuration of the CANopen master interface has been finalized, the module has to be restarted before the configuration of the PROFINET slave interface can be started.
The slave interface is part of a PROFINET network, and will have to be configured within this. This
means that the interface must be assigned an IP address, see “IP Settings” on page 20. The configuration
tool used when configuring the PROFINET master and the PROFINET network will thus have to be
used to configure the slave interface as well. 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 master interface.
There are a number of different configuration tools for PROFINET available on the market. The choice
of tool depends on the application and the PROFINET IO controller of the network. A GSD file for
the slave interface is available at ‘www.anybus.com’.
An application note, describing how to configure an Anybus PROFINET slave interface with Siemens
STEP7, is available on the support pages for the Anybus X-gateway CANopen to PROFINET module
at ‘www.anybus.com’.
5.4.5 IP Settings
There are several options for assigning an IP address to the PROFINET slave interface of the module
is described below.
DCP (Discovery and Basic Configuration, Default)
The Anybus X-gateway CANopen to PROFINET supports the DCP protocol, allowing a PROFINET
IO Controller/Supervisor to change the network settings during runtime. If successful, this will replace
the settings currently stored.
DHCP/BootP
The module retrieves the TCP/IP settings from a DHCP or BootP server.
If it fails and no current settings are available, the module will indicate an error on the on-board status
LEDs. The settings may however be configured using HICP or gleaning, see “Anybus IPconfig (HICP)”
on page 21 and “ARP Gleaning” on page 21.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Configuration 21
Anybus IPconfig (HICP)
The module supports the HICP protocol used by the Anybus IPconfig utility from HMS, which can be
downloaded free of charge from the HMS web site. This utility may be used to configure the network
settings of any Anybus product connected to the network. Note that if successful, this will replace the
settings currently stored.
Upon starting the program, the network
is scanned for Anybus products. The network can be rescanned at any time by
clicking ‘Scan’. In the list of detected devices, the module will appear as ‘Anybus
X-gateway CANopen master’. To alter its
network settings, double-click on its entry in the list.
A window will appear, containing the IP
configuration and password settings.
Validate the new settings by clicking ‘Set’,
or click ‘Cancel’ to abort.
Optionally, the configuration may be protected from unauthorized access by a password. To enter a
password, click on the ‘Change password’ checkbox, and enter the password under ‘New password’.
When protected, any changes in the configuration requires that the user supplies a valid password.
When done, click ‘Set’. The adopted configuration will be stored in the ethernet configuration file.
Note: The HICP protocol communicates over UDP port 3250.
ARP Gleaning
The module supports the Address Resolution Protocol (ARP), allowing the IP settings to be altered using the ARP-command on a PC.
Syntax:
arp -s <IP address> <MAC address>
ping <IP address>
arp -d <IP address>
The ‘arp -s’ command stores the IP and MAC address in the PCs ARP-table. When the ‘ping’-command
is issued, the PC will address the module with the new IP address; the module recognizes that it was
addressed with the correct MAC address and adopts the new IP address from the ‘ping’ message.
If successful, new settings will be stored in the ethernet configuration file as follows:
IP Address:
Gateway:
Subnet:
DHCP:
xxx.xxx.xxx.xxx
0.0.0.0
255.255.255.0
OFF
(value supplied in ARP command)
(no gateway)
Note: This functionality may cause problems if multiple devices continuously issue ‘ping’-messages towards the module. The reason for this lies in the very nature of this functionality; since the module
adopts the IP address from all ‘ping’-messages, any additional ‘ping’-messages may cause the module to
change back and forth between old and new settings.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Configuration 22
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 23 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 control the secondary network, using the instructions sent in the control word from the
PLC.
If the module is set as slave, it will wait for a request from the master of the secondary 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 24
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
PROFINET network in chapter 5.
The control and status words of the module are used by the master of the primary PROFINET 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 25
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
38, 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 26
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 27
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 38, of a CANopen
node or network (depending on the value of
NodeID).
This response reflects the
state set in object 1F82h,
see 38, 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 28
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 29
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 4 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 40
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 30
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 40. 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Module Specification 31
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, 33),
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 32, 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 48.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 - PROFINET
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 48 for emergency error codes.
Current hardware revision
Set by HMS
RW
0000h (default)
RW
00h (default)
Doc.Id. HMSI-168-91
CANopen Supported Objects 33
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 44.
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 30
-
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 34
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 30
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 48).
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 - PROFINET
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-91
CANopen Supported Objects 35
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 - PROFINET
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-91
CANopen Supported Objects 36
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 37
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 38
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 39
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 37, 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 40
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 30. 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 41
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 - PROFINET
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-91
CANopen Supported Objects 42
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 - PROFINET
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-91
CANopen Supported Objects 43
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
CANopen Supported Objects 44
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 25 and
“Status Word” on page 26.
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 PROFINET) Valid values: 2-512a, default 16
RW
Output Data Size (size from PROF- Valid values: 2-512b, default 16
INET)
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 43 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 43 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 33), 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 48).
7.3.5 PROFINET Specific Parameters
Index range 3080h-308Fh is allocated for PROFINET IO 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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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.
Note: The shield of the RJ45 connector is not connected directly to PE. As all nodes in a PROFINET
network have to share chassis ground connection, the PROFINET cable shield has to be connected to
the chassis ground at each node in the network. For further information, see “PROFINET Installation
Guideline for Cabling and Assembly”, order no. 8.072, available for download at www.PROFINET.com.
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
Technical Specification 46
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 - PROFINET at www.anybus.com.
A.5 UL and ATEX Certification
The Anybus X-gateway CANopen - PROFINET 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 - PROFINET at www.anybus.com.
Anybus X-gateway CANopen - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 32.
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91
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 - PROFINET
Doc.Rev. 2.10
Doc.Id. HMSI-168-91

advertisement

Was this manual useful for you? Yes No
Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertisement