DOCSLIB.ORG

CAN/Canopen to Ethercat Gateways: Requirements and Solutions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CAN/Canopen to Ethercat Gateways: Requirements and Solutions iCC 2008 CAN in Automation CAN/CANopen to EtherCAT Gateways: Requirements and Solutions Martin Rostan, Beckhoff Automation GmbH Mirko Tischer, Vector Informatik GmbH CAN is the dominating network technology in automotive applications. Enhanced by the higher layer protocol CANopen it is a well established Fieldbus technology, im- plemented in a large variety of devices and systems. EtherCAT is an Industrial Ethernet technology which provides high end communication performance, flexible topology options and low system costs. In many applications, the distinct advantages of both networks have to be combined. With CAN/CANopen to EtherCAT gateways, this can be done efficiently, if certain design rules are followed. This paper discusses the requirements on such gateways from the application and from the device vendor point of view. Besides CANopen gateways, the special re- quirements of generic CAN to EtherCAT gateways as used e.g. in automotive test bed applications are considered. It is shown that CANopen protocols can be used to con- figure the gateway also from the EtherCAT side. Example implementations and their representation in software tools are shown as well as application examples. It is also shown that such gateways enable a smooth migration path from CANopen devices towards Industrial Ethernet. EtherCAT Overview EtherCAT communication cycle times are 0.1 – 1ms, the network extension, number EtherCAT was originally developed by of nodes and the topology options are al- Beckhoff and introduced in 2003. Mean- most unlimited. A more detailed introduc- while the technology is an IEC standard tion into EtherCAT and its usage of [2-4], and supported by the EtherCAT CANopen protocols can be found in [1]. Technology Group [7], an international user and vendor organization with over 650 member companies from 37 countries EtherCAT masters do neither require any (as of Dec 2007). EtherCAT utilizes special hardware nor a dedicated commu- CANopen [6] communication protocols nication processor and can be imple- such as SDO and PDO and also supports mented in software on any control hard- CANopen device profiles. In IEC 61800-7- ware that provides an Ethernet port. Eth- 301 [5] the mapping of the CANopen servo erCAT Slave Controller chips are available drive profile CiA402 onto EtherCAT is from several manufacturers. standardized. EtherCAT employs the func- tional principle of “processing on the fly”: Gateways unlike other Industrial Ethernet technolo- gies, the Ethernet frame or packet is no CAN / Ethernet gateways have been dis- longer received, then interpreted and cussed for quite some time (e.g. in [8, 9, process data then copied at every device. 10, 11]). The system architecture behind The EtherCAT slave devices read the data these approaches is hierarchical (figure 1): addressed to them while the frame passes field devices networked locally with CAN through the node. Similarly, input data is or CANopen fieldbus systems are con- inserted while the telegram passes nected with the Ethernet based control or through. This leads to superior bandwidth management level via gateways. This ini- utilization and thus to short cycle times – tial approach avoids complex timing re- EtherCAT is considered to be the fastest quirements both for Ethernet and the Industrial Ethernet technology – while al- gateway, since all real time control loops lowing for flexible topology options and low are closed locally within the CAN environ- implementation and system costs. Typical ment. The Ethernet connection is used for 02-1 iCC 2008 CAN in Automation non real time tasks such as data acquisi- CANopen to EtherCAT gateway tion, remote configuration and diagnosis. CANopen networks are used in a very broad range of application fields such as machine control, medical devices, off-road and rail vehicles, maritime electronics, building automation as well as power gen- eration. When considering CANopen to EtherCAT gateways, the following CANopen device classification may help to sort the applications: Fieldbus devices such as I/O-blocks, drives, sensors, actuators, valves etc. which typically are also available with other common fieldbus interfaces. Here the CANopen to EtherCAT gateway pre- Figure 1: Hierarchical Control Architecture dominantly serves the purpose of integrat- The system architecture and thus the re- ing such CANopen devices which are not quirements for gateways change with the yet available with EtherCAT interface. arrival of real time Ethernet technologies Embedded devices such as small em- such as EtherCAT (see figure 2). Now the bedded controllers, custom made sensor Ethernet based system does not only interfaces, specialized hardware compo- reach the real time characteristics (such nents for machine control used in conjunc- as reaction and cycle time) of the CAN tion with general purpose fieldbus devices. based network, but exceeds these per- For special purpose control subsystems – formance parameters substantially. At the often they include the machine builders same time EtherCAT overcomes one of dedicated process know how – CANopen the main constraints of CAN: limited net- so far has been the network of choice, work extension particular at high baud since the CAN hardware is simple to inte- rates. grate and CANopen provides the interop- And since EtherCAT interfaces can also erability. While EtherCAT has similar fea- be implemented at low costs, the applica- tures and will thus further expand in this tion range of the Ethernet technology is environment, gateways here are very use- enhanced towards and beyond the field- ful since one tries to avoid the re-design of bus level, reaching the embedded system such special hardware if possible even if level. CANopen is replaced by EtherCAT as main control network. Deeply embedded devices in vehicles, medical devices etc, where no standard “off the shelf” devices can be used. In con- junction with such systems gateways are typically used to enable the classical hier- archical architecture: local, widely inde- pendent networks have to be connected to supervisory or management levels equipped with EtherCAT. However, Eth- Figure 2: Flat Control Architecture erCAT is already used as backplane bus systems and hence in deeply embedded The real time domain is no longer con- applications. And since EtherCAT slave cluded in the CAN network, but spans controllers are also available with ex- across the network technologies. The re- tended temperature ranges, this network is quirements on the gateways change ac- also beginning to even enter deeply em- cordingly, since CAN networks are now bedded systems with rigid environmental used as local extensions of the real time requirements such as mobile machines. EtherCAT system. 02-2 iCC 2008 CAN in Automation The gateway timing requirements in field- bus and embedded device scenarios typi- cally are more demanding than in applica- tions where deeply embedded systems have to be connected. Whenever the long term goal is to move from CANopen to EtherCAT, gateways provide a smooth migration path. CAN to EtherCAT gateway Most in-vehicle applications do not use Picture 2: BMW Research + Innovation Center CANopen, but proprietary protocols on top (FIZ) in Munich, Germany (Photo: BMW AG). of the CAN physical and data link layer. Generic, non-standardized CAN protocols Gateway design considerations are also used in many deeply embedded applications. Unlike with CANopen, higher When designing such a gateway the spe- layer protocol information may also be cific requirements of coupling EtherCAT encoded in the data length code or identi- and CAN have to be taken into account, in fier field of the CAN frame, so forwarding order to maximize performance, achieve the CAN payload data through the gate- the best possible synchronization and thus way may not be sufficient. In addition, the prepare the gateway for the widest range CAN network timing itself may contain of applications. valuable information (such as occurrence of certain signals), so that additional timing Data throughput information may have to be provided, too. The data throughput of EtherCAT and CAN is different by orders of magnitude. While CAN transports up to 8 bytes per frame at a maximum of 1 MBit/s (60 Kbytes/s), EtherCAT transmits up to 1486 bytes per frame at 100 MBit/s (10.000 Kbytes/s with the possibility of a future extension to Gbit Ethernet). EtherCAT can transport the bus traffic of several CAN networks without generating an overload situation, if several CAN frames per Eth- erCAT frame are transmitted. Picture 1: Engine Test Bed (Photo: BMW AG) Cyclic vs. Event driven communication CAN to EtherCAT gateways are used in automotive test bed applications, e.g. at Another big difference between the sys- the BMW Research and Innovation Center tems is how the transmission of the mes- in Munich, Germany (see picture 1+2). sages is triggered. With EtherCAT the EtherCAT was chosen as automation net- frame is always sent by the master. The work for the new engine test center that EtherCAT master typically operates cycli- starts operations later this year, and some cally and therefore the communication testing equipment is connected via Gate- typically is directly linked with this cycle. ways. The ability to integrate remote CAN On the CAN side communication is often interfaces without jeopardizing the per- event driven. Whenever data has to be formance on either side was a crucial cri- transmitted, the device initiates the send- terion for the network selection in this ap- ing of a frame. The differences
Load more

