Professional Documents
Culture Documents
1756 pm020 - en P
1756 pm020 - en P
WARNING: Identifies information about practices or circumstances that can cause an explosion in a hazardous environment, which may
lead to personal injury or death, property damage, or economic loss.
ATTENTION: Identifies information about practices or circumstances that can lead to personal injury or death, property damage, or
economic loss. Attentions help you identify a hazard, avoid a hazard, and recognize the consequence
SHOCK HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that dangerous voltage may be
present.
BURN HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that surfaces may reach
dangerous temperatures.
IMPORTANT Identifies information that is critical for successful application and understanding of the product.
Allen-Bradley, Rockwell Software, Rockwell Automation, and TechConnect are trademarks of Rockwell Automation, Inc.
Trademarks not belonging to Rockwell Automation are property of their respective companies.
Summary of Changes
There are a number of minor changes throughout this publication that were
made to clarify existing information. The major changes are listed below.
Change Page
Updated supported controller models. Cover
Notes:
Chapter 1
CIP Services Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
CIP Services Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
CIP Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Logix5000 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Tag Type Service Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Segment Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
CIP Service Request/Response Format . . . . . . . . . . . . . . . . . . . . . . . . . 15
Services Supported by Logix5000 Controllers. . . . . . . . . . . . . . . . . . . . . . . 16
Read Tag Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Read Tag Fragmented Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Write Tag Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Write Tag Fragmented Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Read Modify Write Tag Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Logix Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Understanding Structure Boundaries and Member Order. . . . . . . . 34
Tag Type Service Parameters for Structures . . . . . . . . . . . . . . . . . . . . . 35
Chapter 2
CIP Services and User-created Tags Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
How tags are organized in the controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Symbol object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Template object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Creating and maintaining a symbol object list. . . . . . . . . . . . . . . . . . . . . . . 39
Step 1: Finding user-created controller scope tags in a Logix5000
controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Step 2: Isolating user-created tags from system tags/identifying
structured tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Symbol Type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter 3
CIP Addressing Examples Atomic Members of Predefined Data Types . . . . . . . . . . . . . . . . . . . . . . . . 57
Accessing User-Defined Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 4
CIP Over the Controller Serial Port Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Unconnected Messaging (UCMM) via PCCC. . . . . . . . . . . . . . . . . . . . . . 67
Connected Explicit Messages via PCCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Fragmentation Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 5
PCCC Commands Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Supported Subset of PCCC Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Initial Fields of All PCCC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
PLC-2 Communication Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Unprotected Read (CMD=01, 41; FNC not present). . . . . . . . . . . . 73
Protected Write (CMD=00, 40; FNC not present). . . . . . . . . . . . . . 73
Unprotected Write (CMD=08, 48; FNC not present). . . . . . . . . . . 73
Protected Bit Write (CMD=02, 42; FNC not present) . . . . . . . . . . 74
Unprotected Bit Write (CMD=05, 45; FNC not present) . . . . . . . 74
PLC-5 Communication Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Addressing examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Read Modify Write N (CMD=0F, 4F; FNC=79) . . . . . . . . . . . . . . . 77
Typed Read (CMD=0F, 4F; FNC=68). . . . . . . . . . . . . . . . . . . . . . . . . 77
Typed Write (CMD=0F, 4F; FNC=67). . . . . . . . . . . . . . . . . . . . . . . . 78
Word Range Read (CMD=0F, 4F; FNC=01). . . . . . . . . . . . . . . . . . . 78
Word Range Write (CMD=0F, 4F; FNC=00) . . . . . . . . . . . . . . . . . . 79
Bit Write (CMD=0F, 4F; FNC=02) . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SLC Communication Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
SLC Protected Typed Logical Read with 3 Address Fields
(CMD=0F, 4F; FNC=A2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
SLC Protected Typed Logical Write with 3 Address Fields
(CMD=0F, 4F, FNC=AA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
SLC Protected Typed Logical Read with 2 Address Fields
(CMD=0F, 4F; FNC=A1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
SLC Protected Typed Logical Write with 2 Address Fields
(CMD=0F, 4F; FNC=A9) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Studio 5000 Engineering and The Studio 5000 Engineering and Design Environment combines engineering
and design elements into a common environment. The first element in the
Design Environment and Studio 5000 environment is the Logix Designer application. The Logix Designer
Logix Designer Application application is the rebranding of RSLogix 5000 software and will continue to be
the product to program Logix5000 controllers for discrete, process, batch,
motion, safety, and drive-based solutions.
Purpose This manual describes how to access data within a controller from another
product or application that connects to the controller through the EtherNet/IP
network or the serial port. The following methods of data access from a
Logix5000 controller are described in this manual:
Common Industrial Protocol (CIP)
These services are also supported over the DF1 serial port by using
Programmable Controller Communication Commands.
The DF1/PCCC method via the serial port is sometimes the most
convenient way to access the controller, typically because of physical
proximity, but it requires using multiple protocols and can require that tag
be mapped to data tables, which is an extra configuration step. However,
this should not be considered a long term solution because newer Logix
controllers like the L7x family do not have a serial port. This is likely to be
the case as the family of ControlLogix and CompactLogix controller
evolve.
This manual is one of a set of related manuals that show common procedures for
programming and operating Logix5000 controllers. For a complete list of
common procedures manuals, see the Logix5000 Controllers Common Procedures
Programming Manual, publication 1756-PM001.
The term Logix5000 controller refers to any controller that is based on the
Logix5000 operating system, such as:
CompactLogix controllers
ControlLogix controllers
DriveLogix controllers
FlexLogix controllers
SoftLogix5800 controllers
Who Should Use This Manual Before using this document, make sure you:
Have a thorough understanding of CIP and EtherNet/IP.
Have purchased a copy of the pertinent volumes of the CIP Networks
Library.
Are properly licensed through ODVA to use the CIP technology.
For more information on the CIP Networks Library and CIP technologies,
contact ODVA at http://www.odva.org/.
Additional Resources Some of the information in this manual is covered in more detail in the CIP
specification (listed below). In case of discrepancies, the specification is the
authoritative source of information.
Resource Author
DF1 Protocol and Command Set Reference Manual, 1770-6.5.16 Rockwell Automation
Logix5000 Controllers Common Procedures Programming Manual, 1756-PM001 Rockwell Automation
Integration with ControlLogix Programmable Automation Controllers Using EtherNet/ Rockwell Automation
IP, http://www.rockwellautomation.com/enabled/guides.html
Logix5000 Controllers Design Considerations Reference Manual Rockwell Automation
(Chapter 3, Guidelines for Data Types), 1756-RM094
Logix5000 Controllers Import/Export Reference Manual 1756-RM084 Rockwell Automation
The Common Industrial Protocol, Pub 122(1) ODVA
The Common Industrial Protocol (CIP) and the Family of CIP Networks, Pub 123(1) ODVA
EtherNet/IP Quick Start for Vendors Handbook, Pub 213(1) ODVA
CIP Networks Library (Specifications) - subscription required, Volumes 1 and 2 ODVA
(1) To locate publications on the ODVA website, use the Search function and type 'pub ###', where ### is the publication number.
Term Definition
CIP Common Industrial Protocol.
PCCC Programmable Controller Communication Command.
PLC-2 An older, chassis-based, modular programmable controller.
PLC-5 A chassis-based, modular programmable controller.
SLC A small, chassis-based, modular programmable controller.
STS/EXT STS Status of the message transmission.
tag Character name of data.
user-created tag Tags the user creates of an atomic data type, a UDT structured data type, or arrays of these
types. The user also creates tags from system structures (For example, Module-Defined and
Predefined), primarily for use by the Logix system.The tags created from system structures
are referred to as system tags not user-created tags, and include any tags from UDTs that
contain nested system structures.
UDT User-Defined Structure data type.
Notes:
CIP Services
Introduction Communicating with the Logix5000 controller requires using CIP explicit
messaging, which is described in great detail in the CIP Specification. This
section highlights the subset of the CIP explicit messaging constructs that are
pertinent for understanding the service explanations that follow. This is not
meant to replace the need to understand CIP explicit messaging, which can be
found by reading the materials referenced in Additional Resources on page 9.
CIP Services Overview Before you use CIP services, review the following introductory information.
Topic Page
CIP Data Types 11
Logix5000 Data 12
Tag Type Service Parameter 13
Segment Encoding 13
CIP Service Request/Response Format 15
Data in the controller is organized as tags. The tags come in two basic types:
atomic and structures. Atomic types can be arrayed or singular, and are very easy
to work with. Structure types provide a great deal of flexibility, but are more
challenging to access. The following table identifies the atomic data type sizes.
Logix5000 Data
The Logix5000 controller stores data in tags, in contrast to a PLC-5 or SLC
controller, which stores data in data files. Logix5000 tags have these properties:
Name that identifies the data:
up to 40 characters in length.
Scope:
Controller (global), which you can access directly.
Program (local), which cannot be directly accessed, but can be copied
to a controller scope tag.
Data type, which defines the organization of the data.
See CIP Data Types on page 11 for more information.
In the Logix Designer application, version 21 and later, and in RSLogix 5000
software, version 18 and later, external access to controller scope tags is user
selectable. If a tags External Access attribute is set to None, then the tag cannot be
accessed from outside the controller.
For more information about external access to controller scope tags see chapter 4
of the Logix5000 Controllers I/O and Tag Data Programming Manual,
publication 1756-PM004-EN-P.
For more information about tags and data types, see Chapter 3 of the Logix5000
Controllers Design Considerations Reference Manual, publication 1756-RM094.
The Read Tag, Write Tag, Read Tag Fragmented, Write Tag Fragmented, and
Read-Modify-Write Tag services require a service parameter that identifies the
data type of the tag being referenced. This tag type parameter is:
A 16-bit value for atomic tags
Two 16-bit values for structured tags
The value used for structures is a calculated value. For details, see Tag Type
Parameters for Structure on page 35.
The tag type values used for atomic tags and the resulting data size are shown in
the table below.
Analysis
These values are based on the CIP Data Type Reporting Values that are defined
in Volume 1, Appendix C of the CIP Networks Library, but are extended to 16-
bits.
Segment Encoding
The Request Path in a CIP explicit message contains addressing information that
indicates to which internal resource in the target node the service is directed. This
addressing information is organized by using Logical Segments, Symbolic
Segments, or both.
For more detailed information about segments, see the CIP Networks Library,
Volume 1, Appendix C.
The following is a summary of the Logical Segment types defined by CIP that are
supported by the Logix5000 controller.
Logical Segments
These tables explain the Logical Segments. Not all segment types defined by CIP
are supported by Logix5000 controllers.
Segment Type Value Byte Order Representation of Element ID Value (low byte first)
0 1 n n+1
8-bit Element ID 0x28 Value N/A N/A N/A N/A
16-bit Element ID 0x29 00 Low High N/A N/A
32-bit Element ID 0x2A 00 Lowest Low High Highest
Segment Type Value Byte Order Representation of Class ID Value (low byte first)
0 1 n n+1
8-bit Class ID 0x20 Value N/A N/A N/A N/A
16-bit Class ID 0x21 00 Low High N/A N/A
Segment Type Value Byte Order Representation of Instance ID Value (low byte first)
0 1 n n+1
8-bit Instance ID 0x24 Value N/A N/A N/A N/A
16-bit Instance ID 0x25 00 Low High N/A N/A
Segment Type Value Byte Order Representation of Attribute ID Value (low byte first)
0 1 n n+1
8-bit Attribute ID 0x30 Value N/A N/A N/A N/A
16-bit Attribute ID 0x31 00 Low High N/A N/A
Symbolic Segments
CIP also defines a way to reference items by their symbolic name. The segment
used is the ANSI Extended Symbol Segment defined in the CIP Networks
Library, Volume 1, Appendix C.
The Read/Write tags services can use these segments in the request path to
indicate which target tag to operate on. When addressing an arrayed tag, the
Logical Segment for Element ID is also used with the Symbolic Segment.
All CIP services follow the Message Router Request/Response format defined in
the CIP Networks Library, Volume 1, Chapter 2. For complete descriptions, refer
to the CIP Networks Library.
This same form is used for ControlNet and EtherNet/IP communication. Both
are CIP-based networks. (Requests received via the serial port use a different
protocol, which is discussed in Chapter 5.)
The CIP service format is used for CIP-explicit messages and can be delivered to
the controller as connected or unconnected messages. These are sometimes
referred to as Transport Class 3 and UCMM, respectively. The mechanisms for
doing this are CIP-network specific. For example, for EtherNet/IP access, see the
CIP Networks Library, Volume 1, Chapter 3 and the EtherNet/IP Adaptation of
CIP, Volume 2.
The examples used throughout the manual show only the explicit message
protocol elements and not the network-specific details. The exception to this is
the information in Chapter 4, which shows more details of unconnected versus
connected explicit messages, and of the PCCC and DF1 layers. All responses take
the following general form as shown in the table that follows.
Services Supported The following sections describe the inherent mode of communication and
addressing of the Logix5000 controller. The following vendor-specific services
by Logix5000 Controllers operate on tags in the controller using symbolic addressing:
Read Tag Service (0x4c)
Read Tag Fragmented Service (0x52)
Write Tag Service (0x4d)
Write Tag Fragmented Service (0x53)
Read Modify Write Tag Service (0x4e)
The first four services above can be used with two different addressing methods:
Symbolic Segment Addressing
Symbol Instance Addressing (available in version 21 and above.)
The Multiple Service Packet Service (0x0a) may also be used to combine multiple
requests in one message frame. Using this will help improve performance when
accessing many tags by minimizing the time to transmit and process multiple
packets. The number of requests that can be included is limited by the size of each
request, which is dependent on the content of the request. The number of
characters in the tag names, for example, will have a big impact on the number of
requests that can be combined by the Multiple Service Packet Service.
For more information on the Multiple Service Packet Service, see page 31.
The services described here have changed to more descriptive names since earlier
versions of this publication. See the table below for previous names of Tag
Services.
Service In earlier versions of this manual, the In the Logix Designer application,
service was called the service was called
Read Tag Service CIP Read Data CIP Data Table Read
Read Tag Fragmented Read Data Fragmented Format N/A
Service
Write Tag Service CIP Write Data CIP Data Table Write
Write Tag Fragmented Write Data Fragmented Format N/A
Service
Multiple Service Packet Multiple Service Packet Service Multi-Request Service
Service
The Read Tag, Write Tag, Read Tag Fragmented and Write Tag Fragmented
services are described on the following pages along with examples of both the
Symbolic Segment Addressing and the Symbol Instance Addressing.
For examples showing more complex addressing using both types of addressing,
see Chapter 3.
The Request Data and Reply Data are shown in the required order shown in the
examples that follow. Any deviation from the order shown will likely result in an
error.
The Read Tag Service reads the data associated with the tag specified in the path.
Any data that fits into the reply packet is returned, even if it does not all fit.
If all the data does not fit into the packet, the error 0x06 is returned along
with the data.
When reading a two or three dimensional array of data, all dimensions
must be specified.
When reading a BOOL tag, the values returned for 0 and 1 are 0 and 0xFF,
respectively.
Read a single tag named rate using Symbolic Segment Addressing. The tag has a
data type of DINT and a value of 534 The value used for Instance ID was
determined using methods described in Chapter 2.
1st Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data 01 00 Number of elements to read (1)
1st Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C4 00 DINT Tag Type Value
16 02 00 00 0000216 = 534 decimal
Read a single tag named rate using Symbol Instance Addressing. The tag has a data
type of DINT and a value of 534.
1st Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 8F F6 Logical Segment for Instance ID of the tag rate
Request Data 01 00 Number of elements to read (1)
1st Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C4 00 DINT Tag Type Value
16 02 00 00 0000216 = 534 decimal
Both Symbolic Segment Addressing and Symbol Instance Addressing may return
the following errors.
The Byte Offset field is always expressed in number of bytes regardless of the data
type being read. In the example below, the data type being read is SINT, which
happens to be a byte. The elements and offset are in the same units, which will
not be the case for other data types.
Reading the tag TotalCount that has 1750 SINTs consists of the following four
service requests with service data, as shown in the tables that follow.
1st Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data D6 06 Number of elements to read (1750)
00 00 00 00 Start at this byte offset (0) and return as much as will fit
1st Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 0 through 489
2nd Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data D6 06 Number of elements to read (1750)
EA 01 00 00 Start at this byte offset (490) and return as much as will fit
2nd Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 490 through 979
3rd Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data D6 06 Number of elements to read (1750)
D4 03 00 00 Start at this offset (980) and return as much as will fit
3rd Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 980 through 1469
4th Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data D6 06 Number of elements to read (1750)
BE 05 00 00 Start at this offset (1470) and return as much as will fit
4th Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 1470 through1749
Reading the tag TotalCount that has 1750 SINTs using Symbol Instance
Addressing would consist of the following four service requests with service data,
as shown in the tables below. The value used for Instance ID was determined
using methods described in Chapter 2.
1st Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data D6 06 Number of elements to read (1750)
Data Offset 00 00 00 00 Start at this element (0) and return as much will fit
1st Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 0 thorough 489
2nd Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount)
Request Data D6 06 Number of elements to read (1750)
Data Offset EA 01 00 00 Start at this element (490) and return as much will fit
2nd Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Element 490 through 979
3rd Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data D6 06 Number of elements to read (1750)
Data Offset D4 03 00 00 Start at this element (980) and return as much will fit
3rd Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 980 through 1469
4th Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 52 Read Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data D6 06 Number of elements to read (1750)
Data Offset BE 05 00 00 Start at this element (1470) and return as much will fit
4th Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D2 Read Tag Fragmented Service (Reply)
Reserved 00
General Status 06 Reply Data Too Large
Extended Status Size 00 No extended status
Reply Data C2 00 SINT Tag Type Value
nn nn nnnn Data for Elements 1490 through 1749
Each response, except the last one, carries the General Status of 06, Reply Data
Too Large, to indicate that more data is present than is in this particular frame.
The last response carries the General Status of 0 indicating that the data read did
not exceed the message size limit. This means that the entire sequence of bytes
has been read.
Both Symbolic Segment Addressing and Symbol Instance Addressing may return
the following errors.
The Write Tag Service writes the data associated with the tag specified in the
path. The tag type must match exactly for the write to occur; the controller will
validate the tag type matches before executing the service.
Write the value of 14 to a DINT tag named CartonSize using Symbolic Segment
Addressing.
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4D Write Tag Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 43 61 72 74 6F 6E 53 69 7A 65 ANSI Ext. Symbolic Segment for CartonSize
Request Data C4 00 DINT Tag Type Value
01 00 Number of elements to write (1)
0E 00 00 00 Data 0000000E=14 decimal
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CD Write Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Write the value of 14 to a DINT tag named CartonSize using Symbolic Instance
Addressing. The value used for Instance ID was determined using methods
described in Chapter 2.
Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 4D Write Tag Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 36 71 Logical Segment for Instance ID for the tag CartonSize
Request Data C4 00 DINT Tag Type Value
01 00 Number of elements to write (1)
0E 00 00 00 Data 0000000E=14 decimal
Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service CD Write Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended statu
Both Symbolic Segment Addressing and Symbol Instance Addressing may return
the following errors.
The Write Tag Fragmented Service allows a client application to write to a tag in
the controller whose data will not fit into a single packet (approximately 500
bytes). The client must issue a series of requests to the controller to write all of the
data using this service.
The Request Service, Request Path Size, Request Path, and Number of Elements
fields remain the same for each request. The client must change the byte offset
field value with each request by the number of bytes it transferred in the previous
request.
The Byte Offset field is always expressed in number of bytes regardless of the data
type being read. In the examples that follow, the data type being read is SINT,
which happens to be a byte. In this case, the elements and offset are in the same
units, which will not be the case for other data types.
Writing 1750 SINTs to the tag TotalCount using Symbolic Segment Addressing
would consist of the following four service requests with service data as shown in
the tables that follow. The value used for Instance ID was determined using
methods described in Chapter 2.
1st Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 53 Read Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data C2 00 SINT Tag Type Value
D6 06 Total number of elements to write (1750)
00 00 00 00 Start at this offset.
nn, nn, nn Element Data for Elements 0 through 473
1st Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
2nd Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data C2 00 SINT Tag Type Value
D6 06 Total number of elements to write (1750)
DA 01 00 00 Start at this offset.
nn, nn, nn Element Data for Elements 474 through 947
2nd Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
3rd Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data C2 00 SINT Tag Type Value
D6 06 Total number of elements to write (1750)
B4 03 00 00 Start at this offset
nn, nn, nn Element Data for Elements 948 through 1421
3rd Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
4th Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 06 Request Path is 6 words (12 bytes) long
Request Path 91 0A 54 6F 74 61 6C 43 6F 75 6E 74 ANSI Ext. Symbolic Segment for TotalCount
Request Data C2 00 SINT Tag Type Value
D6 06 Total number of elements to write (1750)
8E 05 00 00 Start at this Offset
nn, nn, nn Element Data for Elements 1422 through 1749
4th Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Writing 1750 SINTs to the tag TotalCount using Symbol Instance Addressing
would consist of the following four service requests with service data as shown in
the tables that follow.
1st Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data C2 00 SINT Tag Type Value
D6 06 Number of elements to write (1750)
00 00 00 00 Start at this Offset
nn,nn,...nn Element Data for Elements 0 through 473
1st Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
.
2nd Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segments for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data C2 00 Tag Data Type
D6 06 Number of elements to write (1750)
EC 01 00 00 Start at this Offser
nn,nn,...nn Element Data (474 through 947)
2nd Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
3rdMessage Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data C2 00 Tag Data Type
D6 06 Number of elements to write (1750)
B4 03 00 00 Start at this Offset
nn,nn,...nn Element Data (948 through 1421)
3rd Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
4th Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 53 Write Tag Fragmented Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 1A E0 Logical Segment for Instance ID for the tag TotalCount
Request Data C2 00 Tag Data Type
D6 06 Number of elements to write (1750)
8E 05 00 00 Start at this Offset
nn,nn,...nn Element Data (1422 through 1749)
4th Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service D3 Write Tag Fragmented Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
The response to each request carries a General Status value of 00, Success status
indication, to indicate that the write operation was successful. No other Reply
Data is returned for this service.
Both Symbolic Segment Addressing and Symbol Instance Addressing may return
the following errors.
The size of masks must be the same or smaller than the size of the data type being
accessed. For complete data integrity (for example, to avoid the possibility of a
mix of old and new data when modifying dynamic data), the size of the mask
should match the size of the data type.
Example
Read Modify Write Tag Service may return the following errors.
The Multiple Service Packet Service carries more than one CIP request in a single
CIP explicit-message frame. Use this service to optimize CIP reads and writes by
grouping service requests together for faster request processing.
For details on this service, see the CIP Networks Library, Volume 1, Appendix A.
Example
The Multiple Service Packet Request Path contains the Message Router object
(Class 2, Instance 1). This is always the destination of the Multiple Service
Packets Request Path. The Request Data field contains the Number of Services
followed by byte offsets to the start of each service, followed by each of the CIP
requests, each following the standard Message Router Request format.
The Multiple Service Packet response follows the same Message Router Response
format as all CIP services; therefore, the General Status, Ext Status Size fields are
in the same CIP Service Request/Response Format as described in previous
examples. The Reply Data field contains the number of service replies followed by
the byte offset to the start of each reply, followed by each of the CIP responses.
Each of the responses follows the standard Message Router Response format.
Logix Data Structures A structure is a compound data type that stores a group of possibly different data
types that function as a single unit and serve a specific purpose. (For example, a
combination of values.)
A structure contains one or more members.
Each member can be an:
Atomic data type.
Another structured data type.
A single dimension array of an atomic or structure data type.
You can group most structures into arrays or use them in other structures.
For more information on data types and for information on creating structures,
including what types are not allowed, see the Logix5000 Controllers Design
Considerations Reference Manual, publication 1756-RM094.
Create an alias of the atomic member and access the alias instead of the
structure.
Create an atomic tag or UDT structure tag with an atomic member, and
then have the user program copy the data to and from the tag or atomic
member. Access the new tag or atomic member instead.
Atomic tags
Arrays of atomic tags
Other UDTs of atomic tags
Arrays of UDTs of atomic tags
Structure Boundaries
In a UDT structure, BOOLs are mapped to a host SINT member, and if they are
placed next to each other in a UDT structure, they are mapped so that they share
the same SINT. The host SINT is not visible in the Logix Designer application
Data Monitor, but the individual BOOLs are visible. The Pad bits or bytes that
are added as necessary to achieve this required alignment are not visible in the
Data Monitor.
For more details, see the Guidelines for User-Defined Structures section in
Chapter 3 of the Logix5000 Controllers Design Considerations Reference Manual,
publication 1756-RM094.
Member Order
It is also important for the client application to understand the byte order of the
data in the structure as it will be transmitted on the wire.
For normal UDTs that do not include any nested system structures, the size and
member order will be as shown in the Data Monitor view of the structure
definition in the Logix Designer application with padding to meet the alignment
rules, and hidden host members for BOOLs. Atomic members of the structure
are always sent low byte first on the wire. Data Monitor shows the Data Type Size
(in bytes) of the resulting structure, and the UDT structure template includes the
hidden BOOL host members.
In some cases, a UDT that has been manipulated by Import/Export may contain
other members that are not visible in Data Monitor. This document does not
address UDTs that have been modified using Import/Export.
The Tag Type Service Parameter for structures is always a 4-byte sequence. The
first two bytes are the values A0 and 02, followed by the latter two bytes, which
The Structure Handle comes from Template instance attribute 1 of the template
instance associated with the tag. It is a calculated field, but generally it is not
necessary to calculate the value. Reading and understanding the template
information provides you with all the required information about the structure
makeup to unambiguously access it. With that understanding, the client
application can use the Structure Handle value read from the template instance
attribute 1, rather than calculating it. For more information about structure
templates, see Chapter 2.
If you chose to calculate a Structure Handle, the process used to calculate this
value can be found on this website:
http://www.rockwellautomation.com/enabled/pdf/TypeEncode_CIPRW.pdf
In Logix controllers, arrays report the data type of its members. An array of an
atomic type reports the corresponding 2 byte Tag Type Service Parameter, while
an array of structures reports the corresponding 4 byte Tag Type Service
Parameter.
IMPORTANT Reading a structure before writing to it is one way to obtain the value for
this parameter, but that does not provide any understanding of the
structure makeup, which is critical information when manipulating
structure data. Also, the Structure Handle value is not unique among
structures. Some positional changes of members within an otherwise
identical structure will yield the same value.
The most appropriate way to access structures as a whole is to first read
their template information and understand the data packing. This assures
that the application knows what data type is in what position.
If you read the structure to get the Structure Handle value before writing to it, be
aware that the results may be ambiguous. Reserve this method only in cases where
the control system development is complete and no further data structure
changes will be made.
Introduction This chapter describes processes that CIP clients may need to utilize when
interacting with Logix5000 controller data, specifically, user-created tags. The
processes are as follows.
Finding the controller-scope tags that are created in a Logix5000 controller
Isolating user created tags from system tags and identify structured tags
Locating the structure template for a specific structure
Determining the structure makeup of a specific structure
Determining the data packing of the members of a structure when accessed
as a whole (that is, not member by member)
Determining when the list of tags and structure information needs to be
refreshed
How tags are organized in the Before examining the processes, let us look at how tags are organized in the
controller.
controller
A client application must interact with two vendor-specific objects that are
associated with tags in Logix5000 controllers: the symbol object and the template
object. Through this interaction, the client application learns the following.
What tags are created
If a tag is structure
What the structure members are
How the data is packed in a message when reading a structure
The following diagram shows the two objects in the Logix5000 controller that
are associated with tags. A client application must make use of the attributes and
services of these objects to assure it has an understanding of the tag data makeup
when reading or writing to tags.
Symbol object
When a tag is created, an instance of the Symbol class (Class ID 0x6B) is created
inside the controller. The name of the tag is stored in attribute 1 of the instance.
The data type of the tag is stored in attribute 2.
Instances of the Symbol class are not created in numerical order when a tag is
created, so the Symbol class defines a class-specific service called
Get_Instance_Attribute_List. This service helps with the process of finding a
specific instance of the class. It allows retrieval of the name and type attributes for
each instance of the class that has been created.
Template object
The Get_Attribute_List service directed to the Template object allows the client
application to retrieve one or more attributes from a specific instance of the
Template class. Template instance attributes provide information about the
template structure itself so the application can interpret what it receives when
using the Template_Read service.
The Template Read service is used to retrieve the template structure information
that describes the members of the structure, their ordering, and data types. This
information is required when accessing a structured tag as an entire structure to
understand the data packing in the message frame.
Create an alias tag for the atomic member that needs to be accessed.
These tags will then be present in the Symbol object instances and can be accessed
like any other atomic tag.
The above methods can also be used with structured tags of a UDT that contain a
nested Module-Defined, Add-On-Defined, or Predefined type member.
The STRING data type is a form of Predefined structure that would normally be
excluded after executing steps that will be described later. However, there is an
alternate method for the STRING type. The user can easily create UDT String
structures, including Strings of the same format as the standard STRING. Doing
this will allow external access to the string and avoid the issues of Predefined
structures.
To access any atomic tag that is visible in the Logix Designer application Data
Monitor, the user also has the option of manually entering into client SW the full
symbolic tag address (NAME in the Data Monitor). This includes atomic
members of any structure that are visible in Data Monitor. This only applies to
visible atomic tags and atomic members of structured tags.
Creating and maintaining a Some client applications will access atomic tags or atomic members of structured
tags simply by knowing the name of the tags it wants to access, while other client
symbol object list applications require the ability to learn what tags are present in the controller and
allow the user to pick the data they want to access. The former may not need to go
through all the steps indicated here. For example, if the name of the tags are
known and the Symbolic Segment Addressing method is used to access only
atomic tags or atomic members of structured tags, then reading all the symbol
instances or interpreting the template information is not required.
If the client application does need to know what tags are available or does attempt
to access structures as a whole, then it is important that the client have a list of the
key information about the tags necessary for proper access before attempting to
manipulate tag data. Having this information on-hand is required to
unambiguously identify the data type of each tag so that the application
understands how to interpret the data value associated with the tag.
You also need to make sure that this list is kept up to date. User program changes
frequently create or delete tags, as well as add, delete, and modify UDTs.
Use the steps that follow to create and maintain a list of controller-scope symbol
objects in a Logix5000 controller, associate each instance with a template object
instance if it is a structured tag, and then eliminate the symbol instances of data
that should not be accessed or manipulated by a client application.The rest of this
chapter outlines these steps in detail.
Step 1: Finding user-created This section describes the process used to learn what controller-scoped tags are
located in the Logix5000 controller by retrieving the Symbol Name and Symbol
controller scope tags in a Type attributes for each instance of the Symbol Object.
Logix5000 controller
The Get_Instance_Attribute_List (0x55) service returns instance IDs for each
created instance of the Symbol class, along with a list of the attribute data
associated with the requested attributes.
The steps the client application must use to retrieve all the instances are as
follows:
When General Status = 00 Success, then all the symbol instances that are created
have been returned.
The table below shows the format of the initial service request, which starts with
Symbol Object, Instance 0. This will return as much of the requested data as will
fit in the reply. Most controller programs will require multiple attempts to get all
the tags.
Analysis
The Reply Data includes the Instance ID along with the data values for
attributes 1 and 2.
The Symbol Name attribute is a variable length structure of type STRING
that consists of a UINT character count followed by the single octet
characters (ASCII encoded) in the name.
The Symbol Type attribute is a WORD, which is a 16-bit string,
representing the symbol data type that is described in the next step.
Any symbol instances that represent tags whose External Access is set to
None will not be included in the reply data.
The following example is a continuation from the previous one, assuming that the
controller had more symbols than would fit in one reply. The last instance
number shown in the previous example was 0x5D34 which, when incremented, is
0x5D35.
The table that follows shows the request for the next set of instances or attribute
data. The value 0x5D35 is used as the starting instance ID in the path.
The Logix5000 controller will retrieve data beginning with instance 0x5D35 and
return as much data as will fit in the message frame. Subsequent responses will
look like those in the following table.
The retrieval process is repeated until the General Status of 00 is received from
the Logix5000 controller, indicating the last of the data has been sent.
When the retrieval process is complete, the client has a list of the following items.
All the controller scope tags in the controller, including atomics,
structures, arrays, and aliases
Which instance of the Symbol class is associated with each controller scope
tag
Information about the data type of each controller scope tag, including
whether or not it is a structured tag
Step 2: Isolating user-created Once the application has retrieved the last of the data, the next step is to remove
the system tags, Predefined tags, Add-On-Defined tags, and Module-Defined
tags from system tags/ tags. This is accomplished by interpreting the Symbol Type, Symbol Name, and
identifying structured tags structure Template Name, structure first Member Name, and the Type of each
structure member.
The Symbol Type attribute can be examined to learn more about the tag. The
Symbol Type value is decoded as follows:
Atomic and structured tags are differentiated according to the value of bit 15.
Symbols where bit 12 =1 is a system tag are beyond the scope of this document
and should not be accessed.
For any tag type, the value of bits 13 and 14 indicates the dimensions of this tag as
shown in the following table:
The Template object contains information about structures. There are many
instances of the object class created to hold structures associated with data inside
the Logix5000 controller. When you create new User-Defined Types, a new
instance of the object class is created, and, like the Symbol class, the instance ID
numbers do not follow any particular order.
Structured tags are linked to the appropriate template object instance through the
Symbol Type attribute. For this reason, it is not necessary to read all the instances
of the Template class. Simply refer to the Symbol Type attribute. When Bit 12=0;
Bit15=1, then Bits 0-11 represent the instance ID of the template associated with
this tag.
For example, assume a tag exists in the controller named MachineSummary and
that it is a structure of type STRUCT_B. The Symbol Type attribute(attribute 2)
for this tag has the value 0x82E9. Bit 15 is set indicating this tag is a structured tag
and Bit 12 is reset so it is not a reserved tag. The value of bits 0-11 is 0x2E9 is the
instance ID of the Template object where this tag's structure makeup is defined
and its value is within the range of values that can be accessed. (See the rules
below.)We will use instance ID 0x2E9 in the example in the next step to retrieve
the structure information for a tag of this type.
Knowing how to interpret the Symbol Type attribute, you can begin to identify
tags that are not user-created from those that are user-created.
Beginning with the full list of symbol instances, eliminate tags that should not be
accessed or manipulated by applying the following rules.
1. Discard tags that are not in either of these valid ranges (eliminates
Predefined and String)
the Symbol Type, Bit 12=0, Bit 15=0, and Bits 0-11 range from 0x001-
0x0FF (atomics)
the Symbol Type, Bit 12=0, Bit 15=1, and Bits 0-11 range from 0x100-
0xEFF (structures, not including Predefined)
For template details, see Step 3: Determining the structure makeup for a
specific structure.
4. Locate any nested member structures within the remaining structures, by
checking the Type of each member. For any nested structures, repeat the
checks above for Type in valid range, Template Name and first Member
Name, and discard the total structure if a check fails. Continue until all
nested structures have been checked.
Following all the steps described above will leave only those tags that are
completely user-created.
Step 3: Determining the From the tags that remain, any tag where the Symbol Type Bit 15 = 1 is a
structured data type. It is necessary for the client application to read information
structure makeup for a specific from the Template object Instance ID that is associated with this tag. This
structure Instance ID is the value of Symbol Type, Bits 0-11. There are four attributes of
this instance that contain information about structured data types that are useful
to a client application that will interact with a UDT-based tag.
Read the following Template Instance attributes, using the instance ID in the
Request Path of the Get_Attribute_List service (0x03) to the Template class
(0x6C).
Attribute Description/Characteristics
1 This is the Tag Type Parameter used in Read/Write Tag service
Structure Handle
Data Type: UINT
2 This is the number of structure members
Template Member Count
Data Type: UINT
4 This is the number of 32-bit words
Template Object Definition Size
Data Type: UDINT
5 This is the number of bytes of the structure data
Template Structure Size
Data Type: UDINT
The table that follows shows how to read the list of attributes for a specific
instance of the Template Object associated with the STRUCT_B example.
The response in the table below contains a count of the items requested, followed
by a structured response for each item consisting of the attribute ID (16-bits),
status of retrieval (16-bits), and the attribute data (size varies).
Analysis
With the information returned in the previous example, the client application
now has all the information necessary to use the Template Read service to retrieve
the template member information.
Use the entire size calculated here in the request, regardless of how big it is.
The service handler in the Logix5000 controller will only return as much
data as will fit in the message frame, and will use the General Status = 06 to
indicate theres more to read. The client can then adjust the starting offset
(that is, new starting offset = bytes received +1)and reissue this request,
repeating the process until General Status = 0 is returned, indicating that
all data has been read. For smaller structures, these extra steps may not be
required, as all the data will fit in a single reply.
The structure data returned by the Template Read service has the format
shown in the figure that follows.
The response to the Template Read service is the Member Information above,
which consists of two 32-bit data values for each structure member.
The lower 16-bits are the INFO value. It can be one of following values:
The upper 16-bits represent the data type. For the meaning of this data, see
the description of the Symbol Type.
The second 32-bit value is the offset location of the member in the UDT
structure.
The offset given in the Member n offset value in the example that follows is where
the member is located in the stream of bytes returned from reading a tag of this
type that has been created in the controller.
Below is an example using the Template Read service to retrieve the member
information for a specific instance of the Template object. The example should
help you understand how to interpret the member information stored in the
template instance.
The structure that is accessed in this example is a user defined structure named
STRUCT_B that was defined with the following members:
BOOL named pilot_on
INT array of 12 elements named hourlyCount
REAL named rate
A tag of the type STRUCT_B was created and given the name
MachineSummary. This tag name is used in the following example. The instance
ID used in this example was determined by examining the Symbol Type attribute
of the tag MachineSummary, as described in Step 2, earlier in this chapter. The
Template Read service request and response to that instance is shown in the tables
that follow.
Example
Reading the structure information for the tag MachineSummary, which is a user
defined type called STRUCT_B.
5A 5A 5A 5A 5A 5A 5A 5A 5A 5A Member 1 Name: The name of this member for one or more members is chosen by the
53 54 52 55 43 54 5F 42 30 00 Logix Designer application. This is a host member for the BOOL (Member 2) that
follows. Member 1 is sent on the wire but not visible in Data Monitor to the user in the
Logix Designer application Data Monitor view. As indicated by the offset value for
Member 3, there are 3 bytes of pad inserted after the SINT for this host member, for
data alignment purposes. These pad bytes are sent on the wire when the entire
structure is read/written.
Following the member information are the UDT Template Name string and
structure member names, stored as null-terminated strings. For a UDT structure,
the Template Name string contains the Template Name followed by the
characters ;n plus additional characters. This may also be true for some non-UDT
structures. For other non-UDT structures, the semi-colon may be followed by
other characters, or just a NULL instead of the semi-colon and characters. Non-
UDT structures are beyond the scope of this publication and should not be
accessed as whole structures.
In the example above, the first and second members have the same offset. This is
typical of how BOOL members are mapped into UDTs. The first member is the
host member for the data described by the second member. The second member,
the visible member, is what is seen in Logix Designer application Data Monitor.
BOOLs in UDTs are typically mapped to a previous SINT (whose name begins
with the prefix ZZZZZZZZZZ) in the structure data stream. This SINT does
not appear in the Logix Designer application Data Monitor view. With SINT
host members, if more than eight contiguous BOOLs are defined, multiple
adjacent SINTs will be created to hold them. The bits are always mapped into
each SINT beginning with bit 0 thru bit 7 for contiguous BOOLS. If BOOLS
are defined non-contiguously in a UDT, there will be more than one host
member to which they are mapped. The Member Offset in the Template
identifies where the host SINT is located and the bit order of the BOOL in the
SINT is determined by the order of the bit in the structure. The host member is
sent on the wire when the tag is accessed, but the visible BOOL is only present in
the structure definition to enumerate the value and is not part of what is sent on
the wire.
Logix BOOL arrays are always multiples of BOOL[32] and are implemented as a
DWORD array.
Step 4: Determining the data An example of reading an entire structure to show how that data is transmitted
follows. The values for the tag accessed in this example are shown below.
packing of the members of a
structure when accessed as a Continuing with the example structured tag named MachineSummary is a tag of
whole type STRUCT_B. The members of the tag MachineSummary have the following
values:
pilot_on = 1
hourlyCount[0] = 0x00
hourlyCount[1] = 0x01
hourlyCount[2] = 0x02
hourlyCount[11] = 0x0b
rate = 1.0
The Read Tag service is used to retrieve this entire structure is formatted as
follows.
The amount of data returned (0x20 bytes) agrees with the value of Attribute # 5
(Template Structure Size = 0x20 as determined in Step 3) using the
Get_Attributes_List service.
Step 5: Determining when the The client application should periodically check for changes in the controller to
determine if it needs to repeat the process outlined in this chapter. Once
tags list and structure controller program development is complete, tags and UDT definitions generally
information need refreshing remain constant; however, it is possible that a the PLC program developer may
create or delete tags from time to time, or change a UDT definition. When that
happens, the symbol object instance associated with a tag may change, the
relationship between the template instance and the symbol instance may change,
or the data makeup of a UDT-based tag can change.
There are several attributes of an object inside the controller that indicate a
change was made to the controller. A change in these values can indicate that
there were changes to symbol instances, template instances, or both. These are
not the only changes indicated by these attributes, but these provide the most
straightforward way to determine when the client application should refresh the
list of created tags, while keeping the number of false indications to a minimum.
One method that can be used to check these attributes is to use the Multi Service
Packet Service (0x0a) to group the Get_Attribute_List service with the Read Tag
services. If either of the following situations occur, discard the Tag Read reply data
and refresh the symbol and template information:
The values returned for these attributes are different than the last time they
were read.
The General Status 0x05 (Path Not Known) is returned, which indicates
that a project download is in progress.
IMPORTANT Do not use the Multi Service Packet service to group the attribute check
with the Tag Write service, as this would allow data to be written before
determining whether the tag information needs to be re-read.
When writing to tags, first prepare the tags to be written then check these
attributes. If no change is indicated and the General Status of the request is
Success, proceed with writing the tag data, otherwise, refresh the tag and template
information as described. The tag write can then be followed by the attribute
reads to confirm that the tag was not changed in the small window before the
write. If the attribute check fails, the tag itself can be checked to confirm it did
not change.
The client application should always refresh this information after re-establishing
its CIP network connection with the Logix5000 controller (that is, after the
EtherNet/IP or ControlNet connection is broken and restored), or if ever a
General Status of 0x05 is returned when attempting to read these attributes.
The CPU Lock feature of Logix5000 controllers causes this specific service
request to return a General Status 0x10, Device State Conflict when the
controller is password locked. When in this state, controller memory is unable to
be altered, so the client application can assume that memory will not change.
Rockwell Automation suggests that upon receipt of the Device State Conflict for
the first time, the client application should refresh the tag information one time,
and then again, only upon a connection loss and reconnect or upon the receipt of
General Status 0x05, or upon a success response to this service that indicates that
the CPU is once again unlocked.
The following examples show Request Path strings for various data accesses using
native CIP service requests and addressing.
These examples show only a portion of a message frame for requests and
responses. References to atomic data types that are not dimensioned (not an
array) are fairly straightforward to construct. References to arrays, portions of
arrays, or atomic members of structures are not as straightforward. This section
will use examples to show how various references are constructed.
Atomic Members of Predefined The following examples access tags that return atomic data types.
Data Types Example 1 (Symbolic Segment Addressing Method)
Read a single integer tag named parts.The tag has a data type of INT and a value
of 42.
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 04 Request Path is 4 words (8 bytes) long
Request Path 91 05 70 61 72 74 73 00 ANSI Ext. Symbolic Segment for parts
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C3 00 INT Tag Type Value
2A 00 0x002A= 42 decimal
Read a single integer tag named parts.The tag has a data type of INT and a value
of 42.
Message Request Field Bytes (in hex) Description - Symbol Instance Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 03 Request Path is 3 words (6 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 82 25 Logical Segment for Instance ID for tag parts
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbol Instance Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C3 00 INT Tag Type Value
2A 00 002A = 42 decimal
Write the value of 14.5 to the 6th element of an array of REALs named
setpoints(setpoints[5]).
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4D Write Tag Service (Request)
Request Path Size 07 Request Path is 7 words (14 bytes) long
Request Path 91 09 73 65 74 70 6F 69 6E 74 73 00 28 05 ANSI Ext. Symbolic Segment for setpoints and
the Member segment for 5
Request Data CA 00 REAL Tag Type Value
01 00 Number of elements to write (1)
00 00 68 41 0x41680000 = 14.5 decimal
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CD Write Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 09 Request Path is 9 words (18 bytes) long
Request Path 91 07 70 72 6f 66 69 6c 65 00 ANSI Ext. Symbolic Segment for profile
28 00 Member Segment for 0
28 01 Member Segment for 1
29 00 01 01 Member Segment for 257
Request Data 02 00 Number of elements to read (2)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C4 00 DINT Tag Type Value
F0 02 00 00 0x000002F0 = 752 decimal
2C C7 00 00 0x0000C72C=50988 decimal
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 07 Request Path is 7 words (14 bytes) long
Request Path 91 06 64 77 65 6C 6C 33 ANSI Ext. Symbolic Segment for dwell3
91 03 61 63 63 00 ANSI Ext. Symbolic Segment for ACC'
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C4 00 DINT Tag Type Value
25 02 00 00 0x00000252 = 549 decimal
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4D Read Tag Service (Request)
Request Path Size 09 Request Path is 9 words (18 bytes) long
Request Path 91 0A 45 7272 6F 72 4C 69 60 69 74 ANSI Ext. Symbolic Segment for ErrorLimit
91 03 50 52 45 00 ANSI Ext. Symbolic Segment for PRE
Request Data C4 00 DINT Tag Type Value
01 00 Number of elements to write (1)
32 00 00 00 0x00000032 = 50 decimal
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Message Request Field Bytes (in hex) Description- Symbol Instance and Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 0A Request Path is 9 words (18 bytes) long
Request Path 20 6B Logical Segment for Symbol Class ID
25 00 D1 18 Logical Segment for Instance ID for tag struct3
91 05 74 6F 64 61 79 00 ANSI Ext. Symbolic Segment for member today
91 04 72 61 74 65 ANSI Ext. Symbolic Segment for member rate
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbol Instance and Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data CA 00 REAL Tag Type Service Parameter
00 00 80 41 16.0 decimal
Message Request Field Bytes (in hex) Description - Symbol Instance and Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 16 Request Path is 22 words (44 bytes) long
Request Path 20 6B 25 00 4B 0D Logical Segments for Symbol Class ID and Instance ID for myDstruct4
28 00 Element ID for element 0
91 07 6D 79 61 72 72 61 79 00 ANSI Ext. Symbolic Segment for myarray
28 01 Element ID for element 1
91 05 74 6F 64 61 79 00 ANSI Ext. Symbolic Segment for today
91 0B 68 6F 75 72 6C 79 43 6F 75 6E 74 00 ANSI Ext. Symbolic Segment for hourlyCount
28 03 Element ID for element 3
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description- Symbol Instance and Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C3 00 Data Type for INT
D0 5C 0x5CD0 = 23760 decimal
The values for BOOL 0 and 1 returned by the controller are 0x00 and 0xFF
respectively.
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 0A Request Path is 10 words (20 bytes) long
Request Path 91 07 73 74 72 75 63 74 32 00 Symbolic Segment for struct2
91 08 70 69 6C 6F 74 5F 6F 6E Symbolic Segment for pilot_on
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C1 00 BOOL Tag Type Value
FF BOOL value for 1
Accessing User-Defined This section shows examples of accessing simple structures to help illustrate the
message formats needed. The examples all use the Symbolic Segment Addressing
Structures method. The four structures below are defined and then various members of the
structures are accessed in the examples that follow.
Structure Name: STRUCT_A Structure Name: STRUCT_B
Member Data Type Member Data Type
limit4 BOOL pilot_on BOOL
limit7 BOOL hourlyCount INT [12]
travel DINT rate REAL
errors SINT
wear REAL
For the controller project file and EtherNet/IP traffic capture files examples
shown here, go to http://www.rockwellautomation.com/enabled/guides.html.
Example 1
Read the tag struct1 that is a tag of type STRUCT_A. This reads the entire
structure.
.
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 05 Request Path is 5 words (10 bytes) long
Request Path 91 07 73 74 72 75 63 74 31 00 ANSI Ext. Symbolic Segment for struct1
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data A0 02 C1 FA Tag Type for STRUCT_A
03 00 00 00 limit4 and limit7 members (bits 0 and 1 respectively) (BOOL) = 1,
55 00 00 00 travel member (DINT) = 0x55 (85 decimal),
77 00 00 00 errors member (SINT) = 0x77 (119 decimal),
33 33 2B 41 wear member (REAL) = 10.7 decimal
Example 2
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 08 Request Path is 8 words (16 bytes) long
Request Path 91 07 73 74 72 75 63 74 31 00 ANSI Ext. Symbolic Segment for struct1,
91 04 77 65 61 72 ANSI Ext. Symbolic Segment for wear
Request Data 01 00 Number of elements to read (1)
Example 3
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 0B Request Path is 11 words (22 bytes) long
Request Path 91 09 73 74 72 31 41 72 72 61 79 00 ANSI Ext. Symbolic Segment for str1Array,
28 08 Member ID for element 8,
91 06 74 72 61 76 65 6c ANSI Ext. Symbolic Segment for travel
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C4 00 DINT Tag Type Value
0F 27 00 00 0x0000270F=9999 decimal
Example 4
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 0D Request Path is 13 words (26 bytes) long
Request Path 91 07 73 74 72 75 63 74 32 00 ANSI Ext. Symbolic Segment for struct2,
91 0B 68 6f 75 72 6c 79 43 6F 75 6E 74 00 ANSI Ext. Symbolic Segment for hourlyCount,
28 04 Member Segment for element 4
Request Data 02 00 Number of elements to read (2)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C3 00 INT Type Value
05 00 0x0005=5 decimal
06 00 0x0006=6 decimal
Example 5
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 0C Request Path is 12 words (24 bytes) long
Request Path 91 07 73 74 72 75 63 74 33 00 ANSI Ext. Symbolic Segment for struct3,
91 05 74 6F 64 61 79 00 ANSI Ext. Symbolic Segment for today,
91 04 72 61 74 65 ANSI Ext. Symbolic Segment for rate
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data CA 00 REAL Tag Type Value
00 00 80 41 0x41800000=16.0 decimal
Example 6
Message Request Field Bytes (in hex) Description - Symbolic Segment Addressing
Request Service 4C Read Tag Service (Request)
Request Path Size 19 Request Path is 25 words (50 bytes) long
Request Path 91 0A 6D 79 44 73 74 72 75 63 74 34 ANSI Ext. Symbolic Segment for myDstruct4,
28 00 Element ID for element 0
91 07 6D 79 61 72 72 61 79 00 ANSI Ext. Symbolic Segment for myarray
28 01 Element ID for element 1
91 05 74 6F 64 61 79 00 ANSI Ext. Symbolic Segment for today
91 0B 68 6F 75 72 6C 79 43 6F 75 6E 74 00 ANSI Ext. Symbolic Segment for hourlyCount
28 03 Element ID for element 3
Request Data 01 00 Number of elements to read (1)
Message Reply Field Bytes (in hex) Description - Symbolic Segment Addressing
Reply Service CC Read Tag Service (Reply)
Reserved 00
General Status 00 Success
Extended Status Size 00 No extended status
Reply Data C3 00 INT Tag Type Value
D0 5C 0x5CD0=23760 decimal
Introduction The information in this chapter helps you to communicate with ControlLogix
controllers using CIP over the serial port. For more information about DFI, refer
to the DF1 Protocol and Command Set Reference Manual, publication
1770-6.5.16. For more information about CIP services used with Logix5000
controllers, see CIP Services on page 11.
The controller's serial port supports the DF1 protocol and PCCC commands.
CIP messages can also be delivered by encapsulating CIP explicit messages inside
of the PCCC commands 0x0A and 0x0B. All of the CIP services described in
Chapter 1 can be sent by using this method.
Unconnected Messaging (UCMM) PCCC Command Code 0B provides CIP unconnected explicit-message
capability over the controller's serial port. This can be used for infrequent
via PCCC requests to the controller (for example, to read or write ControlLogix tags) or to
establish an explicit message connection with the controller. See Connected
Explicit Messages via PCCC on page 68 for connected communication).
Connected Explicit Messages via PCCC Command Code 0A provides CIP explicit-message connection behavior.
The services described in CIP Services on page 11 are used within these
PCCC commands. For example, the only difference between connected explicit
messages via PCCC and an EtherNet/IP explicit message connection is the
wrapper that the CIP service is carried in. EtherNet/IP network uses Ethernet
and TCP/IP technology and this uses DF1 and PCCC.
TIP We assume that you are familiar with CIP and the information related to CIP
that is discussed here. Therefore, the details of the CIP portions of the frame
will not be fully described here. References to where more detailed
information can be found are provided below. If you are not familiar with CIP,
a tutorial CD ROM is available for purchase at http://
www.rockwellautomation.com/enabled/cipetraining.html.
The following table shows the fields used and where more information can be
found about specific fields of the command structure.
Like all CIP connections, there is an RPI value associated with the connection
that establishes the rate at which messages must be sent. If they are not sent at this
rate, timeouts can occur. The RPI timer should be reset whenever a message is
sent. If the timer ever reaches the RPI value, the connection should retransmit the
last sent message and keep the same sequence count. Upon detecting the same
sequence count, the target will not reprocess the whole message; it just resends
the same response already sent (it looks to the responder like a retry due to a lost
response). The connection timeout should be short enough that recovery from
noise or a temporary disconnect is relatively quick. It is better to scale the timeout
to something reasonable for noise recovery (20 seconds or so) and then do RPI
rate productions, rather than allow connections to repeatedly time out.
The PCCC status (STS) in the PCCC response indicates the success or failure of
the PCCC system to deliver the data across the PCCC link. It does not indicate
the success or failure of the CIP service in the reply. The status for that will be
present in the CIP service response, within the data field. See the CIP Services on
page 11 for details.
Connections are usually kept open for very long periods of time. However, it may
be necessary for the client to close the connection from time to time. In that case,
the client application must close the connection using the 0B command with a
CIP Forward_Close service request in it. It is not acceptable to allow connections
to timeout naturally and clean themselves up.
The following is an example of the fields for a CIP explicit message connection
using a Class 3 Transport encapsulated in PCCC sent unfragmented, using DF1
Full Duplex on RS-232.
Fragmentation Protocol The fragmentation protocol allows messages up to 510 bytes to be sent over
PCCC/DF1, which has an inherent limit of 240 bytes. It allows each fragment to
be identified as it is transferred, with each fragment being acknowledged (Ack or
Nak) before the next fragment is sent, and provides the ability for the client
device to abort the fragmentation sequence if necessary. This fragmentation
protocol is used only with the 0A and 0B PCCC commands.
PCCC Commands
Introduction PCCC commands are carried within DF1 packets to the serial port of the
Logix5000 controller. This option for accessing data table mappings inside the
Logix5000 controller is provided for backward compatibility with legacy
controllers that do not understand CIP. CIP is the native language of a
Logix5000 controller. Other applications that worked with our legacy controllers
over serial port could, with proper mapping of Logix5000 tags to data tables, be
used to access information in the Logix5000 controller.
IMPORTANT For details on mapping of tags to PLC/SLC data files or data tables, refer to the
Logix5000 Controllers Design Considerations Reference Manual, publication
1756-RM094, and the user assistance/online help in the Map PLC/SLC
Messages function within the Logix Designer application. To avoid data
mismatch, use an array tag of the same data type as the PLC/SLC file.
PCCC commands can also arrive at the controller in the following ways:
Via the RS-232 serial port
Encapsulated inside a ControlNet message
Encapsulated inside a EtherNet/IP message
This chapter identifies the PCCC commands supported by Logix and the
formatting required. A license from ODVA is not required for you to use the
PCCC commands described in this chapter.
Supported Subset of PCCC Logix controllers support the following subset of PCCC commands.
Commands PLC-2 Communication Commands
Unprotected Read
Protected Write
Unprotected Write
Protected Bit Write
Unprotected Bit Write
Initial Fields of All PCCC This section describes the initial fields present in all PCCC commands. These
fields are followed by command-specific fields, which are described in the rest of
Commands this chapter. (A PCCC Request/Reply has nothing to do with a CIP Request/
Reply as described in earlier chapters.)
In the following sections, the name of each command is listed in the following
format:
All Requests Start with these Fields: [CMD] [STS] [TNS] [FNC]
[CMD] 1-byte, Request command code
0x0F in PLC-5 and SLC commands
0x0N in PLC2 commands (N is the hex value for the command)
[STS] 1-byte, status code, always 0x00 in commands
[TNS] 16-bits, transaction identifier
[FNC] 1 byte, function code (not included in some PLC2 commands)
All Replies Start with these Fields: [CMD] [STS] [TNS]+[EXT STS]
[CMD] 1-byte, Reply command code
0x4F in PLC-5 and SLC commands
0x4N in PLC2 commands (N is the same hex value in the corresponding Request CMD)
[STS] 1-byte, status code
0x00 (success)
0xNN is error code (N is any hex value)
0xF0 means fourth field present (EXT STS] See below.
[TNS] 16-bits, unique transaction identifier
[EXT STS] 1-byte, extended status error code
only present if [STS]=0xF0
PLC-2 Communication Use the PLC-2 commands to access one tag (only one tag) in a Logix5000
controller. In addition to sending the command, you must also map the message
Commands to an INT(16 bit integer) tag in the Logix5000 controller. All the PLC2
commands will access the same tag, typically an INT array.
Logix handles protected and unprotected commands the same way, whether the
access for the data is set to Read/Write, Read Only, or None.
This command provides the read capability for the PLC-2 commands.
This command provides a protected write capability for the PLC-2 commands.
This command provides a basic write capability for the PLC-2 commands.
This command provides a protected bit write capability for the PLC-2
commands.
For each 3-field set, this command performs the following sequence:
This command provides a bit write capability for the PLC-2 commands. For each
3-field set, this command performs the following sequence:
PLC-5 Communication Each PLC-5 command requires a system address in one of the following forms:
Commands Logical binary or logical ASCII, which addresses data by file and element.
The first level of the logical binary must always be 0. This is required to
access controller-scoped tags.
The second level is the file number. This is also the level following the
letters in the logical ASCII form.
The next 1, 2, or 3 levels correspond to the array dimension indices as
follows: data[1][2][3].
Any subsequent levels of logical address access parts of the complex
types. Refer to CIP Data Types on page 11.
IMPORTANT Logical addressing requires use of data table mapping. Use a Logix array tag
that matches the data type of the PLC5 file. Members of SINT, INT, DINT, and
REAL arrays are contiguous in Logix memory. For more information on
Logical addressing, refer to the DF1 Protocol and Command Set Manual,
publication 1770-6.5.16
IMPORTANT The PLC-5 TYPED READ and TYPED WRITE commands access tags (elements)
of SINT, INT, DINT, or REAL only. The other PLC-5 commands access only
INTs, that is, 16-bit words.
Use the PLC-5 file data type that matches the data type of the Logix tag.
Addressing examples
The table below shows addressing examples for PLC-5 PCCC Messages.
For each 3-field sequence (address, AND mask, OR mask), this RMW command
performs the following procedure.
Request Format: [PLC-5 system address] [AND mask] [OR mask] + repeats(1)
[PLC-5 system address] specifies the word to be modified
[AND mask] 2 bytes (low byte first) specifying which bits in the word to reset (0=reset to 0)
[OR mask] 2 bytes (low byte first) specifying which bits in the word to set (1=set to 1)
Reply Format:
no data - only status
(1) These fields can be repeated up to 243 bytes.
For each 4-field sequence, this RMW-N command performs the following
procedure:
Request Format: [no of sets][PLC-5 system address] [mask length][AND mask][OR mask] +repeats(1)
[no of sets] indicates the number of sets of the following four fields.
[PLC-5 system address] specifies the word to be modified
[mask length] specifies either 2 or 4 byte masks. For this command, most Logix controllers only support 4-
byte mask; use RMW command (FNC=26) for 2-byte mask
[AND mask] 2 or 4 bytes (low byte first) specifying which bits in the word to reset (0=reset to 0)
[OR mask] 2 or 4 bytes (low byte first) specifying which bits in the word to set (1= set to 1)
Reply Format: [data]
[data]
for a successful command ([STS]=0x00), data may be returned, but the Logix data format is not documented
for an unsuccessful command ([STS]=0xF0), a byte (error code) occurs; data may be returned, but the Logix data
format is not documented.
(1) The last four fields, starting with address can be repeated up to 243 bytes.
The typed read command reads a block of data starting at the PLC-5 system
address plus the packet offset.
The typed write command writes a block of data starting at the PLC-5 system
address plus the packet offset.
Request Format: [packet offset] [total transaction][PLC-5 system address] [type/ID] [data]
[packet offset] 2 bytes, offset in number of elements
[total transaction] 2 bytes, number of elements in complete transaction
[PLC-5 system address]
[type/ID] 1 byte (for integers) or by 2 bytes (for float), type and size of elements.
SINT, INT, DINT (type: integer; size 1,2,4 bytes) REAL (type: float, size 4 bytes)
Integer conversion; error if data value too large for target integer type (SINT or INT)
For details about Type/ID encoding, refer to the DF1 Protocol and Command Set Reference Manual, publication
1770-6.5.16
[data]
Reply Format:
no data, only status
The word range write command will write a block of words starting at the PLC-5
system address plus the word offset.
For the 3-field sequence, this command performs the following procedure:
SLC Communication Commands The SLC commands use strictly a logical form of addressing
(for example, file/element/sub-element). For details about mapping the SLC files
to Logix5000 tags, refer to the Logix5000 Controllers Design Considerations
Reference Manual, publication 1756-RM094.
Logix handles protected and unprotected commands the same way, whether the
access for data is set to Read/Write, Read Only, or None.
IMPORTANT For the SLC Typed Read and Typed Write commands, map the data files to Logix
tags of types INT, DINT, or REAL only. Use an SLC or MicroLogix file data type
that matches the data type of the Logix tag.
For INT tags, use file type 85hex (Binary) or 89hex (Integer)
For DINT tags, use file type 91hex (Long - MicroLogix only)
For REAL tags, use file type 8Ahex (Float)
For more information on SLC file types, refer to the DF1 Protocol and Command
Set Reference Manual, publication 1770-6.5.16
SLC logical addressing has a limited number of logical address levels so there are
some special concerns.
The service is supported for compatibility with SLC modules. It reads data from
the logical address.
Notes:
Rockwell Automation provides technical information on the Web to assist you in using its products.
At http://www.rockwellautomation.com/support/, you can find technical manuals, a knowledge base of FAQs, technical and
application notes, sample code and links to software service packs, and a MySupport feature that you can customize to make the
best use of these tools.
For an additional level of technical phone support for installation, configuration, and troubleshooting, we offer TechConnect
support programs. For more information, contact your local distributor or Rockwell Automation representative,
or visit http://www.rockwellautomation.com/support/.
Installation Assistance
If you experience a problem within the first 24 hours of installation, review the information that is contained in this manual.
You can contact Customer Support for initial help in getting your product up and running.
Rockwell Automation tests all of its products to ensure that they are fully operational when shipped from the manufacturing facility.
However, if your product is not functioning and needs to be returned, follow these procedures.
United States Contact your distributor. You must provide a Customer Support case number (call the phone number above to obtain one) to your
distributor to complete the return process.
Outside United States Please contact your local Rockwell Automation representative for the return procedure.
Documentation Feedback
Your comments will help us serve your documentation needs better. If you have any suggestions on how to improve this document,
complete this form, publication RA-DU002, available at http://www.rockwellautomation.com/literature/.
Rockwell Otomasyon Ticaret A.., Kar Plaza Merkezi E Blok Kat:6 34752 erenky, stanbul, Tel: +90 (216) 5698400