Example: Logix 5000’s Implementation of the CIP Object Model
Example: Logix 5000’s Implementation of Object Addressing
The Allen-Bradley Driver in Ignition
Addressing CIP Objects and Important Service Codes
Important Note Regarding MicroLogix, PLC5, & SLC
A Note on Multiple Service Packets and the Micro800 Driver
What is Allen-Bradley?
Allen-Bradley is the vendor name for a popular brand of PLC products owned by Rockwell Automation. Such PLCs rely on the connection-based, application layer protocol standard, Common Industrial Protocol (CIP), developed and distributed by the Open DeviceNet Vendors Association (ODVA).
How does CIP work?
CIP consists of a library of many possible service codes that can be requested from a device for specific read, write, function, and even custom vendor-specific commands. In order to properly establish a connection and pass these service codes to devices, you must first ensure the following requirements are being met:
- The device you’re connecting to comes from official vendors with ODVA authorization..
- The connection follows one or more CIP Network Adaptations standards.
- Message formats contain proper identifiers and addressing against the CIP Object Model.
ODVA Authorization
Use of CIP to develop your own industrial automation equipment requires proprietary frameworks. This is where Rockwell Automation’s Allen-Bradley brand of PLCs comes into play. They are a vendor with proper authorization to manufacture chipsets that explicitly support CIP standards.
CIP Network Adaptations
There are four possible Network Adaptations that exist for CIP’s connect-based procedure. Each is used for different plant floor scenarios:
- EtherNet/IP
- CompoNet
- ControlNet
- DeviceNet
The Allen-Bradley PLCs supported by Ignition follow two of the four possible Network Adaptations of CIP communication: EtherNet/IP and ControlNet.
In order to distinguish between different adaptations of CIP when handling service requests, one of four unique identifier formats are prepended to the message’s frame for identification.
In the diagram above, the data section of the CIP message structure is responsible for containing the service codes as well as resulting outcomes. The term CRC is an acronym for Cyclic Redundancy Code which acts as the primary means of checking for possible corruption in the frame’s data after transmission. This corruption check works by first generating a CRC during a producer’s preparation to send a message frame out into its network. Once one or more consumers receive this message, they will check the CRC for malformations before unpacking any service codes.
CIP Object Model
The CIP Object Model provides a base framework for PLC vendors to follow when organizing all of the necessary data types and structures for a device’s program. This can lead to both varying terminology and selection of the object model’s data types.
In modern Allen-Bradley models, CIP objects are used as the main categories of data types housing various attributes. In order to access specific attributes in a request, an existing attribute ID is specified towards one of following object types:
- Identity
- Wall-Clock Timed
- Modbus-Serial Link
- TCP/IP
- Ethernet Link
- USB
- Symbol
The Ignition Allen-Bradley driver suite only concerns itself with two of the CIP object types: Identity and Symbol.
- The Identity object provides the general information and identification of a device.
- The Symbol object provides access to the user-programmed tags and its acquired plant floor data.
Example: Logix 5000’s Implementation of the CIP Object Model
Allen-Bradley models (ControlLogix, CompactLogix, SLC, PLC-5, Micro800, etc.) may vary in their supported data structures and programming functions. Logix 5000 can be defined as a family of specific Allen-Bradley models where each model is expected to follow the same set of data type support and service requests.
The Logix 5000 family makes use of three of the CIP object model’s data types and defines them as tags when organized during programming:
- Atomic
- Structure
- Array
Once a PLC programmer has acquired the appropriate model for their needs, CIP objects and the available data types are then further defined through a programming software in preparation for messaging service requests during plant floor operations.
Explicit Messaging
Explicit messaging is a CIP-specific term that describes the overall request message format containing all CIP service codes, object addressing, and network identifier specifications being followed. It's important to understand that this complexity behind the message format as a whole affects the range of which Allen-Bradley models can be supported by Ignition. Not every model will support the same list of service codes and identifiers.
This type of messaging is also present/used during client/server communication between Ignition and supported AB devices through the use of the Ethernet/IP CIP network adaptation.
Example: Logix 5000’s Implementation of Object Addressing
When referring to the Logix 5000 family of devices, you can expect specific CIP service codes to be available options across this subset of models. Other model families may have the ability to allow user defined service codes and functions, but Logix 5000 focuses specifically on read and write operations.
The Logix 5000 family also provides two Symbolic Addressing methods which define how its tags (CIP objects) can be addressed when using an explicit messaging format:
- Symbolic Segment
- Tags can be accessed directly by tag name in ASCII format.
- Best used for devices handling small to moderate amounts of data.
- Symbolic Instance
- Requires tags to be configured with additional instance IDs on device programming.
- Tags will be requested through known instance IDs.
- Best used for devices handling large amounts of data.
- Only available for model versions 21 and/or higher.
Implicit Messaging
Communication protocol between PLCs and I/O nodes in the plant floor involve a Producer/Consumer model, which is a multicast transmission where one producer (i.e. PLC) passes a request with a unique identifier to be recognized by one or more consumers (i.e. I/O nodes) that exist on a given network. This is also known as Implicit messaging.
The Ignition driver does not make use of this messaging type during CIP connections. Instead, this type of messaging is where potential ControlNet Network Adaptations may be used, since other devices residing in a network of Allen-Bradley PLCs may not require Ethernet connections.
The Allen-Bradley Driver in Ignition
The Ignition user manual provides information on all the currently supported models of Allen-Bradley PLCs and how to set up a basic connection. Depending on the family of device models, some configurations may vary, but keep in mind a few consistencies:
- Ignition can only establish TCP connections against Allen-Bradley devices. Any use of UDP will only exist between PLCs.
- Allen-Bradley must contain an Ethernet/IP module to connect. Without it, specification of the required IP address on the device settings will not be possible.
- Ignition will connect using the defined IP address of a given PLC directly, or to a ControlLogix Gateway with additional connection path information required to reach the PLC. See Connection Path details in the Ignition user manual for more information.
It’s important to keep these considerations in mind since Allen-Bradley hardware provides more variety in possible configurations than the Ignition driver’s range of support.
Addressing CIP Objects and Important Service Codes
Earlier it was mentioned in the Logix 5000 examples that service codes are the important data unpacked from a CIP request message when sent to a device. Service codes explain the following:
- How a device uses the CIP Object Model
- How a device accomplishes Explicit Messaging
The following listings below use Symbolic Addressing:
- Allen-Bradley Drivers Module
- Allen-Bradley CompactLogix: Legacy, CompactLogix PLCs up to firmware v20.18.
- Allen-Bradley ControlLogix: Legacy, ControlLogix PLCs up to firmware v20.18.
- Allen-Bradley Logix5000 Driver Module
- Allen-Bradley Logix Driver: Allen-Bradley Logix family devices. Optimized for devices with firmware v21+ but supports earlier firmware versions with significantly reduced performance.
- Allen-Bradley Micro800 Driver Module
In this method CIP Objects are described as Tags and are accessed using Symbolic Addressing.
Important Note Regarding MicroLogix, PLC5, & SLC
Since the other supported model types such as MicroLogix 1100/1400, PLC5, and SLC do not use Symbolic Addressing, CIP specific service codes are not exposed in the same way and are unavailable for listing.
Wireshark Examples
In order to better visualize the service codes mentioned above, you can observe a Wireshark capture and its default exposure of CIP packets.
The service codes listed below summarize important message values (Hexadecimal) more likely to be seen during Wireshark captures.
Service Type | Service Code |
Get Attribute List | 0xac |
Multiple Service Packet (Not Available for Micro800) | 0x0a |
Read Tag | 0x4c |
Read Tag Fragmented (First Message) | 0x52 |
Write Tag | 0x4d |
Write Tag Fragmented (First Message) | 0x53 |
Read Modify Write Tag | 0x4e |
Identity / Browsing
In this example, a v21+ CompactLogix device has already accepted a TCP connection with Ignition’s Logix driver. Ignition is now attempting to request from both the Identity object and Symbol object for general device information as well as any browsable tags programmed to the device. These packets come from messages sent by the CIP Communication Manager (CM) periodically for the duration of the device connection.
In the image above, the message stating Class (0xac) - Get Attribute List describes the Allen-Bradley driver (the client) requesting a set of attributes that will quickly notify Ignition if any changes occurred across any symbols/templates (the addresses pointing to a device’s tags). If any changes are detected in the device’s response, a re-browse occurs on Ignition’s side to reflect the changes stated by the device.
For this example, no changes were detected on the device. In the image above, the response of the service request Get Attributes All - 0xac provides attributes (Revision, Product Name, Status, etc.) from the device’s Identity object. This can be found under the capture’s expandable section: CIP Connection Manager.
Read Requests
In this example, a v21+ CompactLogix device has already accepted a TCP connection with Ignition’s Logix driver. The capture is a result of subscribing to a random tag in the OPC Quick Client. These packets come from the Wiresharks’ exposed Common Industrial Protocol (CIP) packets and are expected to occur periodically for the duration of tag subscription.
In the image above, the message stating Multiple Service Packet - Service (0x4c) describes the Allen-Bradley driver requesting data from one or more tags in the device. When looking at the packet itself and expanding the Common Industrial Protocol section’s Multiple Service Packet (Request), you can locate the single tag request from the expandable section Service Packet #1: …. Then will you be able to observe specific symbol addressing described within the Request Path by checking the Instance and Member attributes.
A Note on Multiple Service Packets and the Micro800 Driver
Multiple Service Packet Service (0x0a) can be described as an additional wrapper for CIP requests. It allows one or more requests, of potentially different types (read, write, etc.), to be bundled into a single request for efficiency. Allen-Bradley device connections that support this service are expected to contain the setting, CIP Connection Size, which basically allows users to control the maximum number of service requests that can be bundled into a single request.
Compared to the Logix and Legacy drivers that use the same symbolic addressing, the Micro800 driver does not support Multiple Service Packets. This is will result in some noticeable differences during a Wireshark capture:
On the image above, you can see a read service code (0x4c) is being called against the tag MyRTC. While this may appear as a simple read request, there are some key differences occurring in this capture example when compared to a Logix/Legacy driver device connection:
- The tag in the snapshot is a tag member defined within a structure. The driver is able to make a direct request to this tag using the address provided by a prior CSV import against the device connection. No OPC subscriptions have been created by any client (Ignition) during this test.
- This service request is being called in its own individual packet and not bundled (no Multiple Service) with other tag reads.
- If you compare the contents of the Request Path in the Common Industrial Protocol section of this Micro800 image with the Logix example, you will notice that the attributes Instance and Member have been replaced with the attribute ANSI Symbol.
- Instance/Member attributes allow Logix 5000 devices to take full advantage of Symbolic Addressing in Allen-Bradley devices since they can locate tags within complex structures using a minimal amount of characters (hexadecimal values). Addressing a tag in the device using ANSI Symbols can potentially require exceedingly long character strings, which is less efficient when passed into a data frame over Ethernet.
Write Requests
In this example, a v21+ CompactLogix device has already accepted a TCP connection with Ignition’s Logix driver. The capture is a result of writing to a random tag in the OPC Quick Client. These packets come from the Wireshark’s exposed Common Industrial Protocol (CIP) packets:
In the image above, the message stating Multiple Service Packet - Service (0x4d) describes the Allen-Bradley driver writing data to one or more tags in the device. When looking at the packet itself and expanding the Common Industrial Protocol section’s Multiple Service Packet (Request), you can locate the single tag request from the expandable section Service Packet #1: …. Then will you be able to observe specific symbolic addressing described within the Request Path by checking the Instance and Member attributes.
Comments
0 comments
Article is closed for comments.