Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING E

INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING ETHERNET/IP Concepts and Principles of EtherNet/IP Communication with Rockwell Automation Products Authors:Vivek Hajarnavis, Richard Piggin, Ray Romito,Viktor Schiffer Version 1.0 Contents Introduction 3 Explicit Messaging 3 Use of CIP Routing 4 Data Organization in the Controller 4 Outbound Explicit Messages 5 Inbound Explicit Messages 7 Explicit Message Response Times 8 I/O Messaging 8 Further design considerations 18 EtherNet/IP communication with Add-On Instructions 19 Introduction – Why Add-On Instructions? 20 Generic benefits of Add-On Instructions 22 Creating an AOI 24 Steps to building an AOI 26 Integration with FactoryTalk View software 27 Appendix A – Accessing Tags in a Logix Controller 29 Glossary 30 References 31 Developer Resources 32 INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING ETHERNET/IP 3 Introduction Many Rockwell Automation products support communication via EtherNet/IP™; however, the type of communication it supports and the details of the communication vary from product to product. The CIP™Networks Library from ODVA (Open DeviceNet Vendor Association) provides detailed information about EtherNet/IP and the specifications that define Common Industrial Protocol (CIP) as well as its adaptation to various network protocols. What is commonly referred to as “the EtherNet/IP Specification” comprises two volumes (see references [8] and [9]) of this seven-volume library. All EtherNet/IP-enabled products support the minimum explicit messaging server functionality by allowing explicit messaging access to ID Object and other required objects. Although useful to identify a product, this communication is not the core requirement of an industrial application. Several guide documents (see references [1] through [6]) detail the communication with Rockwell Automation products. This document does not aim to replace these guides, but intends to highlight the communication concepts. For more information about the Common Industrial Protocol and EtherNet/IP, please refer to the the CIP eTraining ClassroomTM [10], an instructional CD designed to help developers understand and apply the fundamentals of the Common Industrial Protocol. The CD provides a cost-effective alternative to traditional training and can assist in product development and reducing time to market. For an introduction to EtherNet/IP interface development, the ODVA guide to EtherNet/IP development [11] provides a complete background to EtherNet/IP along with steps to follow for a successful development. Explicit Messaging Before the CIP concepts were made public, a range of legacy products were developed. Although these products are true explicit messaging servers (and sometimes clients as well), they use special, older protocol mechanisms such as PCCC (see [5]), meaning they communicate through a vendor-specific object using object-specific services. The data portion of the explicit message contains additional address information. Newer products, especially those within the Logix family, are explicit messaging servers with fully integrated CIP principles. In order to leverage their capabilities, several product details need to be understood. CIP is the preferred method of communicating to these products. The Logix family also supports the PCCC encapsulated messages to access controller data organized in PLC-5® style. Please refer to the Logix Data Access manual for details about this communication method. INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING ETHERNET/IP 4 Introduction Explicit Messaging Use of CIP Routing Figure 1 General Principle of a Logix System As shown in Figure 1, a Logix system is modular in nature, with modules sitting in a physical and/or logical chassis, also called a “rack.” Modules in a rack communicate using CIP as implemented on a backplane bus. Network communications modules (e.g. DeviceNet™, ControlNet™or EtherNet/IP) allow processor modules in the rack to communicate with the outside world via CIP networks. Communication modules are not an integral part of any processors (at least not logically), meaning that all communication from the outside world into a processor, and vice versa, must use the routing principles built into CIP. These principles state that processors should message across routed connections or through the Unconnected Send service, which carries at least one port segment. T o communicate with a Logix system, a routed explicit message (Unconnected Send or Forward Open) must contain a port segment identifying the backplane port (1) and the slot number of the module to be reached. All typical CIP principles apply inside the individual modules of the Logix system. Data Organization in the Controller Logix processors store and organize all data relevant to the outside world in tags whose user-defined names have meaning in the control application. Tags have the following properties: • A name with up to 40 characters One of two scopes: • Controller (i.e. global) scope is accessible by external means • Program (i.e. local) scope is not accessible by external means A defined data type for organizational purposes: • Atomic • BOOL, SINT, INT, DINT, REAL • These types follow the data definitions in CIP; note that Logix does not support all CIP-defined types. See Appendix C of reference [8] for details • Structures • This grouping of atomic data items functions as a single unit for a specific purpose; structures can be predefined (eg: TIMER, COUNTER, CONTROL) or user- defined (eg: UDTs) INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING ETHERNET/IP 5 Use of CIP Routing Data Organization in the Controller Arrays • A sequence of elements of the same data type can be one, two or three dimensional; array members can be atomic or structures The details of creating and using tags are beyond the scope of this document. Please see reference [7] for further details. For information about how to access tags, please read the chapter entitled, “Appendix A -- Accessing Tags in a Logix Controller.” Outbound Explicit Messages The MSG (message) instruction handles all Explicit messaging initiated by a Logix Controller program. T o utilize connected or unconnected messaging, the user configures MSG instruction. A later section will address how connected messaging can be “cached” to keep the connection open. Figure 2 Logix5000™MSG Instruction Message Configuration CIP Services that are directed towards data structured into objects can be chosen by selecting “CIP generic” messaging. A user can select from several predefined standard services or enter a valid service code in the “Service Type” field. T o access tag-oriented data, select the “CIP Data Table Read” or “CIP Data Table Write” services. Devices that support these vendor-specific services will respond to commands as explained in the chapter, “Appendix A – Accessing Tags in a Logix Controller.” Logix uses default timeout settings that can be changed by the user. These settings are (Please note that items in italics are members of the tag structure for the MSG instruction): • Approximately 30 seconds for connected explicit messages (ConnectionRate x 2^TimeoutMultiplier x 4); please note that ConnectionRate is the RPI in microseconds Arrays Outbound Explicit Messages INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING ETHERNET/IP 6 • Approximately 30 seconds for unconnected explicit messages (UnconnectedTimeout) • Approximately 30 seconds for Forward Open requests (UnconnectedTimeout) Any communication with another EtherNet/IP product initiated by Logix utilizes the List Services encapsulation command. If a device does not respond to this service (support of List Services is required, per the EtherNet/IP specification), Logix will not proceed with the communication. Logix EtherNet/IP interfaces automatically create and manage TCP connections and CIP encapsulation sessions. The user has no direct influence on this process. When an interface establishes a TCP connection and CIP encapsulation session, it will continue until it carries no CIP connection or has carried no CIP traffic for 125 seconds. The number of supported TCP connections depends on the interface module used. Figure 3 Logix5000 MSG Instruction Communication Configuration When using the MSG instruction to initiate a connected message, the user may enable the Cache Connection option, which keeps the CIP connection open indefinitely. If a cached connection is inactive for a period equal to the RPI (ConnectionRate) the controller repeats the last message. The repeated message has an unchanged sequence number, which does not affect the application. Logix controllers have a limit of 32 cached connections. If it exceeds this limit, the controller closes the least recently used connection. INTEGRATIONWITH CONTROLLOGIX PROGRAMMABLE AUTOMATION CONTROLLERS (PACS) USING ETHERNET/IP Outbound Explicit Messages 7 If the user does not enable Cache Connection, the connection closes immediately. An example of this sequence is: ForwardOpen Request, ForwardOpen Response, Explicit Request, Explicit Response, ForwardClose Request, ForwardClose Response. This sequence is repeated each time the MSG rung goes from false to true. Inbound Explicit Messages T o send explicit messages to a Logix system, connected messaging is recommended instead of unconnected messaging. Unconnected messaging resources are limited and can be come overwhelmed with activity. When this happens, response times become very long and the user application can suffer as a result. Users should also reuse TCP connections and Encapsulation sessions whenever possible because the Logix server sequentially executes messages in the order received. The client sequentially sends messages using a single connection rather than opening and closing separate connections for each new message. If a message request times out for example, re-try the CIP request. If it fails again, then consider if the session or TCP connection needs to be torn down and rebuilt. Incoming explicit messages are processed by the message router object uploads/Management/ developer-guide 6 .pdf