Application Guide:

ControlLogix Data Collection with RSLinx Classic

Updated For RSLinx Classic 2.50.00 (CPR 7)

 

Rockwell Software

Document Version: 2.50.00 (CPR 7)

 

 

 

Introduction. 3

Design Tips for Optimal Performance. 3

Give the ControlLogix Processor Enough Communications Bandwidth. 3

The Continuous Task. 3

Periodic Tasks. 4

Using Both a Continuous and Periodic Tasks. 5

Configuring ControlLogix Processors as Data Concentrators. 5

Maximize ControlLogix Communications Bandwidth Usage. 5

Have only one RSLinx Classic communicate to any ControlLogix Processor 5

Use RSLinx Classic Gateway to Get Data into Many Stations. 6

Collect Data from Arrays or UDT structures. 6

Separate data collection from time critical control programs. 6

Don’t poll data too fast 6

Keep Tags on Scan. 6

Use a Faster ControlLogix Processor. 7

Ensure RSLinx Classic and ControlLogix versions are current enough. 7

Configuring RSLinx Classic. 7

Topic Parameters. 9

Polled Messages. 9

Unsolicited Messages. 9

Communications Time-Out 9

Use Symbols. 10

RSLogix 5000 Automatically Configures Topics in RSLinx Classic. 10

Understanding ControlLogix Data Collection. 10

Step-by-Step. 10

Read Optimization. 12

Array optimization. 12

Boolean Array Optimization. 12

UDT optimization. 13

First Level or “Scattered” Optimization. 15

How much data can be read in a ControlLogix Optimized Packet?. 15

Write Optimization. 15

How to Use Write Optimization. 15

Array optimization for writes. 15

How many tags can be sent in a write packet to the ControlLogix?. 16

Data Type. 16

Max. Items that fit into a Write Packet 16

RSLinx Classic “Smart” Polling.. 16

How RSLinx Classic Uses ControlLogix Connections. 16

Memory Consumption in the ControlLogix Processor. 18

Communication Event Log.. 19

Getting RSLinx Classic Data into Applications. 20

Logix5000 Tag Import Utility - Import ControlLogix Tags Into RSView and RSSQL  20

Browsing and Selecting ControlLogix Tags. 20

Miscellaneous RSLinx Classic Features and Tips. 22

Backup/Restore RSLinx Classic Configurations To/From a File. 22

ControlLogix Data Monitor. 23

RSLinx Classic’s Copy DDE/OPC link supports browsing ControlLogix Tags. 24

Getting Module Information in RSLinx Classic. 25

Application Notes. 26

Put Tags on Scan at the Same Time. 27

Changing ControlLogix Tags While On Scan. 27

Redundant RSLinx Classic Gateway Servers with RSView’s NodeSwitch Command  28

Redundancy for ControlLogix processors. 28

Using ControlLogix Strings. 28

Troubleshooting.. 29

Performance. 29

Throughput vs. System Overhead Time Slice with a Continuous Task. 29

Throughput vs. Periodic Rate with a Periodic Task. 30

Throughput vs. System Overhead Time Slice and Periodic Rate with a Continuous and a Periodic Task. 32

Processor Type vs. Performance. 32

 


Introduction

This document provides design tips, troubleshooting, application notes, and performance data for performing RSLinx Classic data collection to ControlLogix processors.

 

Design Tips for Optimal Performance

Give the ControlLogix Processor Enough Communications Bandwidth

The ControlLogix processor’s task configuration determines the communications bandwidth available for data collection. There is a tradeoff between faster task execution times and data collection performance. The default setting in the ControlLogix processor is optimized for fast task execution. You will need to find the appropriate balance between task execution time and data collection performance for your application. The ControlLogix processor can run two types of tasks; continuous and periodic. The following gives an explanation of each and how their configurations affect communications bandwidth.

 

The Continuous Task

This is the default task type and only one can exist. The ControlLogix CPU constantly swaps between running the task and servicing communications. The System Overhead Time Slice dictates how much relative time can be allocated for all communications vs. running the task. Let’s consider an example where the System Overhead Time Slice was set to 10%.  In this case, for every 10ms we can expect that 9ms will be spent running the task and 1ms for all communications including RSLinx Classic data collection, motion, I/O, and messaging. Increasing the System Overhead Time Slice can and usually does increase the task scan time. The System Overhead Time Slice is a property of the ControlLogix Processor and can be set in RSLogix under Edit->Controller Properties. This can also be modified with an OPC tag in conjunction with the ControlLogix Set command. (Ladder logic)

 

 

The “Advanced” tab of the Controller Properties in RSLogix5000, showing the “System Overhead Time Slice” box.

 

 

 

 

The “Configuration” tab of the Task Properties in RSLogix5000 for the continuous task, showing the Max Scan Time of the task

 

 

Periodic Tasks

A periodic task runs without being interrupted by communications. Communications are only serviced in-between task executions. More communications bandwidth can be allocated by increasing the Periodic Rate of the periodic task so that it runs less frequently. Conversely, the more tightly a periodic task is scheduled to run the less communications bandwidth the ControlLogix processor has. For example, if a periodic task takes 30ms to run and it is scheduled to run every 50ms then communications will be blocked for 30ms and then will be serviced for the next 20ms. Motion, I/O, and messaging also need to be serviced in-between periodic task executions. Note that the System Overhead Time Slice has no effect on communications bandwidth relative to a periodic task.

 

With multiple periodic tasks communications are still only serviced in-between running the periodic tasks. More periodic tasks will make scheduling more complicated and will decrease communications bandwidth.

 

 

 