Recommended publications
  • Introduction to Real-Time Ethernet II
    the EXTENSION JULY–AUGUST A Technical Supplement to Control Network Volume 5 Issue 4 © 2004 Contemporary Control Systems, Inc. Introduction to Real-Time Ethernet II By Paula Doyle, a doctoral researcher with the Circuits and Systems Research Centre at the University of Limerick in Ireland INTRODUCTION IEEE 1588 defines two separate types of clocks: In “Real-Time Ethernet I”, we introduced the basic ordinary and boundary. Boundary clocks (BC) are concepts of Ethernet’s capacity to deliver a real-time employed in devices such as hubs or switches—where (RT) communication system. “Real-Time Ethernet II” more than one PTP communication path (port) exists. introduces some of the RT solutions available to Ordinary clocks exist in devices having a single port— e.g., normal network devices. Each BC port can act as industry today*: PROFInet, EtherCAT and ETHERNET Powerlink. It also provides an introduction to a single a master or ordinary clock in its own segment. standard, IEEE 1588 that is growing in popularity PTP is for networks that support multicasting but amongst RT Ethernet developers to provide sub- keep multicasts within a subnet and where each local microsecond synchronization accuracy of distributed clock fulfills exacting requirements. The grandmaster clocks over Ethernet. clock (GMC) is the best clock in the system—with the best inherent stability, accuracy, resolution, etc. * EtherNet/IP is included in the full article available at defined by the standard [2]. The Best Master Clock http://www.ccontrols.com/pdf/volume5n4.pdf Algorithm (BMC), run by every live node, determines IEEE 1588 clock quality. Within each subnet, the BMC determines the master clock; in a single-subnet system the master IEEE 1588 [1] specifies “A protocol to synchronize is the GMC.
    [Show full text]
  • Canopen Documentation Release 1.2.2.Dev41+Gff8b5ca
    canopen Documentation Release 1.2.2.dev41+gff8b5ca Christian Sandberg Sep 13, 2021 Contents 1 Network and nodes 3 2 Object Dictionary 11 3 Network management (NMT) 17 4 Service Data Object (SDO) 19 5 Process Data Object (PDO) 27 6 Synchronization Object (SYNC) 33 7 Emergency Object (EMCY) 35 8 Time Stamp Object (TIME) 37 9 Layer Setting Services (LSS) 39 10 Integration with existing code 43 11 Device profiles 45 Index 51 i ii canopen Documentation, Release 1.2.2.dev41+gff8b5ca This package provides support for interacting with a network of CANopen nodes. Note: Most of the documentation here is directly stolen from the CANopen Wikipedia page. This documentation is a work in progress. Feedback and revisions are most welcome! CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. Easiest way to install is to use pip: $ pip install canopen Contents 1 canopen Documentation, Release 1.2.2.dev41+gff8b5ca 2 Contents CHAPTER 1 Network and nodes The canopen.Network represents a collection of nodes connected to the same CAN bus. This handles the sending and receiving of messages and dispatches messages to the nodes it knows about. Each node is represented using the canopen.RemoteNode or canopen.LocalNode class.
    [Show full text]
  • EM133 Multifunction Meter
    EM133 Multifunction Meter CANopen Communications Protocol Reference Guide BG0592 Rev. A1 Every effort has been made to ensure that the material herein is complete and accurate. However, the manufacturer is not responsible for any mistakes in printing or faulty instructions contained in this book. Notification of any errors or misprints will be received with appreciation. For further information regarding a particular installation, operation or maintenance of equipment, contact the manufacturer or your local representative or distributor. REVISION HISTORY A1 February Release 2016 AnyBus® is a registered trademark of HMS Industrial Networks AB. 2 Table of Contents 1 GENERAL........................................................................................................... 5 2 CANOPEN PROTOCOL IMPLEMENTATION .................................................... 6 2.1 CANOPEN ELECTRONIC DATA SHEET (EDS) FILE ..................................................................... 6 2.2 CANOPEN VERSION ................................................................................................................. 6 2.3 BAUD RATES ........................................................................................................................... 6 2.4 NODE ADDRESS ....................................................................................................................... 6 2.5 INPUT AND OUTPUT BUFFERS ................................................................................................... 6 2.6 EXTENDED DIAGNOSTIC
    [Show full text]
  • Ethercat – Ultra-Fast Communication Standard
    EtherCAT – ultra-fast communication standard In 2003, Beckhoff introduces its EtherCAT tech- In 2007, EtherCAT is adopted as an IEC standard, EtherCAT: nology into the market. The EtherCAT Technology underscoring how open the system is. To this Group (ETG) is formed, supported initially by day, the specification remains unchanged; it has global standard 33 founder members. The ETG goes on to stan- only been extended and compatibility has been dardize and maintain the technology. The group is retained. As a result, devices from the early years, the largest fieldbus user organization in the world, even from as far back as 2003, are still interopera- for real-time with more than 5000 members (as of 2019) cur- ble with today’s devices in the same networks. rently. In 2005, the Safety over EtherCAT protocol Another milestone is achieved in 2016 Ethernet from the is rolled out, expanding the EtherCAT specification with EtherCAT P, which introduces the ability to to enable safe transmission of safety-relevant carry power (2 x 24 V) on a standard Cat.5 cable field to the I/Os control data. The low-footprint protocol uses a alongside EtherCAT data. This paves the way for so-called Black Channel, making it completely machines without control cabinets. independent of the communication system used. The launch of EtherCAT G/G10 in 2018 in- How it works The key functional principle of EtherCAT lies in how its nodes process Ethernet frames: each node reads the data addressed to it and writes its data back to Flexible topology the frame all while the frame is An EtherCAT network can sup- moving downstream.
    [Show full text]
  • Communication Solutions for Rockwell Automation ® Users
    WHERE AUTOMATION CONNECTS Communication Solutions for Rockwell Automation® Users ASIA PACIFIC | AFRICA | EUROPE | MIDDLE EAST | LATIN AMERICA | NORTH AMERICA Table of Contents Ethernet and Serial Gateway Solutions 2 Automotive and Inertial Navigation Gateways 2 Serial & Ethernet Modbus® Solutions 3 Scalable Modbus® & Modbus® TCP Solutions for CompactLogix™ 3 Secure Remote Connectivity 4 In-Chassis Flow Computer Solutions 6 HART Solutions 6 Power and Energy Solutions 7 DNP3 Solutions 7 Modernization Solutions 8 PROFIBUS Solutions 10 Enterprise Connectivity 11 Leverage the IIoT 11 Automated Material Handling 12 802.11n (abgn) Fast Industrial Hotspots 13 Radiating Cable 2.4 and 5 GHz Band 14 802.11n (abgn) Fast Watertight Industrial Hotspots 14 Wireless Support from Trusted Experts 15 Wireless Comparison Product Selection Chart 16 In-Chassis Product Selection Chart 17 Stand-Alone Gateways Product Selection Chart 18 Rockwell_2020_EN Ethernet and Serial Gateway Solutions ProSoft Technology’s stand-alone, DIN-rail mounted industrial gateways provide a means to read or write data from devices on dissimilar protocols. All gateways come with our ProSoft Discovery Service feature. With PDS, you don’t have to change your PC to the default subnet of the module, saving you time during setup. Building Automation solutions – including QuickServer gateways – bring key operational data directly to your Rockwell Automation controller. Use these solutions to boost energy efficiency, use the resource most productively, and decrease your usage and costs. • Gateways with two Ethernet ports allow you to isolate networks, passing only the data you want between devices • EtherNet/IP gateways support multiple I/O connections for fast real-time data • Remote configuration and diagnostics via Ethernet • SD Card slot for disaster recovery of configuration data • Up to four Serial ports PROFIBUS DP & many other protocols are also available.
    [Show full text]
  • Ethercat the New Standard for Measurement Applications Central Backbone for Distributed Systems
    C5.2 EtherCAT The new standard for measurement applications Central backbone for distributed systems Dr. Kessel, Jens-Achim ADDITIVE Soft- und Hardware für Technik und Wissenschaft GmbH Max-Planck-Str. 22b, 61381 Friedrichsdorf Abstract In the past years EtherCAT has become a world wide accepted new standard in automation and control. In November 2003 the EtherCAT Technology Group (ETG) was founded and it has grown up to about 900 members from 45 countries in January, 2009. EtherCAT was designed and developed as an open high performance Ethernet-based fieldbus system. The development goal of EtherCAT was to apply Ethernet technology to automation applications which require short data update times (also called cycle times) with low communication jitter (for synchronization purposes) and low hardware costs. Once the new standard was introduced for automation and control, it became interesting, too, to use Eth- erCAT also for distributed systems in measurement applications. This paper takes a focus on the special properties of EtherCAT with respect to the usability in measure- ment applications. It shows the capabilities of EtherCAT as a powerful backbone, replacing classical net- works based on CAN or ProfiBUS. In particular aspects of synchronisation and real-time-processing in combination with the compact data packaging are interesting for measurement applications with a big number of distributed analog channels. E.g. in applications where torque and speed of rotating parts are picked up just to measure, to detect or even to prevent oscillations, it is very important to synchronize the sampling of data at the distributed converter modules. Only this allows then to calculate exact phase in- formation from the measured signals and evaluate and prepare the data according to the requirements of an application on top.
    [Show full text]
  • AKD Canopen Manual English
    RGM® CAN-BUS Communication Edition: A, October 2017 Original Documentation For safe and proper use, follow these instructions. Keep them for future reference. RGM CANopen | Record of Document Revisions Revision Remarks A, 10/2017 Launch version Technical changes which improve the performance of the device may be made without prior notice! Printed in the United States of America This document is the intellectual property of Kollmorgen. All rights reserved. No part of this work may be reproduced in any form (by photocopying, microfilm or any other method) or stored, processed, copied or distributed by electronic means without the written permission of Kollmorgen. 2 Kollmorgen | kdn.Kollmorgen.com | October 2017 RGM CANopen | 1 Table of Contents 1 Table of Contents 1 Table of Contents 3 2 About This Manual 18 2.1 Overview and Scope 18 2.1.0.1 Copyrights 18 2.1.0.2 Document Validity 18 2.2 Product Warnings 18 2.3 References 18 2.3.1 Defining Documents 18 2.3.1.1 CiA 301: CANopen Application Layer and Communication Profile 18 2.3.1.2 CiA 402 Part 1: Device Profile for Drives and Motion Control, General Definitions 18 2.3.1.3 CiA 402 Part 2: Device Profile for Drives and Motion Control, Operation Modes and Application Data 18 2.3.1.4 CiA 402 Part 3: Device Profile for Drives and Motion Control, PDO Mapping 19 2.3.1.5 IEC 61800-7-1: Adjustable Speed Power Drive Systems 19 2.3.1.6 IEC 61800-7: ETG Implementation Guideline for the CiA402 Drive Profile 19 2.4 Object Description Conventions 19 Transmit PDO Communication Parameters - Index 0x1800
    [Show full text]
  • Handbuch Canopen ECO PIO-347+Busklemmen,Englisch
    Electromechanical Automation North America Parker I/O-System CANopen ECO + I/O-Modules PIO-347 Manual Technical description, installation and configuration We reserve the right to make technical changes 88-022350-01A October 2003 The data contained in this manual correspond to the current status at the time of printing. PIO Parker I/O-System Copyright © 2003 Parker Hannifin GmbH EME All rights reserved. Microsoft Word, Microsoft Office, Windows®, Window 95™, Window 98™, Windows NT®, Window 2000™, Window XP™ and MS-DOS™ are trademarks of Microsoft Corporation. EME - Electromechanical Automation Europe Germany: Parker Hannifin GmbH Electromechanical Automation Postfach: 77607-1720 Robert-Bosch-Str. 22 D-77656 Offenburg Tel.: +49 (0)781 509-0 Fax: +49 (0)781 509-176 E-mail: [email protected] mailto:[email protected] Internet: www.parker-eme.com http://www.parker-eme.com England: Parker Hannifin plc Electromechanical Automation 21 Balena Close Poole, Dorset England, BH17 /DX UK Tel.: +44 (0)1202 69 9000 Fax: +44 (0)1202 69 5750 E-mail: [email protected] mailto:[email protected] Internet: www.parker-eme.com http://www.parker-eme.com Italy: Parker Hannifin S. p. A Electromechanical Automation Via Gounod 1 I-20092 Cinisello Balsamo (MI), Italy Tel.: +39 (0)2660 12459 Fax: +39 (0)2660 12808 E-mail: [email protected] mailto:[email protected] Internet: www.parker-eme.com http://www.parker-eme.com EMN - Electromechanical Automation North America USA: Parker Hannifin Corporation Electromechanical Automation 5500
    [Show full text]
  • AKD Ethercat Manual English
    AKD™ EtherCAT Communication Edition: A, July 2010 Valid for Hardware Revision A Part Number 903-200005-00 Original Documentation Keep all manuals as a product component during the life span of the product. Pass all manuals to future users and owners of the product. Kollmorgen Record of Document Revisions: Revision Remarks -, 11/2009 Beta launch version -, 12/2009 Minor formatting changes A, 07/2010 FBUS.PARAM04 added, part number added, page format, release information Hardware Revision (HR) Hardware Revision Firmware WorkBench A M_01-03-zz-zzz 1.2.0.zzzzz EnDat is a registered trademark of Dr. Johannes Heidenhain GmbH EtherCAT is a registered trademark of EtherCAT Technology Group HIPERFACE is a registered trademark of Max Stegmann GmbH WINDOWS is a registered trademark of Microsoft Corporation AKD is a registered trademark of Kollmorgen™ Corporation Current patents: US Patent 5,646,496 (used in control card R/D and 1 Vp-p feedback interface) US Patent 5,162,798 (used in control card R/D) US Patent 6,118,241 (used in control card simple dynamic braking) Technical changes which improve the performance of the device may be made without prior notice! Printed in the United States of America This document is the intellectual property of Kollmorgen™. All rights reserved. No part of this work may be reproduced in any form (by photocopying, microfilm or any other method) or stored, processed, copied or dis- tributed by electronic means without the written permission of Kollmorgen™. 2 Kollmorgen | July 2010 AKD EtherCAT | Table of Contents Table
    [Show full text]
  • HDL Implementation of a Controller Area Network Node
    Rowan University Rowan Digital Works Theses and Dissertations 12-31-2003 HDL implementation of a controller area network node Anthony Richard Marino Rowan University Follow this and additional works at: https://rdw.rowan.edu/etd Part of the Electrical and Computer Engineering Commons Recommended Citation Marino, Anthony Richard, "HDL implementation of a controller area network node" (2003). Theses and Dissertations. 1341. https://rdw.rowan.edu/etd/1341 This Thesis is brought to you for free and open access by Rowan Digital Works. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of Rowan Digital Works. For more information, please contact [email protected]. HDL Implementation of a Controller Area Network Node by Anthony Richard Marino A Thesis Submitted to the Graduate Faculty in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE Department: Electrical and Computer Engineering Major: Engineering (Electrical Engineering) Approved: Members of the Committee In Charge of Major Work For the Major Department For the College Rowan University Glassboro, New Jersey 2003 ii TABLE OF CONTENTS List of Figures ................................................................................. vi List of Tables .............................................................................................. ............. viii Abstract........................................ ....................................................................................... x Acknowledgements...............................................
    [Show full text]
  • Ethercat Communication Manual
    Specialized Vision Sensor for Positioning FZM1 Series EtherCAT Communication Manual Cat. No. Q179-E1-01 Trademarks and Copyrights • EtherCAT is a registered trademark of Beckhoff Automation GmbH (Germany). EtherCAT technology is protected by patents. • Other system names and product names that appear in this manual are the trademarks or registered trademarks of the relevant companies. © OMRON, 2010 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, mechanical, electronic, photocopying, recording, or otherwise, without the prior written permission of OMRON. No patent liability is assumed with respect to the use of the information contained herein. Moreover, because OMRON is constantly striving to improve its high-quality products, the information contained in this manual is subject to change without notice. Every precaution has been taken in the preparation of this manual. Nevertheless, OMRON assumes no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained in this publication. Contents 1 What Is EtherCAT?.....................................................................................................1 1-1 Outlines of EtherCAT .......................................................................................................1 Features of EtherCAT ..................................................................................................1 EtherCAT Mechanism
    [Show full text]
  • Ethercat Sensor Communication Unit
    E3X-ECT EtherCAT Sensor Communication Unit Operation Manual E413­E1 OMRON, 2012 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, mechanical, electronic, photocopying, recording, or otherwise, without the prior written permission of OMRON. No patent liability is assumed with respect to the use of the information contained herein. Moreover, because OMRON is con- stantly striving to improve its high-quality products, the information contained in this manual is subject to change without notice. Every precaution has been taken in the preparation of this manual. Nevertheless, OMRON assumes no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained in this publication. E3X-ECT EtherCAT Sensor Communication Units Operation Manual Revised February 2012 Introduction Thank you for purchasing a E3X-ECT EtherCAT Sensor communication Unit. This manual contains information you need to know to use the EtherCAT Slave Unit. Before use, please make sure that you thoroughly read the manual and have a full understanding of the products functions and performance. After you finished reading this manual, please keep it in a convenient place. Intended Readers This manual is intended for the following individuals. Those having electrical knowledge (certified electricians or individuals having equivalent knowledge) and also being qualified for one of the following: • Introducing FA equipment • Designing FA systems • Managing FA sites E3X-ECT EtherCAT Sensor Communication Unit Instraction Manual 1 How to Read the Manual Page Structure This manual's page structure consists of the following.
    [Show full text]