How Tag Length Impacts Polling Performance

Overview

The ACM ControlLogix protocol driver uses EthernetIP/CIP Explicit Connected Messaging to browse, read and write tags from an end device back to the ACM host. These messages are optimized to request as many OPC tag items into a single request as possible based on factors such as max packet size, item interval and priority to name a few. The longer the length of a tagname, when combined with other items in a request, will reduce the overall amount of tags that can be polled in a single request/response transaction. The following paragraphs will explain this in detail and provide some examples and guidelines the PLC programmer can reference to ensure the tag load is designed with performance in mind when using the AutoSol Communication Manager® (ACM) ControlLogix protocol driver.

General Message Structure

When reading and writing OPC items, the driver uses the CIP Multiple Service Request (0x0A) message structure to pack individual Read Tag Service (0x4C) and Write Tag Service (0x4D) requests together. A message (incoming from device or outgoing to device) is limited to about 512 bytes. After header bytes are accounted for the 0x0A service has about 475 bytes to work with.

ReadingTags

When an OPC item is activated, the ControlLogix driver will attempt to place the request for that item into an existing message if it can fit. The length of the tag name is evaluated for how many bytes it would add (as an additional 0x4C request) to the existing message. Its data type is also evaluated for the length of the response to ensure that value can be returned by the existing response message. If either one makes the existing message exceed the 475 byte limit, it is put into another message or a brand new one as the first item in that message. The following examples describe how tags are encoded as 0x4C read requests and the potential impact this has on communication.

Example Tag Read: Station_On

The 0x4C Read Tag Request Service would form the following byte pattern to be inserted into the 0x0A service request:

4C 06 91 0A 53 74 61 74 69 6F 6E 5F 4F 6E 01 00

This service call consumes 16 bytes plus an additional two bytes for the offset position for a total of 18 bytes in the 0x0A service encapsulating it. If similar OPC tag names were to be activated with the same length, we could estimate a message payload of roughly 26 OPC tags (475/18= 26). This is assuming the return data types can fit in the response message returning from the device.

Example Tag Read: Station_OnOffIndicator

The 0x4C Read Tag Request Service would form the following byte pattern to be inserted into the 0x0A service request:

4C 0C 91 16 53 74 61 74 69 6F 6E 5F 4F 6E 4F 66 66 49 6E 64 69 63 61 74 6F 72 01 00

This service call consumes 28 bytes plus an additional two bytes for the offset position for a total of 30 bytes in the 0x0A service encapsulating it. If similar OPC tag names were to be activated with the same length we could estimate a message payload of roughly 15 OPC tags (475/30= 15). This is assuming the return data types can fit in the response message returning from the device. This is nearly half the number of items the previous example was able to browse in a single request/response transaction. This would result in twice the traffic packets of the previous example to read 25 tags!

Example Structured Tag Read: S01.On

The 0x4C Read Tag Request Service would form the following byte pattern to be inserted into the 0x0A service request:

4C 05 91 04 53 30 31 00 91 02 4F 6E 01 00

This service call consumes 14 bytes plus an additional two bytes for the offset position for a total of 16 bytes in the 0x0A service encapsulating it. If similar OPC tag names were to be activated with the same length we could estimate a message payload of roughly 29 OPC tags (475/16= 29). This is assuming the return data types can fit in the response message returning from the device. 

Example Structured Tag Read: Station_01.Station_OnOffIndicator

The 0x4C Read Tag Request Service would form the following byte pattern to be inserted into the 0x0A service request:

4C 12 91 0A 53 74 61 74 69 6F 6E 5F 30 31 91 16 53 74 61 74 69 6F 6E 5F 4F 6E 4F 66 66 49 6E 64 69 63 61 74 6F 72 01 00

This service call consumes 40 bytes plus an additional two bytes for the offset position for a total of 42 bytes in the 0x0A service encapsulating it. If similar OPC tag names were to be activated with the same length we could estimate a message payload of roughly 11 OPC tags (475/42= 11). This is assuming the return data types can fit in the response message returning from the device. This is nearly a third the number of items the previous example was able to browse in a single request/response transaction. This would result in three times the traffic packets of the previous example to read 25 tags!