The “Configuration” tab of the Task Properties in RSLogix5000 for a periodic task, showing the Periodic Rate and the Scan Times of the task.

 

 

Using Both a Continuous and Periodic Tasks

If there is a mix of a periodic task(s) and a continuous task then communications bandwidth will be limited. Communications will only be serviced while the continuous task is running at the proportion determined by the System Overhead Time Slice. The continuous task can only run in between periodic task executions.

If using a mix of continuous and periodic tasks then both the System Overhead Time Slice and the Periodic Rate(s) will have to be increased to allocate more communications bandwidth. If only one of these parameters is increased then task scan times may adversely increase with little increase to communications bandwidth.  First, eliminate any unnecessary tasks by consolidating your PLC code into fewer tasks. Then, increase the Periodic Rate(s) of the periodic task(s) as much as possible so the task(s) only run as often as necessary. Finally, increase the System Overhead Time Slice.

 

Configuring ControlLogix Processors as Data Concentrators

If a ControlLogix processor is going to function primarily as a data concentrator then use only one task to maximize the communications bandwidth. Having only one task in the ControlLogix processor maximizes communications throughput.

Maximize ControlLogix Communications Bandwidth Usage

Have only one RSLinx Classic communicate to any ControlLogix Processor

We highly recommend having only one RSLinx Classic communicating to any ControlLogix processor, or two if redundant data servers are needed. RSLinx Classic has been designed to optimize communications to so using more than one RSLinx Classic to any controller will bypass these optimizations and increase the ControlLogix CPU and memory resources needed to communicate. These resources often account for data acquisition performance bottlenecks.

 

It’s OK to have an RSLinx Classic station communicate to more than one ControlLogix processor. There is no physical limit on how many ControlLogix processors one RSLinx Classic can communicate to but there is a practical limit imposed by workstation CPU resources.

 

Use RSLinx Classic Gateway to Get Data into Many Stations

In many applications you may need to get ControlLogix data into several HMI, batch, or other data collection stations. Leverage RSLinx Classic Gateway to achieve data collection on several stations without having each station communicate to ControlLogix controller(s) directly. Each station will connect via Remote OPC to RSLinx Classic Gateway. RSLinx Classic Gateway optimizes several data collection stations’ requests to the ControlLogix, which minimizes communication burden. For example, if several stations request the same tag RSLinx Classic Gateway will only request it once from the ControlLogix and serve it up to each of the data collection stations. There is no physical limit on how many Remote OPC clients can connect to RSLinx Classic Gateway.

 

Leverage RSLinx Classic Gateway Correctly

This is very important. RSLinx Classic Gateway to remote RSView or other remote data collection applications is used differently than with RSLogix. For data collection, remote OPC is used. This is achieved by configuring DDE/OPC topics on the RSLinx Classic Gateway and having the data collection stations connect via Remote OPC. Note that RSLinx Classic will not even be used on the data collection stations.

In contrast, RSLogix has to have a local RSLinx Classic with a TCP driver that references a driver on the RSLinx Classic Gateway. Do not use this setup for data collection as it bypasses RSLinx Classic optimization and creates more communication burden on the ControlLogix.

 

Eliminate a single point of failure with redundant RSLinx Classic Gateways

This is easily done with having a backup RSLinx Classic Gateway server available. If the RSLinx Classic Gateway server fails then all HMI stations can switch their data collection to the backup RSLinx Classic Gateway server. RSView for example has a simple node-switch command that will switch the data collection from one RSLinx Classic Gateway server to another.  See the application Note section of the document for an example.

 

TIP: One option to reduce hardware cost is to make one of the HMI stations the RSLinx Classic Gateway server or backup server.

 

Collect Data from Arrays or UDT structures

Collecting data contained in arrays or UDTs that can be optimized will use less ControlLogix processor CPU resources and memory. Array optimization happens automatically when array elements of a one dimensional array are put on scan by a data collection application at the same time. The ControlLogix processor will internally treat a range of these array elements as a single tag thus consuming less CPU and memory resources.

UDT optimization works by having RSLinx Classic grab the entire UDT structure when any of the structure’s members are put on scan and the UDT optimization is enabled in RSLinx Classic. See the UDT Optimization section later in this document for more information.

 

Separate data collection from time critical control programs

In many cases a ControlLogix processor is running time critical code with little room to allocate for communications. If more communications bandwidth is needed and there is no tolerance for increasing task time consider consolidating data collection and I/O as much as possible into specific ControlLogix processors that are not controlling time critical tasks.

 

Don’t poll data too fast

Sometimes you can get better performance by not requesting data so fast. For example, if you are collecting data every 10ms in an HMI application and updates are too slow try backing off to collecting the data every 250-500ms or higher. HMI screens can’t update every 10ms anyway and you will reduce the burden on the ControlLogix processor and your data collection station.

Keep Tags on Scan

When a data collection application puts tags on and off scan RSLinx Classic must negotiate with the ControlLogix processor and build up ControlLogix Optimized Packets. This accounts for why it sometimes takes a while to get data when switching between HMI screens or when starting up an HMI project. In many applications, its better to put all tags on scan when the project starts. You’ll get the best optimization possible and little delay when switching between HMI screens. Keeping all tags on scan will use more memory in the ControlLogix processor but the communications performance will be steadier. Network traffic will be higher but in many cases that’s not the bottleneck. If your HMI is constantly putting tags on scan and taking them off, communications will be disrupted often and you will not get the best optimization between RSLinx Classic and the ControlLogix processor. You may have to experiment with you particular setup to see what works best for your particular application.

Use a Faster ControlLogix Processor

