«TECH NOTE: PLC TO IN-SIGHT COMMUNICATIONS USING EIP PLC to In-Sight Communications Using EIP Copyright, Trademarks, Patents The software described in ...»
TECH NOTE: PLC TO IN-SIGHT COMMUNICATIONS USING EIP
PLC to In-Sight Communications Using EIP
Copyright, Trademarks, Patents
The software described in this document is furnished under license, and may be used or copied
only in accordance with the terms of such license and with the inclusion of the copyright notice
shown on this page. The software, this document, nor any copies thereof may be provided to or
otherwise made available to anyone other than the licensee. Title to and ownership of this software remains with Cognex Corporation or its licensor. Cognex Corporation assumes no responsibility for the use or reliability of its software on equipment that is not supplied by Cognex Corporation. Cognex Corporation makes no warranties, either express or implied, regarding the described software, its merchantability or its fitness for any particular purpose.
The information in this document is subject to change without notice and should not be construed as a commitment by Cognex Corporation. Cognex Corporation is not responsible for any errors that may be present in either this document or the associated software.
This document may not be copied in whole or in part, nor transferred to any other media or language, without the written permission of Cognex Corporation.
Tech Note: In-Sight to PLC Communications Using EIP Revision 3 June 2006 Copyright © 2003-2005 Cognex Corporation.
All Rights Reserved.
The hardware and portions of the software described in this document may be covered by one or
more of the following U.S. patents (other U.S. and foreign patents are pending):
Hardware 4,972,359; 5,526,050; 5,657,403; 5,793,899 Vision Tools 5,495,537; 5,548,326; 5,583,954; 5,602,937; 5,640,200; 5,717,785; 5,742,037;
5,751,853; 5,768,443; 5,796,868; 5,818,443; 5,825,483; 5,825,913; 5,845,007;
5,859,466; 5,872,870; 5,909,504
The following are registered trademarks of Cognex Corporation:
Cognex Cognex, Vision for Industry In-Sight "crosshair" logo In-Sight
The following are trademarks of Cognex Corporation:
The Cognex logo VAN (Vision Area Network) Other product and company names mentioned herein are the trademarks, or registered trademarks, of their respective owners.
PLC to In-Sight Communications Using EIP Table of Contents 1 Introduction
1.3 EtherNet Industrial Protocol (EIP)
1.3.1 Map Specification (MapSpec)
1.3.2 Change of State Function
1.3.4 Explicit Messaging Formats
2 Explicit Messaging Example
2.1.1 Components Needed
2.1.2 Summary of Steps
3 Implicit Messaging Example
3.1.1 Components Needed
3.1.2 Setting up in RSLogix 5000
PCCC (PC3) Communications Example
4.1.1 Components Needed
4.1.2 Using RSLogix 500
4.1.3 Message (MSG) Instruction
4.1.4 Setup Screen for the MSG Instruction
4.2 Using the MSG Instruction to Receive Data
4.3 Sending Native Mode Commands from an SLC5/05
4.4 Message Instruction results
1.1 Purpose The purpose of this document is to aid in the configuration of various Programmable Logic Controllers (PLCs) to communicate with In-Sight systems using the EtherNet Industrial Protocol (EIP). Users should already be familiar with the specific hardware and software configuration tasks pertinent to their system.
1.2 Scope The scope of this document is to enable an operator familiar with the EIP protocol and the applicable PLC equipment and software to successfully communicate with In-Sight® systems.
This document also provides examples of tested communication configurations.
This document is organized in four sections:
Introduction – This section introduces the concepts of the Ethernet Industrial Protocol and it’s application to In-Sight systems.
Explicit Messaging Example – This section provides an example of PLC communications with the In-Sight system using explicit messaging.
Implicit Messaging Example – This section provides an example of PLC communications with the In-Sight system using implicit messaging.
PCCC (PC3) Communications Example - This section provides an example of PC3 communications with the In-Sight system using explicit messaging and the SLC5/05.
1.3 EtherNet Industrial Protocol (EIP) The EtherNet Industrial Protocol incorporates the TCP and UDP layers of the Ethernet protocol in the transmission of data.
Because TCP/IP is point-to-point, EIP uses this layer for explicit messaging only. Explicit messaging is described as those messages in which the data field carries both protocol information and instructions for service performance. With explicit messaging, nodes must interpret each message, execute the requested task and generate responses. These types of messages can be used for device and job configuration, setup, etc.
Explicit messaging uses one of two packet types: Generic CIP (Control/Information Protocol) or PCCC (PC3).
The UDP/IP protocol, which can multicast, is used for implicit messaging. With implicit messaging, the data field contains no protocol information, only real-time I/O data. The meaning of the data is predefined at the time the connection is established and processing time in the node is therefore minimized during runtime. Such messages are low overhead, short and provide the required time-critical performance needed for control.
In-Sight systems support explicit or implicit messages from a single I/O client at any given time.
An I/O client is described as the PLC device communicating with the host In-Sight system.
PLC to In-Sight Communications Using EIP The protocol matrix for Rockwell’s Allen-Bradley PLCs is shown in Table 1-1.
Table 1-1:EIP Protocol Matrix
NOTE Every In-Sight sensor has a factory-assigned unique Media Access Control (MAC) address assigned to it, which cannot be changed or deleted. The MAC address is a hardware address that identifies a specific node of a network. The MAC address is made up of 6 bytes: 00-d0-24-xx-xx-xx. The first three bytes of the MAC address are the same for all In-Sight sensors: 00-d0-24. The last 3 bytes of the MAC address are unique to each sensor, represented as “xx-xx-xx”. When sending the MAC address over Ethernet/IP, In-Sight reverses the last three bytes of the MAC address and an “f4” byte value is displayed as the last byte. For example, the MAC address 00-d0-24-01-02-03 is sent over Ethernet/IP as 0x030201f4.
1.3.1 Map Specification (MapSpec) The map specification (MapSpec) provides the method of accessing or writing data to the applicable assembly object. The assembly object describes the communication services available and a common means by which information is exchanged between the Client (PLC) and the Server (In-Sight). The Input and Output assembly objects are configured as shown in Table 1-2 and Table 1-3.
Table 1-2: Input Assembly Object
… The relationship between the Input and Output Assembly is reversed between the Client (the PLC) and the Server (the In-Sight system). For example, the Client’s Output Assembly outputs data to the Server Input Assembly as shown in Table 1-4.
Table 1-4: I/O Assembly Relationship
The input to the assembly object is specified in the MapSpec, which consists of a list of specifiers delimited by colon (:) characters. Each specifier has two parts: the byte offset, and a data type code. The data type codes are listed in Table 1-5.
Table 1-5: MapSpec Data Type Codes
* Each byte after the start byte of the string will be interpreted as a character until a null (\00) byte is encountered or until another data type is specified (e.g., ‘8s:13i’ means that starting at byte 8, all bytes until 13 will be interpreted as characters for a total of five characters).
PLC to In-Sight Communications Using EIP
The MapSpec tells the applicable In-Sight functions how to encode or decode the data that exists in the assembly object. A colon (:) separates each data element. In Figure 1-1, the value of the Mapping parameter for the ReadEIP function, “0f:4f:8f”, has 3 elements: 0f, 4f, 8f. The first element indicates that starting at data byte 0 of the Input Assembly; translate the data into a float (0f → first byte, type float). Since a float is 4 bytes long, the next piece of data starts at the fourth byte and is also a float (4f → fourth byte, type float). The last piece of data starts at the eighth byte and is also a float (8f → eighth byte, type float).
The value of the Mapping parameter for the WriteEIP function, “0il:2il:4il”, also has 3 elements:
0il, 2il, 4il. The first element indicates that starting at data byte 0 of the Input Assembly, translate the data into an integer (0il → zero byte, type integer). Since an integer is 2 bytes long, the next piece of data starts at the second byte and is also an integer (2il → second byte, type integer).
The last piece of data starts at the fourth byte and is also an integer (4il → fourth byte, type integer).
NOTE The maximum length for input data is 128-bytes.
When using the ReadEIP function, a corresponding GetEIPData function is required.
GetEIPData has two parameters: ReadEIP structure (points to a ReadEIP function on the spreadsheet), and an Index (which tells it what element of the MapSpec to get data from). For example: GetEIPData (A2, 1) gets the 2nd element (In-Sight uses a 0 index as the first element) from the ReadEIP function in cell A2 (Figure 1-1).
1.3.2 Change of State Function (In-Sight software version 2.43 and higher) To provide an additional level of acquisition control using EtherNet/IP, a change of state (COS) field has been added to the assembly object.
Table 1-6 and Table 1-7 show the changes to the assembly object with the implementation of this function.
Table 1-6: In-Sight Input Assembly (Prior to V2.43)
2 97 123 42 \0 3 3.14159 … Table 1-7: In-Sight Input Assembly (After V2.43)
2 97 123 42 \0 3 3.14159 …
CMD – is still the command byte with 1 new acceptable data value:
99 (0x63) – to trigger on every packet (continuous trigger). This method is not recommended since it will attempt to trigger acquisitions at the RPI rate. It appears here only for backward compatibility with jobs developed older firmware.
COS – Change of State value PLC to In-Sight Communications Using EIP In-Sight will trigger whenever it sees the COS byte’s value change from its previous value to a different non-zero value. In-Sight will not trigger when the COS byte’s value changes to 0.
Reserved – Reserved bytes. No data to be placed here.
The data portion of the assembly object (bytes 4 – 132) remains the same. For both methods of network triggering, the null terminated “Master Name” string (for example: “PLC1\0”) has to appear in the first part of the data section. In the AcquireImage property sheet (cell A0), the Trigger parameter must be set to Network, and the Master Name Parameter must contain the same string that will appear in the first bytes of the data portion of the packet (“PLC1”).
■ If the Master Name Parameter is left blank, the string at the beginning of the assembly object is not required.
■ Regardless of the state of the CMD and COS bytes, the PLC may still send and receive data to/from the In-Sight server. The CMD byte only affects the AcquireImage event.
Change of State Functionality
Assume the following initial setup from the Client:
2 97 123 42 \0 3 3.14159 … Initially In-Sight receives a COS byte with a value of 0, so regardless of the previous value of the COS byte, In-Sight will not trigger. The client then begins to send packets at the Request Packet Interval (RPI) and the server (In-Sight) receives them. The camera will not be triggered at this point because the COS byte has not changed (initial state was 0 and has remained 0). At some point later, the client wants to tell In-Sight to trigger, so it changes the COS byte to 1. That packet is sent out and received by In-Sight. In-Sight determines that the COS byte has changed from 0 to 1 and will fire an acquisition event. If, on the next cycle, the client does not change the COS byte, the camera will not acquire (client continues to send 1). If the client wants to trigger again, the COS byte must be set to a different non-zero value. In-Sight will receive that packet, determine that the COS byte has been changed from 1 to a different non-zero value and fire a second acquisition event.
PLC to In-Sight Communications Using EIP
To prevent the In-Sight from missing triggers, it is recommended that the COS byte be incremented rather than simply toggled between two non-zero values. To understand this problem, consider toggling the COS byte between 1 and 2 with the PLC’s RPI set to 300 msec. If the PLC’s logic updated the COS byte every 100 msec, with a sequence of changes such as 1In-Sight would sometimes miss the value changing from 1 to 2. Instead In-Sight would see 1-1-2 and therefore miss a trigger.
1.3.3 PCCC (PC3) and Implicit Messaging Formats PC3 and Implicit messaging protocols also employ the In-Sight’s ReadEIP and WriteEIP functions. PC3 may also use a limited Native Mode command set to access and write data to/from
the In-Sight system. The ReadEIP and WriteEIP functions require the following inputs:
The Event input specifies the update event on which to read data. This argument must reference cell A0 (the AcquireImage function), or a cell containing a soft event.