Data collection throughput can increase by 150% when using a ControlLogix 5563 over a 5555. Additionally, a 5563 will execute tasks around half the time over 5555 or 5550. This allows for even more communications bandwidth to be allocated. Data collection throughput increases by 30%-40% when using a ControlLogix 5555 over a ControlLogix 5550.

Ensure RSLinx Classic and ControlLogix versions are current enough

RSLinx Classic and ControlLogix based controllers are continually enhanced to offer improved data collection performance and features. Reference the chart below to ensure that you are taking advantage of the various improvements.

 

Improvement

Minimum RSLinx Classic Version

Minimum ControlLogix Firmware Version

 

 

 

First Level optimization

RSLinx 2.1*

4.41*

Array Optimization

RSLinx 2.20

4.41

UDT Optimization

RSLinx 2.20 SP1

4.41

String Support

RSLinx 2.30

8.x

Write Optimization

(Greatly enhances batch and recipe downloads)

RSLinx 2.30.02

10.x

Numerous enhancements and fixes

RSLinx 2.40 and +

---

 

*You should have at least RSLinx 2.1 and ControlLogix firmware version 4.41 when doing any data collection.

 

Configuring RSLinx Classic

Configuring RSLinx Classic to communicate to data collection applications involves creating a Topic. The RSLinx Classic setup is the same for DDE or OPC applications. For the best performance we recommend that any ControlLogix processor should not use more than one RSLinx Classic for data collection. You’re communications will be less efficient if you create topics on multiple RSLinx Classic stations to the same ControlLogix processor. If several data collection stations are going to be collecting data then use an RSLinx Classic Gateway. Only the RSLinx Classic Gateway station will need to have a topic configured. OPC applications know how to remotely connect to the RSLinx Classic Gateway and collect data using its topic. 

 

Here is the easiest way to create a topic. Note this assumes that a driver is already configured for the relevant network. We will use Ethernet in this example.

 

Step 1: In the RSWho window right mouse click on the ControlLogix processor that you want to configure a topic to. Select “Configure New DDE/OPC Topic”. The DDE/OPC Topic Configuration dialog will open.

 

 

To configure a topic right mouse click the ControlLogix in RSWho.

 

Step 2:  A topic with the name of the control program is created. The screen shot below is of the Data Collection tab of the dialog. It contains some additional parameters that are discussed below.

 

 

RSLinx Classic DDE/OPC Topic Configuration Dialog. Looking at the properties of a ControlLogix topic

Topic Parameters

Polled Messages

A topic to a ControlLogix processor has to be configured for either polled or unsolicited messages. Polled messaging should be used if you want RSLinx Classic to poll the ControlLogix processor for the requested data items. The polling interval specifies how often data items are read from the controller. This is the interval for which DDE clients will be updated. OPC clients will be updated at their requested intervals.

 

Unsolicited Messages

You have to configure a separate topic for unsolicited messages when you want the ControlLogix processor to send the data to RSLinx Classic via a message instruction. Unsolicited data sent to RSLinx Classic is passed onto any clients requesting the data items.

 

Communications Time-Out

This is the number of seconds RSLinx Classic will wait for the processor to acknowledge a request before RSLinx Classic returns a time-out error to the client. You can increase the Communications Time-Out for the topic if you are requesting a large amount of data, and receiving a lot of time-outs in the RSLinx Classic Communication event log. The timeout message for ControlLogix is “CIP Messaging Error: a message timed out waiting for a response.”

 

Use Symbols

This is where you associate the RSLogix 5000 .acd file to the topic for offline browsing.  This will allow you to configure your data collection applications offline since the list of available tags is associated with the topic. You need to have RSLogix5000 v10 or higher to use this feature.

 

Optimize Poke Packets – Enables/Disables write optimization. This option is enabled by default when a new topic is created in RSLinx 2.30.02 and later. Make sure that this option is enabled if you upgraded from a previous version of RSLinx Classic and if you are going to be sending batch/recipe downloads or any other data to the ControlLogix processor. This option is only available for ControlLogix processors with firmware version 10.x or above and RSLinx 2.30.02 or later.

RSLogix 5000 Automatically Configures Topics in RSLinx Classic

When saving an .acd project in RSLogix 5000 (version 10 and higher) it will automatically configure a topic in RSLinx Classic for you. It will also associate the .acd file with the RSLinx Classic topic. This enables OPC browse aware applications to obtain a list of the available ControlLogix processor tags when offline. This is useful when building an RSView project when you don’t have access to the ControlLogix processor that the project will communicate to.

 

Understanding ControlLogix Data Collection

 

Data collection with ControlLogix processors is very different from PLC-5 and SLC based controllers. Controller tags are structured as data tables in these legacy controllers so RSLinx Classic already has built in knowledge of the tag data types and how they are structured. The ControlLogix tag and data type flexibility frees its users from such restrictive data definitions and allows users to model their data meaningfully. This flexibility introduces some overhead since RSLinx Classic initially does not have any knowledge of what tags are available and their data types.

When a data collection application initially requests data from a ControlLogix, RSLinx Classic will upload a list of all the available tags and their data types. RSLinx Classic will keep this information in memory. Each time an OPC or DDE application requests data, RSLinx Classic will determine how to request the data optimally to the ControlLogix packing up to 486 bytes worth of data into each request. Each of these requests from RSLinx Classic to the ControlLogix is referred to a ControlLogix Optimized Packet. The size of this packet is limited by the size of a ControlNet packet, which is essentially the network that the back plane of the 1756 chassis uses.

Step-by-Step

Reading ControlLogix data:

  1. A data collection application puts tags on scan through RSLinx Classic’s OPC or DDE interfaces.
  2. RSLinx Classic uploads a list all of the available ControlLogix tags and their data types. RSLinx Classic stores this list in memory.
  3. RSLinx Classic builds ControlLogix optimized packets. Each optimized packet can hold up to 488 bytes worth of data.
  4. Once the packets are built, data can be delivered from RSLinx Classic to data collection applications via OPC or DDE. It can take several seconds to put several thousand tags on scan.

Note: RSLinx 2.30 SP1 and ControlLogix firmware 10.x and above employ a faster method of putting tags on scan and taking them off.

 

Tags taken off/put on scan: (Typically when switching HMI screens)

 

  1. When tags are taken off scan RSLinx Classic will remove those tags from their corresponding ControlLogix Optimized Packets. RSLinx Classic will re-optimize whatever tags are on scan after the removal and recreate as few packets as possible. All data from that ControlLogix will stop updating until re-optimization is complete. The ControlLogix cannot send a packet of data while the contents of the packet are changing.
  2. When new tags are put on scan RSLinx Classic will build new optimized packets. If the tags are already on scan then RSLinx Classic will simply get the data from the existing ControlLogix Optimized Packets. This is where using RSLinx Classic Gateway to serve data to multiple data collection stations is more efficient over having several independent RSLinx Classic stations. The ControlLogix processor needs to build and service one set on ControlLogix Optimized Packets for the RSLinx Classic Gateway. Multiple RSLinx Classic stations would require the ControlLogix processor to build and service a set of ControlLogix Optimized Packets to each RSLinx Classic station, even when each station is collecting the same data! 

 

Adding, removing, or modifying tags in the ControlLogix processor while collecting data:

Typically, data collection stations will be running while new programs are downloaded and/or online changes are made to ControlLogix processors. If you are using a version of RSLinx Classic earlier then 2.30 then any change to the ControlLogix processor’s tags will require that all data collection applications be stopped before the changes are made and then restarted once the ControlLogix processor has been updated. RSLinx Classic 2.30 has the capability of detecting these changes but you need to manually instruct RSLinx Classic to update the ControlLogix tag information.

Improvements have been made to RSLinx 2.30.02 so that data collection can continue largely uninterrupted when the tags inside of the ControlLogix processor change. RSLinx Classic now frequently checks the ControlLogix processor to see if any changes have been made to its tags and in many cases automatically updates the ControlLogix tag information. Here are some scenarios involving changing the ControlLogix tags while collecting data with RSLinx 2.30.02. 

 

  1. Tags are added to the ControlLogix processor when online with RSLogix 5000:

RSLinx Classic will detect that tags have been added to the ControlLogix processor, log an event into the RSLinx Classic communication event log, and then update the list of available tags to include the newly added tags. Data collection stations can start collecting data from the new tags without stopping the data collection project.

 

  1. Tags are added to the ControlLogix processor by downloading an updated program:

RSLinx Classic will detect a download, log an event in the communication event log, and refresh its list of available tags. Data collection will stop while a new program is being downloaded and will resume when after the download. Data collection stations can start collecting data from the new tags without stopping the data collection project.   

 

  1. Tags are removed from the ControlLogix processor when online with RSLogix 5000:

RSLinx Classic will detect that tags have been removed from the ControlLogix processor, log an event into the RSLinx Classic communication event log, and then update the list of available tags. All data collection projects should be stopped prior to making these changes. Restart data collection after the tags are removed from the ControlLogix processor. All items on scan while removing any tags from the ControlLogix processor will cause all tags to stop updating until data collection applications are restarted.

 

  1. Tags are removed from the ControlLogix processor by downloading an updated program:

RSLinx Classic will detect a download, log an event into the RSLinx Classic communication event log, and then update the list of available tags to no longer include the removed tags. All data collection projects should be stopped prior to making these changes. Restart data collection after the tags are removed from the ControlLogix processor. All items on scan will stop updating after downloading a new program into the ControlLogix processor that results in the removal of tags.

 

  1. When the tags in the ControlLogix processor have their data types changed or when alias tags are re-referenced:

All data collection projects should be stopped prior to making these changes. Restart them after the data types of the tags in the ControlLogix processor have changed. RSLinx Classic cannot update this information while data collection is in progress.

 

  1. When arrayed tags in the ControlLogix processor are re-dimensioned in any way:

All data collection projects should be stopped prior to making these changes. Restart them after the data types of the tags in the ControlLogix processor have changed. RSLinx Classic cannot update this information while data collection is in progress.

 

  1. Changes of any kind to User Defined Types (UDT’s) whether adding, deleting, or modifying it’s members in the ControlLogix processor:

All data collection projects should be stopped prior to making these changes. Restart them after the data types of the tags in the ControlLogix processor have changed. RSLinx Classic cannot update this information while data collection is in progress.

Read Optimization

Read optimization allows many tags to be read from the ControlLogix processor in fewer requests. This conserves valuable ControlLogix CPU and memory resources as well as minimizing network traffic. Requests from data collection applications to RSLinx Classic are optimized down to a fewer number of requests from RSLinx Classic to the ControlLogix. These fewer requests are each ControlLogix Optimized Packets. Without optimization each tag request from data collection applications would correspond to a request from RSLinx Classic to the ControlLogix.

There are a few different levels of optimization. Namely UDT, Array, and First Level or “Scattered”. RSLinx Classic determines the kind of optimization used when tags are put on scan. The next few sections discuss the different types of optimization.

 

Array optimization

This kind of optimization grabs several elements of an array and treats them as one item in the controller. The benefits of this kind of optimization are often reduced as HMI clients typically must request array elements individually and not a range of elements at one time. In other words to get the most out of this optimization reference elements of an array like this: INTArray[0],L10. Instead of INTArray[0], INTArray[1],…,INTArray[9]. If you are not able to use the L notation then array optimization will still occur between the ControlLogix and RSLinx Classic but there will be more resources used on the PC.

 

Requirements:

Scenario:

INTArray[100] is defined. The following tags are requested: INTArray[0], INTArray [20], and INTArray[90]. RSLinx Classic will create a packet requesting all elements between INTArray[0] and INTArray[90]. The ControlLogix will treat all of these array elements as one item and one ControlLogix Optimized Packet will be used for delivering these tags. If later on INTArray[60] is requested then RSLinx Classic will already have this on scan and no more overhead is needed to deliver the data.

 

Boolean Array Optimization

Starting with RSLinx 2.20 optimizations to Boolean arrays allow each individual Boolean item as a single bit object, as opposed to a 32-bit object, as it had done previously. Using this method, up to 3872 Booleans can fit into one ControlLogix Optimized Packet. Previously, the maximum was 81 Booleans. When dealing with individual Boolean tags, and not Boolean-array tags, the tags will still be treated 32-bit items, and only 81 items will fit into a ControlLogix Optimized Packet.

 

UDT optimization

A UDT or User Defined Type is a custom data type in the ControlLogix processor. Users create UDTs containing native data types like INTS, DINTS, FLOATS, other UDTs, and etc. When elements of a UDT are requested from data collection applications and the UDT Optimization option is enabled in RSLinx Classic, RSLinx Classic will grab the entire UDT structure as one item from the ControlLogix processor. This reduces the ControlLogix processor’s CPU and memory resources needed to serve up data. The more elements of the UDTs that are used by data collection applications the better the performance. If a minority of the UDT elements is on scan then it is inefficient for RSLinx Classic to serve up the entire UDT. In that scenario it would be wise to disable UDT optimization. UDT optimization can be enabled or disabled for all ControlLogix processors/Topics. This option cannot be set on a per topic basis. Here is how the option is set.

 

1. Open the CIP Options.

 

2. The Optimize User Defined Data Types option is located via the Connection for ControlLogix Processor tab in the CIP Options dialog.

 

 

RSLinx Classic Configure CIP Options dialog

UDT Optimization Requirements:

·         The above option must be enabled in RSLinx Classic.

·         The UDT must be 480 bytes or less.

.

Some scenarios regarding UDT optimization:

 

1. A UDT is larger than 480 bytes:

RSLinx Classic will not perform UDT optimization, just “Scattered” optimization.

 

2. A UDT contains arrays of SINTS, INTS, DINTS, or REALS:

RSLinx Classic will perform UDT optimization and grab the whole structure. If the UDT is greater than 480 bytes then array optimization will be performed on any arrays. “Scattered” optimization will be performed on the remaining elements.

 

3. An array of UDTs:

RSLinx Classic not will perform UDT optimization for each UDT element of the array.

 

4. A UDT contained in a UDT:

RSLinx Classic will perform UDT optimization on the outer UDT providing that is less than 480 bytes.

 

 

First Level or “Scattered” Optimization

This is the default optimization that occurs when UDT or array optimization does not apply. RSLinx Classic will pack up to 480 bytes worth of tags into a ControlLogix Optimized Packet. The tags are usually scattered throughout the memory of the ControlLogix Processor. This type of optimization uses more ControlLogix CPU and memory than with UDT or array optimization.

 

How much data can be read in a ControlLogix Optimized Packet?

This table outlines how many items of each native ControlLogix processor data type can fit into a ControlLogix Optimized Packet. This data is accurate with RSLinx 2.20 and higher.

 

Data Type

Max. Items that fit into a Read Packet

 

 

Boolean

81

Boolean Arrayed

3872

SINT

81

SINT Arrayed

81

INT

121

INT Arrayed

243

DINT

81

DINT Arrayed

121

REAL

81

REAL Arrayed

121

Write Optimization

Write optimization enhances performance for batch or recipe downloads to the ControlLogix processor. Often times the ControlLogix processor is so busy that write requests occasionally time-out and the batch/recipe downloads fail. With write optimization there will be fewer write requests generated from RSLinx Classic to the ControlLogix processor. Fewer write requests will reduce the work the ControlLogix processor has to do to accept the batch/recipe downloads and will reduce the occurrence of batch/recipe download failures.

Each write request from RSLinx Classic to the ControlLogix processor is referred to as an Optimized Network Write Packet. Before RSLinx 2.30.02 every single tag being written to had to be sent in its own Optimized Network Write Packet. With write optimization many tags being written to can be sent in fewer Optimized Network Write Packets. For write optimization First Level or “Scattered” optimization is used for tags within the ControlLogix processor that have little or no relation to each other. Write optimization groups them together into as few Optimized Network Write Packets as possible. Additionally, there is array optimization but no UDT optimization.

 

How to Use Write Optimization

The RSLinx Classic topic communicating to the ControlLogix processor needs to have the “Optimize Poke Packets Option” option enabled. See the Configuring RSLinx Classic section for details. Also, you should have ControlLogix firmware 10.x or higher.

 

Array optimization for writes

This is similar to array optimization for reads. Array elements can be optimized even better as to allow more data to fit into an Optimized Network Write Packet. To take advantage of array optimization, the array elements being written to must be contiguous and the write must be issued as once command. 

 

Boolean Arrays – note that when using write optimization for Boolean arrays the “L” specifier should not be used. Each array element should be individually referenced as a separate tag.

 

How many tags can be sent in a write packet to the ControlLogix? 

 

Data Type

Max. Items that fit into a Write Packet

 

 

Boolean

32

Boolean Arrayed

32

SINT

32

SINT Arrayed

460

INT

30

INT Arrayed

230

DINT

26

DINT Arrayed

115

REAL

26

REAL Arrayed

115

 

These numbers are accurate for ControlLogix firmware versions 10.x and beyond. Previous versions of the ControlLogix firmware would yield lower numbers since the write optimized packets had to contain the actual tags names. Therefore, we recommend using ControlLogix version 10.x or higher for the best performance. Versions prior to RSLinx 2.30.02 do not support write optimization.

 

RSLinx Classic “Smart” Polling

RSLinx Classic smart polling reduces CPU utilization on the RSLinx Classic system when collecting data. If data is being requested faster than the controller and the network can possibly send it (by using a very fast poll rate on a slower network, for example), RSLinx Classic will “back off” the excessive polling, and only poll the data from the processor at the rate it is actually being sent. This feature is implemented in RSLinx 2.20 and higher. There are no settings, this happens automatically.

How RSLinx Classic Uses ControlLogix Connections

RSLinx Classic uses connections, a dedicated communications pipe, when collecting data from a ControlLogix. When reading data from a ControlLogix processor each ControlLogix Optimized Packet makes use of a connection. It gets its connection from a pool of connections that is shared by all ControlLogix Optimized Packets. The maximum number of connections that are used in this pool is configurable but the default is four, which in many cases is the optimal setting.

RSLinx Classic’s use of connections when writing data to the ControlLogix processor is different then reads. When writing data to the ControlLogix processor it has the ability to use one connection or none at all for all writes. If writes to the ControlLogix processor are very frequent (within 32sec. by default) or continuous then you are better off using a connection for writes. If you are sending data less frequently then you should not use a connection for writes. For example, if you had a batch\recipe running every few minutes you would be better off not using a connection for writes.

 

How to access the dialog for configuring the maximum number of read connections used per ControlLogix and to enable/disable the use of connections for writes.

 

  1. From the RSLinx Classic main menu select Communications…Configure CIP Options.

 

 

  1. Select the Connections for ControlLogix Processor tab.
  2. The maximum number of read connections that RSLinx Classic will use for each ControlLogix is set here. Also the option for enabling/disabling connections for writes is on this dialog.

 

 

RSLinx Classic Configure CIP Options dialog

Memory Consumption in the ControlLogix Processor

The ControlLogix processor has to allocate a certain amount of memory in order to internally maintain the structures of the ControlLogix Optimized Packets. The amount of memory that the ControlLogix will consume is based on:

           

 

 

Here are some results of a test performed to determine the actual amount of memory consumed in the processor for different data requests. The Optimized Items & Optimized Packets counts were obtained via RSLinx Classic diagnostics, the memory consumed was determined using the “@freemem” DDE/OPC item.

 

Items being requested within arrays, or structures & UDT’s will also now consume less memory than before, if they can take advantage of those types of optimizations. This is because both array and UDT optimizations yield fewer overall “ControlLogix Optimized Packets.”

 

See section 2 for additional information on array optimizations and UDT optimizations.

 

 

Test setup

Array optimizations?

ControlLogix Optimized Items

ControlLogix Optimized Packets

Connections to processor used

Memory consumed in processor

1 native tag integer

No Array Optimizations

1

1

1

1364 bytes

Perfect  Array Optimizations

1

1

1

1364 bytes

 

100 native tag integers

No Array Optimizations

100

1

1

4532 bytes

Perfect Array Optimizations

1

1

1

1560 bytes

 

500 native tag integers

No Array Optimizations

500

5

5

22660 bytes

Perfect Array Optimizations

3

3

3

5084 bytes

 

1000 native tag integers

No Array Optimizations

1000

9

8*

42736 bytes

Perfect Array Optimizations

5

5

5

7556 bytes

 

* RSLinx Classic was configured to use up to 8 connections for this test.


Communication Event Log

The RSLinx Classic communication event log will populate with some events that may occur while performing data collection. Some of these may be communications errors while other may just indicate a potential problem. The contents of this log can be exported to a text file.

 

1. How to access the communication event log from RSLinx Classic’s main menu.

 

 

Opening up the Communication Event Log from RSLinx Classic’s main menu

 

2. The events in the communication event log can be saved to a text file.

 

 

RSLinx Classic’s Communication Event Log

 

 

Getting RSLinx Classic Data into Applications

 

Logix5000 Tag Import Utility - Import ControlLogix Tags Into RSView and RSSQL

Use the Logix5000 Tag Import utility to import ControlLogix tags from an L5K file into RSView or RSSQL. The utility generates a csv file that RSView ME and RSView SE can import from. It also generates a TSV file for RSSQL. RSView32 can import the tags directly from the utility.

Download this utility and application note from Rockwell Software’s online knowledgebase: A839 Logix 5000 Tag Import Utility for RSView32, RSView ME / SE and RSSQL (RSView32)

 

Browsing and Selecting ControlLogix Tags

Another way of getting tags into applications is by browsing the available ControlLogix tags and picking the tags of interest. The mechanism that allows this kind of support RSView and RSSQL are examples of applications that support this OPCBrowse interface. Note that you can browse the list of available tag online or offline.

 

Online - RSLinx Classic directly queries the controller for a list of available tags.

OfflineRSLinx Classic queries an RSLogix 5000 .acd file. A topic must be configured to Use Symbols with the .acd file associated with it. RSLogix 5000 will automatically create this for you when you save a project. This feature requires RSLinx 2.30 SP1 and RSLogix version 10 and higher.

 

Here is an example of browsing ControlLogix tags in RSView.

 

  1. Create a new Node in RSView with these following settings:

Data Source should be “OPC Server”

The server name should be “RSLinx OPC Server”

The “In-Process” server type should be selected.

Do not specify an Access Path.

 

 

 

 

2)       In the RSView Tag Database, create a tag with the following settings:

a.       Specify either an “Analog” or “Digital” tag type, as appropriate.

b.       Select the data source of the tag to be of type “Device”.

c.       For the Node Name, use the Node Name as created in step 1.

d.       At this point, a box with three dots will appear next to the “Address” field. (This is circled on the image below.) Click on this box.

 

 

 

3)       The OPC Address Browser window should now appear in RSView. From here, you can select your RSLinx Classic topic to your ControlLogix processor, and browse through the address hierarchy to associate your tag with an address.

 

 

Browsing ControlLogix tags in RSView

 

Miscellaneous RSLinx Classic Features and Tips

Backup/Restore RSLinx Classic Configurations To/From a File

This utility can be accessed from the start menu. See the screenshot below for details. All RSLinx Classic settings including drivers and topics are backuped to/ restored from a file. This utility is also accessible from the command line via Backupcmd.exe which is located where ever RSLinx.exe is installed.

 

Accessing the RSLinx Classic Backup-Restore utility from the Windows Start Menu.

ControlLogix Data Monitor

In RSLinx 2.20 or higher, there is Data Monitor support for ControlLogix processors. Now, with a right-mouse click on a ControlLogix processor in RSWho, you can choose the “Data Monitor” option to monitor your tags. The data monitor is only available with RSLinx Classic Professional and RSLinx Classic Gateway.

 

 

RSWho pop-up menu for the ControlLogix processor

 

 

 

 

ControlLogix Data Monitor

 

Tip: Right-mouse click a tag and select Copy To Clipboard. This will populate the copy to clipboard dialog with the tag that you selected. This allows you to paste a hotlink into Microsoft Excel or the tag name into another application. RSLinx Classic will use an existing topic but if none is configured then RSLinx Classic will step you through the configuring one.

 

RSLinx Classic’s Copy DDE/OPC link supports browsing ControlLogix Tags

 

 

Select Copy DDE/OPC Link from the RSLinx Classic main menu

 

 

After making your tag selection, you will be able paste a DDE hotlink into Microsoft Excel or just paste the tag name into another application. (Like VB for example) 

 

 

Copy DDE/OPC Link dialog.

 

Getting Module Information in RSLinx Classic

 

The easiest way of checking which firmware revision in the ControlLogix processor is to perform the following steps:

 

(This will work in RSLinx Classic 2.20 and higher)

 

1. Use the mouse to right-click a ControlLogix processor in RSWho, to bring up the following pop-up menu.

 

 

 

2. Choose the menu item “Device Properties,” to display a dialog with information on the device.

 

 

This dialog will display the firmware version in the ControlLogix, in the field labeled “Revision.” Here, we see the firmware version is 8.20. Note that this feature is supported by most devices – not just ControlLogix processors.

Application Notes

Many tech notes are available online from Rockwell Software’s knowledgebase. Many of the topics in this section reference those tech notes by document number and title and are also hyperlinked. Here is the general link to the knowledgebase. http://support.rockwellautomation.com/

 

Put Tags on Scan at the Same Time

See tech notes from Rockwell Software’s online knowledgebase

A2062 ControlLogix communication packet optimization techniques and observations (RSView32)

Changing ControlLogix Tags While On Scan

You may need to make a process for changing tags in the ControlLogix processor while performing data collection. The actions that you must take depend on the changes that are made. RSLinx Classic uploads all of the ControlLogix tags and their data types when the first tag gets put on scan. RSLinx Classic uses this information to build the ControlLogix Optimized Packets. If the tags in the ControlLogix change then RSLinx Classic will have to upload the new tag information. Here are the actions necessary when making changes to tags in a ControlLogix processor.

 

Changing data types, array resizing, UDT definition changes or if tags are deleted from the ControlLogix processor. This applies even if the tags are not on scan by data collection applications.

  1. Disconnect data collection applications from RSLinx Classic. If connecting remotely via RSLinx Classic Gateway then disconnect all data collection stations. RSLinx Classic does not have to be shutdown and restarted. Computers do not have to be rebooted. RSView for example has a node disable command that could be assigned to a button or run as part of a script.
  2. Restart the data collection applications after changes are made to the ControlLogix processor.

 

If tags are added to the ControlLogix controller – No data type changes or tag deletions:

Option 1 (RSLinx 2.30 or higher required)

  1. Add tags offline in RSLogix 5000
  2. Download the program into the ControlLogix
  3. RSLinx Classic will log an event to its Communication Event Log and upload the new tag information automatically. Data collection stations will resume data collection after download is complete.

 

Option 2 (RSLinx 2.30 or higher required)

  1. Add tags to the ControlLogix Processor online while collecting data.
  2. Command RSLinx Classic to re-upload ControlLogix tags. This is done in one of three ways:
    1. RSLinx Classic will automatically detect changes and the re-upload the ControlLogix tag information. RSLinx Classic queries the ControlLogix Processor for these changes every 20-30 seconds. An event will be logged to the RSLinx Classic Communication Event Log when changes are detected and uploaded. (RSLinx 2.31 and later)
    2. Perform a read on the predefined item @CLTagUpdateAddressSpace
    3. Select the option from RSLinx Classic’s main menu under DDE/OPC

 

 

 

Redundant RSLinx Classic Gateway Servers with RSView’s NodeSwitch Command

See tech notes from Rockwell Software’s online knowledgebase.

R679 RSView32 6.30.16 Patch for switching between OPC nodes (RSView32)

Redundancy for ControlLogix processors

There are a few options of incorporating redundancy at the ControlLogix level into your data collection system.

Option 1: Use hardware redundancy. This option will only work if your data collection is over ControlNet requires

Option 2: Use Alias Topics is RSLinx Classic

Option 3: Use RSView’s node switch command.

 

See tech note from Rockwell Software’s online knowledgebase

A952 Node Level Redundancy - A comparison of the Alias Topic and the NodeSwitch Command (RSView32)

Using ControlLogix Strings

You must be at least RSLinx 2.30 and ControlLogix firmware 8.x to use strings.

 

RSLinx 2.31 and later

The addressing syntax for a ControlLogix string data type is just the tag name of the string. So if I had a string named “MyString” You would address it as “MyString” in your data collection application regardless of how many characters you want to read. RSLinx Classic will automatically update the length of the string in the ControlLogix processor when writing a new value to the string.  

 

Prior to RSLinx 2.31

The addressing syntax for a ControlLogix a string data type is StringTag.DATA,SC# (where # is the number of characters). For example, if you had a string tag in the ControlLogix processor named “MyString” you would use MyString.DATA,SC10 to read the first ten characters of MyString..

Troubleshooting

Click here to get the troubleshooting guide from our support website. For reference here is the link.

http://www.software.rockwell.com/download/comms/rslinx/controllogix data collection troubleshooting guide.doc

Performance

Throughput vs. System Overhead Time Slice with a Continuous Task

 

Test setup:

 

The test was run for three different organizations of tags. The tags were either scattered, UDT optimized, or in Arrays. Here is an explanation of each.

 

Scattered means either one of three things.

1.       Each tag was individually defined in the ControlLogix processor.

2.       Tags were defined as elements in User Defined Types with the “Optimize User Defined Data Types” disabled in RSLinx Classic.

3.       Tags were defined as elements in User Defined Types that were too large to be optimized. (UDT>480 bytes)

 

Array – All data was defined in one big array. The OPC test client put all 5000 tags on scan at the same time to yield the best array optimization.

 

UDT – 120 elements of type DINT were defined in UDTs. (480 byte UDT) “Optimize User Defined Data Types” is enabled in RSLinx Classic.

 

Tags per Second = (5000 Tags/Number of ControlLogix Optimized Packets from RSLinx Classic Server Diagnostics) * Packets per second from RSLinx Classic driver diagnostics.


 

 

Time Slice

Scattered

Tags Per Second

UDTs

Tags per Second

 

Arrays

Tags Per Second

10%

1270

10400

10400

20%

2680

21600

21700

30%

4070

32500

32700

40%

5340

42400

42700

50%

6620

45000

45300

60%

7940

45000

45300

70%

9190

45000

45300

80%

10360

45000

45300

90%

11530

45000

45300

 

 

Results:

Throughput in tags per second is dependent on how the tags are organized and the Time Slice. The array and UDT optimizations in these tests show a best case scenario. Scattered tag organization represents the worst case scenario. Since typical applications have a mix of different arrays, UDTs, etc. their performance will be somewhere in-between the worst case and best case scenarios.  

 

Throughput vs. Periodic Rate with a Periodic Task

 

Test Setup:

 

The test was run for two different organizations of tags. The tags were either scattered or in Arrays. UDTs are not published here as results were similar to arrays.

 

Tags per Second = (5000 Items/Number of ControlLogix Optimized Packets from RSLinx Classic Server Diagnostics) * Packets per second from RSLinx Classic driver diagnostics.

 

The periodic task for this test takes 63 ms to execute. To increase performance we have to increase the Periodic Rate.

 

 

Periodic Task Rate

(ms)

Items Per Second no arrays or UDTs

Items Per Second Arrays

64

260

1450

70

1300

7400

100

4840

18450

200

8890

30300

300

10250

35700

400

10950

37700

500

11350

39600

 

Test Results:

Throughput in tags per second is dependent on how the tags are organized and the Periodic Rate. The array and UDT optimizations in these tests show a best case scenario. Scattered tag organization represents the worst case scenario. Since typical applications have a mix of different arrays, UDTs, etc. their performance will be somewhere in-between the worst case and best case scenarios.  

Throughput vs. System Overhead Time Slice and Periodic Rate with a Continuous and a Periodic Task

 

This test uses both a continuous task and a Periodic task. The periodic takes 63ms to execute.

 

Time Slice

Periodic Rate of the Periodic Task

Maximum Continuous Task Execution Time (ms)

Scattered Tags Per Second

10%

70

696

140

50%

70

1,190

610

90%

70

6,376

1150

10%

100

196

480

50%

100

388

1990

90%

100

1,801

4230

10%

200

134

860

50%

200

187

2340

90%

200

795

6600

10%

400

134

1070

50%

400

192

1960

90%

400

914

7660

 

Results:

With a combination of periodic and continuous tasks communication bandwidth is further reduced. Allocating communication bandwidth involves finding a balance between Periodic Rate and Time Slice. Just increasing the Time Slice without increasing the periodic rate can increase the Continuous task execution time significantly while not really freeing up much communication resources.

Processor Type vs. Performance

Test setup:

 

 

Time Slice

Tags per second (DINT) 5550

Tags per second (DINT) 5555

Tags per second (DINT) 5563

 

 

 

10%

970

1270

4670

20%

1970

2675

9540

30%

2980

4070

14230

40%

3920

5340

19300

50%

4840

6620

20500

60%

5850

7940

21050

70%

6700

9190

21050

80%

7570

10360

21050

90%

8410

11532

21050