clxperf

RSLinx: ControlLogix Data AccessVia OPC

Updated for RSLinx version 2.2 Service Pack 1

Rockwell Software

Document Version 2.12 7/18/2000


1) Optimizations – an overview...........................................................................................4

2) ControlLogix Optimized Packets....................................................................................5

ControlLogix Array Optimization...................................................................................5

Boolean Array Optimization............................................................................................5

3) Firmware Requirements for ControlLogix Optimization..............................................10

4) Checking your ControlLogix firmware version in RSLinx...........................................12

5) ControlLogix Optimized Packet creation......................................................................13

6) How RSLinx performs reads on a ControlLogix processor..........................................14

7) RSLinx Configuration Settings.....................................................................................16

Limit Maximum Packets................................................................................................16

Communications Time-Out...........................................................................................16

CIP Options for ControlLogix.......................................................................................17

8) System Overhead Time Slice........................................................................................19

Using non-array-optimized items:.................................................................................20

Using array-optimized items:........................................................................................20

System TimeSlice effects on Program Scan Time........................................................22

9) RSLinx “Smart” Polling................................................................................................24

10) Setting up RSLinx to use PLC-5 mapped tags............................................................24

11) Memory Consumption in the ControlLogix................................................................25

12) ControlLogix Data Monitor.........................................................................................27

13) OPC Browsing.............................................................................................................28

OPC Browsing Using the OPC Test client....................................................................28

OPC Browsing Using RSView......................................................................................29

14) PLC-5 Mapped Tag performance................................................................................32

15) The underlying network’s effect on performance.......................................................33

Comparison of Tags Per Second Throughput performance on different networks.......33

16) Effects of Connections on a ControlLogix processor.................................................34

1000 Integers.................................................................................................................35

5000 Integers.................................................................................................................35

17) RSLinx 2.1 vs. RSLinx 2.1 Service Pack vs. RSLinx 2.2..........................................36

RSLinx 2.1 method – no optimized packets..................................................................36


RSLinx 2.1 Service Pack method – optimized packets.................................................36

RSLinx 2.2 method – optimized packets (w/array optimizations)................................36

Side-by-side comparison of all three versions:..............................................................37

Tags per second throughput:......................................................................................37

ControlLogix Optimized Packets Needed: (Fewer is better).....................................37

It is easy to see from these tables, major improvements have been made in the area of

ControlLogix optimization in the last couple of releases of RSLinx. The throughput has

increased, while the required processor overhead has decreased. 18) Frequently Asked

Questions...........................................................................................................................37

18) Frequently Asked Questions.......................................................................................38

Is it possible to use up too much of the Logix5550’s memory?....................................38

How much memory will be used in the processor if I have multiple clients getting data

from a single Logix5550?..............................................................................................38

Why can’t I access my new tags using DDE/OPC? I can even see them in RSLogix.. 38

Is it possible for RSLinx to use up too many connections to the Logix5550?..............38

What happens when communications are disrupted between RSLinx and the

Logix5550?....................................................................................................................39

What happens with optimization when your MMI screen changes?.............................39

What happens with the optimized packets when multiple topics communicate to a

Logix5550 processor?....................................................................................................39

What other performance enhancements are planned for improved communications to

the Logix5550?..............................................................................................................39

Why can I only get 81 Boolean tags in a single optimized packet?..............................39

To what extent are ControlLogix structured data types and UDT’s optimized?...........40

Does the array optimization apply to an array of UDT's?.............................................40

I have an array of data that is updated with the same value from my control program.

Why am I getting different values when I read the arrayed data?.................................40


1) Optimizations – an overview. One of the major benefits of using RSLinx as your industrial automation communications package is the fact that it is capable of optimizing data requests. Optimized data results in both reduced network traffic, and increased communication speeds to your processors. RSLinx has long been able to optimize data for PLC-5, SLC-500, and MicroLogix processors. Beginning with RSLinx 2.1 Service Pack, RSLinx supports data optimization to the ControlLogix processor as well.

The general notion of “optimization” here essentially means sending as many data items as possible across the network in one network packet. For example, if you were reading 5 tags from a processor, it would be much more efficient if you were able to receive updates for all 5 tags at once, instead of one at a time.

In order to begin to understand the way in which ControlLogix optimizations work, it is worthwhile to first discuss the way in which PLC-5 and SLC-500 data is optimized in RSLinx. In order for optimization to occur here, the items that you are requesting need to be either contiguous, or near contiguous, in one data file. RSLinx will determine if multiple items can be requested as one single larger block request, as opposed to a single request for each item For example, if items N7:0, N7:1, and N7:4 are all requested, instead of making three requests (one for each item), RSLinx will make one request for a block of data that will include N7:0 through N7:4. RSLinx will then be able to parse out the items that it needs from this. This saves RSLinx from having to make several requests that have to be sent onto the network, which results in significant performance improvements.

The extent to which RSLinx can optimize items within a data file is directly related to the maximum packet sizes that can be sent on a network. For Ethernet, this is 1000 integers (500 floats), and for DH+ and ControlNet, this is 100 integers (50 floats). If you had a client communicating to a PLC via Ethernet, and the client was making 1000 individual requests for integers, all of which happened to all be contiguous in one data file, you could get updates for all 1000 items in one single network packet. This would result in a tremendous performance increase, but it would require a lot of work setting up both the PLC program and the client applications to work with the data just right, so that it could be optimized in this way.

Due to the very nature of the native tags in the ControlLogix, this technique of optimization does not generally apply. RSLinx does not know if two tags being requested with user-defined names are “contiguous” or not within the ControlLogix. Up until the RSLinx 2.1 Service Pack, every native tag item on scan in the ControlLogix had to be read in its own individual packet for this reason. Starting with RSLinx 2.1 Service Pack, there has existed a mechanism for communicating to the ControlLogix to obtain native tags more efficiently, the ControlLogix Optimized Packet. (Note that accessing tags that are in PLC-5 mapped mode in the ControlLogix would still take advantage of the PLC/SLC style of optimization.)


2) ControlLogix Optimized Packets The ControlLogix Optimized Packet is essentially a data structure utilized by both RSLinx and the ControlLogix. RSLinx creates these structures when native tags from the ControlLogix processor are requested. RSLinx will attempt to fit as many optimized items as possible into one ControlLogix Optimized Packet. With this mechanism in place, more than one item at a time can be sent in each communication packet, which increases the possible throughput of data transfers. Previously, RSLinx could only send one data item per communications packet.

Another newer performance enhancement is that RSLinx now communicates to the ControlLogix using CIP connections, whereas previously, all communications were done via unconnected messaging. The primary tradeoff of all of the performance enhancements is that some of the memory in the ControlLogix processor itself will now be allocated towards the optimized communications.

Timeline of ControlLogix Optimization Improvements

RSLinx 2.1 RSLinx 2.1 SP RSLinx 2.2 RSLinx 2.2 SP|------------|--------------------------------|-----------------------|-----------------------------|-------- No optimization Optimized Packets Array UDT Optimizations

Implemented Optimizations Implemented Implemented

ControlLogix Array Optimization

A new enhancement for RSLinx 2.2 is the ability for RSLinx to optimize array requests to the ControlLogix. It consumes a lot less overhead (in both RSLinx and in the ControlLogix) if several contiguous items from an array are being requested at once. For example, let’s suppose we have an array tag in the ControlLogix called myArray, of type INT[1000]. If we are requesting items myArray[0] through myArray[9], all separately, we would in essence be requesting 10 different items. In RSLinx 2.1 Service Pack, those 10 individual items would be treated as just that – 10 individual items. In RSLinx 2.2, those 10 items would be treated as one optimized item. This optimized item will end up being a larger request to the ControlLogix for the entire piece of memory that contains the data for all of myArray[0] through myArray[9]. Obtaining data in this method is significantly faster and more efficient.

Boolean Array Optimization

RSLinx 2.2 took the optimizations of Boolean arrays one step further. Now, when performing optimizations on Boolean arrays, RSLinx is able to treat 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 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

RSLinx 2.2 Service Pack 1 provides support for User Defined Template (UDT) and native structure data type optimizations. Previously, if you were requesting several different sub-elements of a structure, such as from a timer or a UDT, RSLinx would treat each of those requests as individual item requests. Now, the option exists to read the entire structure or UDT in one big chunk. The benefit of this method is that it is a faster and more efficient way of acquiring data. The UDT optimizations will work if the size of the UDT to be optimized is less than 480 bytes. If it is larger than this, RSLinx cannot presently read the entire structure all at once, so it will default back to treating each sub-element as a separate item. Support for reading larger UDT’s in large chunks will be supported in a future release of RSLinx. If you have a UDT that contains an array or another UDT, RSLinx will try to read the outer UDT. If it was <480 bytes then it would read it as optimized UDT. Otherwise, array optimization would be performed or no optimization would be performed.RSLinx 2.2 Service Pack will, by default, attempt to perform UDT optimizations on items. This option can be disabled, in the Connections for ControlLogix Processor dialog (see section 7). You may wish to disable this feature if you are only requesting one (or very few) sub-elements from your structures or UDT’s. This is because even if you are only requesting one sub-element, RSLinx will still read the entire structure or UDT, which can waste space in the optimized packets that are created.

Viewing the Optimized Packets information in RSLinx

Using the diagnostics in RSLinx, it is possible to determine the extent to which your data is being optimized.

As an example, the following individual tags were loaded via the OPC Test Client:

- 1000 Integers: int_change_1[0] through int_change_1[999]- 1000 Reals: real_change_1[0] through real_change_1[999]

In RSLogix5000, int_change_1 is declared as type INT[1000], and real_change_1 is declared as type REAL[1000].

After loading these items in the OPC Test Client, we can observe the ControlLogix Optimized Packets directly in RSLinx by viewing the “DDE/OPC Optimized Packets” screen.


ControlLogix Optimized Packets Each row in this particular view shows a ControlLogix Optimized Packet. There are 14 rows here, so we can conclude that our 1000 integers and 1000 reals have been placed into a total of 14 ControlLogix Optimized Packets.

The “Start Item” and “End Item” will display the first item and the last item that RSLinx has added to that particular ControlLogix Optimized Packet.

The reason why the “Item Counts” are all 1 is due to the array optimizations occurring. Look at the last entry in the list, for example. Its “Start Item” is Int_Change_1[0], and its “End Item” is Int_Change_1[242]. This means that RSLinx is receiving data for all 243 integers within that range using that Optimized Packet. It is essentially doing this through a single request for one very large “item” that contains all of the data values within that range, because this is a much faster way of acquiring data. Hence, RSLinx displays a 1 for the Item Count.

RSLinx can combine many different individual items into a ControlLogix Optimized Packet. Note that it is not possible to view each and every item contained in any ControlLogix Optimized Packet at this time (this will be added in a future revision of RSLinx). To demonstrate, 5 different items, named A, B, C, D, and E, have been loaded and placed on scan in that particular order. Below is the Optimized Packet display showing the result:


The “Start Item” here is “A”, because it was the first item placed into that particular packet, “E” is the “End Item” because it was the last item placed into that packet. We have 5 items in the packet, as seen by the item count, but we cannot actually see that “B”, “C”, and “D” are the other items in this particular packet. Because there are no array optimizations occurring in this example, we actually get an “Item Count” of 5 with these 5 items.

When items are placed on scan, and taken off scan, RSLinx will add and remove items as appropriate from the ControlLogix Optimized Packets. The actual items contained in any given packet can change frequently under these conditions.

Back to the original example with 1000 ints and 1000 REALs, we can observe the DDE/OPC Server Diagnostics while these particular Optimized Packets are active (below). Note the entry for “ControlLogix Optimized Packets” (second entry from the bottom), whose value is 14. This matches the count of Optimized Packets we have from the “DDE/OPC Optimized Packets” display. Also notice the entry for “ControlLogix Connections” (the last entry). This will tell you how many CIP connections RSLinx is currently using for communications to a ControlLogix processor. The OPC Item count is 2000, because the client is requesting 2000 individual tags from RSLinx. (Even though RSLinx will optimize these requests, they are still 2000 individual tags as far as the clients know.)

DDE/OPC Server Diagnostics for our example setup(Note- You will need to scroll down to view the ControlLogix information on this diagnostics screen.)


An example of viewing RSLinx diagnostics for UDT-optimized items:

You can see that 5 sub-elements from a Timer are on scan (Timer_1.CTL, PRE, ACC, EN, TT, and DN). Observe the entry in the “DDE/OPC Optimized Packets” display. The “Start Item” and “End Item” are the same, “Timer_1”. The “Item Count” is 1. This is because the entire Timer structure is being requested as one big item, instead of each sub-element at a time.


3) Firmware Requirements for ControlLogix Optimization RSLinx, upon initializing communications to a ControlLogix processor, will check the firmware version of the processor, to ensure that it supports the optimization functionality. If it is version 4.41 or greater, RSLinx will use the new ControlLogix Optimized Packet method to acquire data. If it is older than version 4.41, RSLinx will default back to the original (non-optimized) method. If you attempt to initialize communications when either the processor times out (if it is disconnected from the network, for example), or you have just powered up the ControlLogix chassis, and it is still within its approximately 5 second startup, RSLinx will default to the old communications method. When this happens, an entry will be made in the “DDE/OPC Communication Event Log” stating that this has occurred.

Time-out event states that the firmware revision could not be determined.

In order to get RSLinx to re-attempt to communicate with the new optimized methods, you will need to shut down all client applications that are using the RSLinx topic under question, so that it will no longer be in use. When the topic gets re-initialized, the firmware check will once again be performed.


Communications event log states that the firmware version in the ControlLogix is incompatible with the optimization techniques.


4) Checking your ControlLogix firmware version in RSLinx The easiest way of checking which firmware revision in the ControlLogix processor is to perform the following steps:

(This will work in RSLinx 2.2 and greater)

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 4.41, so this ControlLogix will support optimizations.


5) ControlLogix Optimized Packet creation In the ControlLogix Optimized Packet, each individual item is allocated a certain amount of space. The maximum size of a packet is 488 bytes. This is a ControlNet system limitation; though this packet size currently applies to all networks.

RSLinx will determine a way to structure as much data as it can into a ControlLogix Optimized Packet, and will then send the information about this structure’s composition to the ControlLogix processor. What the ControlLogix will now be able to do is send one large packet of data to RSLinx containing the data for each individual item in the ControlLogix Optimized Packet. RSLinx will then be able to extract the data values for each of these items, knowing the structure of the packet sent.

It is worth noting that in a ControlLogix Optimized Packet, data types can be mixed and matched. It should also be noted that RSLinx solely deals with the creation and the management of these ControlLogix Optimized Packets.

One of the major benefits of this technique is that your data now does not have to be contiguous, or organized in any special way, in order to take advantage of optimization.

As examples, all of these following combinations can be made into a single ControlLogix optimized packet, following the above format:

- 122 individual integers (RSLinx 2.1 Service Pack and greater)- 243 individual integers, that are contiguous in an array (RSLinx 2.2)

- 81 individual REALs or DINTs (RSLinx 2.1 Service Pack and greater)- 121 individual REALs or DINTs, that are contiguous in an array (RSLinx 2.2)

- 81 individual native BOOLs (RSLinx 2.1 Service Pack and greater)- 3872 individual native BOOLs, that are contiguous in an array (RSLinx 2.2)

Recall that The ControlLogix, as well as RSLinx, has to keep track of these ControlLogix Optimized Packet structures. This will consume some additional memory in the ControlLogix itself, the quantity of which is explained later on.


6) How RSLinx performs reads on a ControlLogix processor When you open a client to read tags from a ControlLogix processor, RSLinx will take the following steps:

1) RSLinx will upload the database of native tags from the ControlLogix processor. This allows RSLinx to:

- More quickly determine if an item being requested is invalid,- Determine the actual sizes of the data items, which is necessary when requesting

items,- Retrieve information about arrays, so that it can perform array optimizations.

Note that RSLinx will not load information about UDT’s when it performs this particular tag upload. Any information about UDT’s is loaded as needed, on demand.

This tag upload occurs when a client first communicates to a ControlLogix using a particular network path*. RSLinx will continue to use this tag information for subsequent communications to this processor, even if your application is connecting and disconnecting from the processor. If, however, RSLinx detects that the something in the ControlLogix processor has changed as it attempts to re-connect, it will be forced to once again re-upload the tag database, in order to make sure it’s dealing with the most up-to-date controller tag database.

2) RSLinx will determine an optimal way to place the data being requested into ControlLogix Optimized Packets, and will then build the packet structures. RSLinx will then send the information about these packets’ structures to the ControlLogix processor.

3) RSLinx will perform reads, using the available connections configured:

- If you have more connections configured than the number of optimized packets, RSLinx will use one connection per optimized packet to acquire data from the processor. RSLinx will not use more connections than this.

- If the number of optimized packets is the same as the number of connections configured, RSLinx will use that number of connections to acquire data from the processor.

- If the number of optimized packets is greater than the number of connections configured, RSLinx will use a round-robin type mechanism to acquire data from the processor. An optimized packet will be able to perform a read only when it has its turn to use a connection.

* A “path,” as mentioned above, refers to one or more topics, all of which are pointing to the same ControlLogix processor via the exact same network route. RSLinx performs all communications to a ControlLogix processor based on paths, not individual topics.


If you create a new tag in the ControlLogix processor after the initial tag upload has already occurred, and the path is still active, RSLinx will not immediately recognize the new tag. It will treat it as an invalid item until one of the two things occurs:

- All clients that are using that particular path disconnect from RSLinx- All items are taken off scan from that particular path. (The topics can remain in

use in this case, which means that the clients will not have to disconnect.)


7) RSLinx Configuration Settings

Limit Maximum Packets

The Limit Maximum Packets option allows you to specify how many outstanding (concurrent) packets are allowed on the network at one time. For example, if your Limit Max Packets was set at 20 (the default), then RSLinx will only attempt to send 20 concurrent read requests to the ControlLogix processor at once. RSLinx will not try to send any more read requests until the ControlLogix has answered at least one of those previous 20 requests. This setting can be tweaked to help to reduce both network traffic, and the load on the ControlLogix processor. Setting this number too low, however, can be very inefficient. This setting is on the DDE/OPC Topic Configuration.

The “Limit Maximum Packets” setting.

Communications Time-Out

You can also increase the Communications Time-Out for the topic (shown below) if you are requesting a large amount of data, and receiving a lot of time-outs. This setting is on the DDE/OPC Topic Configuration.

This is the number of seconds RSLinx will wait for the processor to acknowledge a request before RSLinx returns a time-out error to the client.


“Communications Time-Out” setting

CIP Options for ControlLogix

RSLinx communicates to the ControlLogix via DDE/OPC using CIP connections. This setting is accessed via the menu item “Communications” “Configure CIP Options”.

The three settings on this dialog are:

Maximum Messaging Connections per PLC

This specifies the maximum number of CIP connections you wish RSLinx to use when communicating with a ControlLogix processor. The default setting is 4. Based on system testing, it has been determined that this is an optimum number. Some applications may perform better by changing this number.

The effects of tweaking the number of connections used on a ControlLogix processor can have dramatic results on your data throughput; this will be discussed in the “Performance” section of the document.

Messaging Connection Parameters

This parameter specifies the timeout and retry intervals used on a CIP message. The timeout can be interpreted as the amount of time a connection will remain active without any communications occurring on it. When a timeout occurs, the ControlLogix optimized packet on that connection is destroyed. In order to read that data again, RSLinx and the ControlLogix processor will have to re-create the packet.


Use Connections for Writes to ControlLogix processor

RSLinx can now also perform writes to a ControlLogix processor using connections. RSLinx will use one additional connection (beyond what it is using to do reads) to perform writes to a ControlLogix processor when this option is checked. It is recommended to use this option when:

- You are performing a lot of writes, or

- You are performing a lot of reads, and you want to ensure that writes get through without timing out.

It is the default setting in RSLinx to use a connection for performing ControlLogix writes.

Optimize User Defined Templates

When this option is checked, RSLinx will perform optimizations, if possible, when reading elements from UDT’s, or to native structures, such as timers. It is the default setting in RSLinx to optimize UDT’s. Additional information on UDT optimization can be found in section 2 of this document.

“Configure CIP Options” dialog


8) System Overhead Time Slice

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

The System Overhead Time Slice is actually set using the RSLogix5000 software, not RSLinx.

The System Overhead Time Slice refers to how often the ControlLogix is able to perform communications tasks. Communication is considered to be low-priority for the ControlLogix controller, with higher priorities being placed on motion applications, periodic tasks, and program scans. A 10% time slice (the default) means that for every 10msec of program scan, 1 msec will be allocated to processing system overhead tasks such as communications. For applications that are communication-intensive, you will have to increase this time slice in order to obtain faster, more responsive data updates. Note that the tradeoff here is allocating less time to program scans.


Here are the results of a test run to demonstrate how the System Time Slice will impact data throughput. Both tests shown are using approximately 5000 integers on scan.

Using non-array-optimized items:

Effects of the System Time Slice setting on item throughput- NO ARRAY OPTIMIZATIONS4880 individual native tag integers on scan (optimized into 40 packets of exactly 122 integers each)Network: EthernetUsing 8 connections

TimeSlice Packets Per Second Items Per Packet Item per second throughput10% 12 122 146420% 22 122 268430% 31 122 378240% 39 122 475850% 47 122 573460% 56 122 683270% 64 122 7808

100% (program mode) 88 122 10736

Using array-optimized items:

Effects of the System Time Slice setting on item throughput- WITH ARRAY OPTIMIZATIONS4860 individual native tag integers on scan (optimized into 20 packets of exactly 243 integers each)Network: EthernetUsing 8 connections

TimeSlice Packets Per Second Items Per Packet Item per second throughput10% 69 243 1676720% 105 243 2551530% 106 243 2575840% 107 243 2600150% 107 243 2600160% 107 243 2600170% 107 243 26001

100% (program mode) 130 243 31590


Here are the results of the test in a graphical format:

Using array optimizations in RSLinx 2.2, a point can be reached where the processor is sending the data as fast as it is able to. This can be seen in the graph where the array-optimized item throughput levels off as the System Time Slice is increased.

To demonstrate how the System Time Slice will even affect performance on system configurations with a smaller amount of tags on scan, and to also demonstrate the Time Slice’s effect on program scan time, the following test was performed:

488 individual integers were placed on scan via the OPC Test Client. The number of ControlLogix connections was held at the RSLinx default of 4. With a varying System Time Slice, both the update rate obtained on the items, and the (approximate) minimum and maximum Logix5550 program scan times were observed.


System TimeSlice effects on Program Scan Time

Effects of the System Time Slice setting on item updates and program scan times (No array optimizations)

488 individual native tag integers on scan (optimized into 4 packets of exactly 122 integers each)Network: ControlNetUsing 4 connections

TimeSliceUpdates per Item

(per second) Min. Program Scan Time Max Program Scan Time10% 1.8 12.7 14.420% 4.1 13.8 15.730% 6.3 16.5 18.140% 8.4 19.7 21.850% 10.8 23.8 25.860% 12.8 30.8 33.170% 14.8 42.7 45.6

Also recall that by modifying the System Time Slice, you are not only adjusting the communications, but also the scan time. Below is a graph to demonstrate how the scan time of one particular Logix5550 processor will vary as the Time Slice is adjusted.

(The scan times would fluctuate between the shown Min time and Max time.)


9) RSLinx “Smart” Polling

RSLinx 2.2 implements a new polling algorithm when collecting data that reduces CPU utilization. What this means is, when you are requesting data 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 will “back off” the excessive polling, and only poll the data from the processor at the rate it is actually being sent. This helps to cut down on CPU activity on the RSLinx system, because it is no longer trying to acquire and process data faster than it can possibly be received.

10) Setting up RSLinx to use PLC-5 mapped tags RSLinx is capable of communicating to the ControlLogix to access either native tags or PLC-5 mapped tags. A topic can be specified to access either tag type. This is set in the topic configuration dialog.

DDE/OPC Topic Configuration

As seen in the above figure, for a topic, you can choose a “Processor Type”, which tells RSLinx how it should access data from the remote processor, given its type. If you wish to access PLC-5 mapped tags, you need to manually set this option to “PLC-5”. If you had been using PLC-5 tags in the past, and you wish to begin to use native tags, you can set this option back to “Logix5000”.


11) Memory Consumption in the ControlLogix

The ControlLogix processor itself 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:

- The number of messaging connections to the processor. (Approx. 1.1K of memory is consumed / connection)

- The total number of ControlLogix optimized packets (Approx. 80 bytes / optimized packet)

- The total number of ControlLogix optimized items (Approx. 32 bytes / item)

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 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



1 1 1 1560 bytes




3 3 3 5084 bytes


No Array Optimizations 1000 9 8* 42736 bytesPerfect Array Optimizations

5 5 5 7556 bytes

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


If you cannot spare the memory in the ControlLogix, consider using PLC-5 mapped tags as opposed to native tags. Memory is not consumed when using PLC-5 tags.


12) ControlLogix Data Monitor In RSLinx 2.2 or later, there is now 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.

RSWho pop-up menu for the ControlLogix processor

ControlLogix Data Monitor


13) OPC Browsing The RSLinx OPC Server supports the OPC Browse interface of the OPC Specification. This provides a way for RSLinx clients to browse for available data addresses and symbols on certain topics. The types of topics that support tag browsing are currently (in RSLinx 2.2):

1) Any topic configured to use an external Symbol File (as specified in the Topic

Configuration)

2) A DeviceNet topic for which the proper EDS file for the target device is

registered on the system

3) A topic to a ControlLogix processor

This section will focus specifically on #3, the ControlLogix processor address browsing. However, all three techniques will behave functionally the same.

OPC Browsing Using the OPC Test client

To use the OPC Test Client to do OPC Browse operations on RSLinx, perform the following steps:

1) Run the OPC Test Client, and create a “New” server to the “RSLinx OPC Server”.

2) Create a new OPC Group. (Group -> Add Group) This option will be available only after connecting to an OPC Server.

3) Open the “Add Item” dialog. (Item -> Add Item.) At this point, the following dialog should appear:


The available tags can be browsed for on the lower half of this dialog. On the lower left hand side there is a hierarchical tree-view of branches that can be expanded. On the lower right hand side, a listing of available tags (“leaves”) on the currently selected tree branch will be displayed. Clicking on a tag here will place it into the “Items to be added” list.

The “Offline” branch will contain tags from a symbol file that is associated with the topic (if there is one); the “Online” branch will contain the complete online tag database from the ControlLogix processor, which RSLinx retrieves.

OPC Browsing Using RSView

It is also possible to use the OPC Browse capability of the RSLinx and the ControlLogix processor from directly within RSView. To do so, perform the following steps.

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:

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

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

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

- 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 topic to your ControlLogix processor, and browse through the address hierarchy to associate your tag with an address.


14) PLC-5 Mapped Tag performance

System setup:

- Dell computer, Pentium II 400, 128MB RAM, PCI Ethernet NIC card, running Windows NT 4.0 (SP5)

- RSLinx 2.2- Isolated Ethernet network (10Mbps)- 1756-ENET module- Logix5550 processor with firmware version 5.13

Test Procedure:

Several items were put on scan in the RSI OPC Test Client. The topic to the ControlLogix processor is set in RSLinx to act as a PLC-5 processor. The group update rates are set to 1ms for all tests, so that RSLinx will poll for data as fast as it can. The Packets per Second numbers were obtained via the RSLinx Driver Diagnostics.

100 Integers (One packet of 100 integers)

System Time Slice (%)

Packets per second Tags per second

10% 56 560020% 68 680030% 73 730040% 74 7400

50% + 75 7500

1000 Integers (Ten packets of 100 integers)

System Time Slice (%)

Packets per second Tags per second

10% 100 1000020% 153 1530030% 165 1650040% 165 16500

50% + 165 16500

As seen in the above tables, after a while, increasing the System Time Slice will have minimal effect on the throughput performance. The above numbers can be compared to the various native tag performance numbers in section 17.


15) The underlying network’s effect on performance System setup:


- RSLinx 2.2- Isolated Ethernet network (10Mbps), ControlNet network, DH+ network, DF1

connection.- 1756-ENET module, 1756-CNB module, DHRIO module. - Logix5550 processor with firmware version 5.13

Test Procedure:

Several items were put on scan in the RSI OPC Test Client, using four different network types. The group update rates are set to 1ms for all tests, so that RSLinx will poll for data as fast as it can.

Default CIP options (4 connections) were used, a 50% Controller Time Slice was used.

Depending on which version of RSLinx you are using, and how your tags are set up, either one of the two sets of data should be used for the appropriate comparison:

If you are using: Refer to the data for:RSLinx 2.1 SP RSLinx 2.1 SPRSLinx 2.1 SP, using tag requests with the “,L” specifier to read the data in maximum size blocks.

RSLinx 2.2

RSLinx 2.2 with tags that cannot be array-optimized RSLinx 2.1 SPRSLinx 2.2 with tags that can be array-optimized RSLinx 2.2

Comparison of Tags Per Second Throughput performance on different networks

RSLinx 2.1 SP – No array optimizations

100 Integers (approx. tags/sec)

1000 Integers(approx. tags/sec)

~ 5000 Integers(approx. tags/sec)

Ethernet Card – Ethernet 3000 4500 4600KTC Card – ControlNet 3000 4600 4600

PKTX Card – DH+ 700 800 900Serial Port – DF1 300 300 350

RSLinx 2.2 – Using array optimizations



~ 5000 Integers(approx. tags/sec)

Ethernet Card – Ethernet 7800 18000 23000KTC Card – ControlNet 6300 20000 26000

PKTX Card – DH+ 1200 1500 1700Serial Port – DF1 500 600 650


16) Effects of Connections on a ControlLogix processor System setup:


- RSLinx 2.2- Isolated Ethernet network (10Mbps)- 1756-ENET module- Logix5550 processor with firmware version 4.45

Test Procedure:

Several items were put on scan in the RSI OPC Test Client, the nature of the items are described in each test. The group update rates are set to 1ms for all tests, so that RSLinx will poll for data as fast as it can. The Packets per Second numbers were obtained via the RSLinx Driver Diagnostics.

Depending on which version of RSLinx you are using, and how your tags are set up, either one of the two sets of data should be used for the appropriate comparison:

If you are using: Refer to the data for:RSLinx 2.1 SP RSLinx 2.1 SPRSLinx 2.1 SP, using tag requests with the “,L” specifier to read the data in maximum size blocks.

RSLinx 2.2

RSLinx 2.2 with tags that cannot be array-optimized RSLinx 2.1 SPRSLinx 2.2 with tags that can be array-optimized RSLinx 2.2

From Section 8 of this document, we could conclude that using a 20% Time Slice would be ideal when performing array-optimized reads. Anything above 20% would not yield any significant performance enhancements. The following tests therefore use a 20% System Time Slice for the RSLinx 2.2 tests. For comparison’s sake, the same throughput tests were performed on RSLinx 2.1 SP2, using both the 20% Time Slice, and a significantly higher 50% time slice. The results show that you can get much better performance in RSLinx 2.2 using array optimizations, even with a greatly reduced System Time Slice in your controller.


100 Integers

Number of connections:

RSLinx 2.1 SP2, 20% Time Slice

(tags/second)

RSLinx 2.1 SP2,50% Time Slice

(tags/second)

RSLinx 2.2,20% Time Slice

(tags/second)1 1500 2800 78002 1500 2800 78004 1500 2800 78008 1500 2800 780012 1500 2800 7800

Since all 100 items are placed in one ControlLogix Optimized Packet, only one connection will ever be used, so varying the connections here doesn’t have any effect on the system.

1000 Integers



(tags/second)


(tags/second)


(tags/second)1 1556 3000 104002 1778 4333 156004 1889 4556 176008 1889 4556 1820012 1889 4556 18200

In the RSLinx 2.1 SP, it is apparent that there is a bottleneck in the system, as increasing the number of connections eventually stops having any effect at all on the throughput. This has to do with the internal processing of the ControlLogix processor, having to gather each individual integer to send as one packet.

5000 Integers



(tags/second)


(tags/second)


(tags/second)1 1464 3050 114212 1830 4514 182254 1830 4514 225998 1830 4514 2600112 1830 4514 26001


17) RSLinx 2.1 vs. RSLinx 2.1 Service Pack vs. RSLinx 2.2 Here are the results of tests performed to show the improvements of reading individual native tags from the Logix5550 using the newer ControlLogix Optimized Packet method of data, with a varying number of items. Tests were all done on Ethernet, using default CIP settings (4 connections max), and using a 50% Time Slice on the ControlLogix processor. The old RSLinx 2.1 method of data acquisition was tested using a Logix5550 controller containing older firmware (version 3.29) with RSLinx 2.1 Service Pack. Full array optimization is in effect for RSLinx 2.2. These tests were run using the OPC Test Client.

RSLinx 2.1 method – no optimized packetsPackets per

SecondTags per packet

(average)Tags Per Second

100 integers 21 1 211000 integers 21 1 2110000 integers 21 1 21100 reals 21 1 211000 reals 16 1 1610000 reals 25 1 25

RSLinx 2.1 Service Pack method – optimized packetsPackets per




RSLinx 2.2 method – optimized packets (w/array optimizations)Packets per





Side-by-side comparison of all three versions:

Tags per second throughput:

RSLinx 2.1 RSLinx 2.1SP RSLinx 2.2100 integers 21 3200 78001000 integers 21 5217 2000010000 integers 21 10614 25466100 reals 21 3300 63001000 reals 16 4928 1609510000 reals 25 6723 20706

ControlLogix Optimized Packets Needed: (Fewer is better)

RSLinx 2.1 RSLinx 2.1SP RSLinx 2.2100 integers 100 1 11000 integers 1000 9 510000 integers 10000 82 42100 reals 100 2 11000 reals 1000 13 910000 reals 10000 124 84

It is easy to see from these tables, major improvements have been made in the area of ControlLogix optimization in the last couple of releases of RSLinx. The throughput has increased, while the required processor overhead has decreased.


18) Frequently Asked Questions

Is it possible to use up too much of the Logix5550’s memory?

Depending on the number of items you are requesting from RSLinx, you may begin to use up excessive memory in the Logix5550. When this happens, you may begin to get errors returned to your clients instead of data. Because this memory consumption did not previously exist, you may now find that applications written using previous versions of RSLinx and the Logix5550 firmware might now break under the new RSLinx and Logix5550 firmware if large amounts of communications are taking place. An alternate way of communicating to the Logix5550 is by using PLC-5 mapped tags as opposed to native tags. This does not require the additional memory overhead as does the native tags. Refer to section 2 to see how memory is consumed in the processor. You can also upgrade your processor to a model with more memory to solve this condition.

How much memory will be used in the processor if I have multiple clients getting data from a single Logix5550?

Each RSLinx client communicating to the Logix5550 will use up its own required memory in the controller. The memory used (which can be estimated in Section 2) will be independent of the number of clients connected. For example, if two RSLinx clients were communicating to a Logix5550, each requiring 2000 bytes for the Optimized Packet overhead, then 4000 bytes would be consumed in the processor. If this is an issue, two suggested client/server type solutions would be to use either an RSLinx Gateway or an RSView Active Display server to be the data server, and have each client acquire its data via that server. This way, only one system (the server) will be putting the communications overhead on the controller, as opposed to each individual client.

Why can’t I access my new tags using DDE/OPC? I can even see them in RSLogix.

If the topic you are requesting the tags from had been active since the time you created the tags, you may run into this problem. RSLinx reads in the tags when a client first begins communicating with that topic, after that, new tags will not be recognized as valid. In order to use the new tags, all clients communicating with that topic would need to be shut down so that the topic is no longer being used. Once that topic is re-initialized, all tags will be accessible. RSLinx is adding code to handle this better in the future such that shutting down the client will not be necessary. Refer to section 6 in this document for methods of getting new tags to be accessible.

Is it possible for RSLinx to use up too many connections to the Logix5550?

It’s possible, if you set the “Connections for ControlLogix Processor” CIP option too high. RSLinx can be configured to use up to 32 connections per processor. It is important to realize that if RSLinx consumes excessive connections, fewer connections will be available for other devices or other client applications to use. This may result in timeouts and/or other undesirable behaviors. To avoid this situation, be careful of the ramifications of allowing additional connections to be used when communicating with the ControlLogix processor using RSLinx.


What happens when communications are disrupted between RSLinx and the Logix5550?

This depends on which network you are using to communicate to the ControlLogix processor. If you are using Ethernet, and the disruption is corrected within the connection timeout period, communications will resume gracefully. Unfortunately, due to limitations in the CNB(R) modules, ControlNet communications behave differently. The ControlLogix processor will time-out the Optimized Packet structures stored in memory after the connection time-out period has transpired. After this happens, the memory that RSLinx was consuming will be freed up in the processor. If communications are then re-established between RSLinx and the ControlLogix, RSLinx will recreate the optimized packets and restore communications. This does, however, take much more time than Ethernet does to recover.

What happens with optimization when your MMI screen changes?

When some items are no longer being requested in RSLinx, as would be the case when an MMI screen changes, RSLinx begins a process of removing the items no longer active from the optimized packets. After this occurs, if different items are activated, they can be placed in the old optimized packets if there is room for them. Otherwise, new items will be placed in their own new packet(s). Also, currently, optimized packets will not be re-optimized. What this means is that if there are two packets, both of which have had items removed from them, to the point where they could theoretically be combined into one packet, this will not occur.

What happens with the optimized packets when multiple topics communicate to a Logix5550 processor?

If you have multiple topics configured to a ControlLogix that all have the same communications route, RSLinx will be able to optimize the data being read from both topics together, so that the communications overhead will not have to be duplicated for each topic. RSLinx and the Logix5550 controller cannot share the optimized packet overhead if you are acquiring data from the same processor via different communications paths, however. What this means is that even if you are requesting the same data from fboth topics, to the same Logix5550, you could not share the optimized packet overhead between both topics. They would both need to handle this separately.

What other performance enhancements are planned for improved communications to the Logix5550?

This is the second of many planned enhancements. Optimization of write operations remains to be completed. Further optimization of arrayed items is another area of improvement.

Why can I only get 81 Boolean tags in a single optimized packet?


If you are only getting 81 Boolean items in a ControlLogix Optimized Packet (using RSLinx 2.2), you are most likely not requesting those Booleans from within a Boolean array. Only elements within a Boolean array can be optimized, up to 3872 in a single packet. Nothing can be done with individual native Booleans. A Boolean tag is stored in the controller as a DWORD and as a result, we can only fit a maximum number of 81 items in a single optimized packet. Only in arrays can RSLinx go around this limitation to treat Booleans as a single bit value.

To what extent are ControlLogix structured data types and UDT’s optimized?

A: Support for optimization of UDT’s and structured data types is introduced in RSLinx 2.2 Service Pack 1, and is discussed in Section 2 of this document.

Does the array optimization apply to an array of UDT's?

A: No. Array optimization only applies to simple data types (i.e. INT, SINT, DINT, BOOL, REAL).

I have an array of data that is updated with the same value from my control program. Why am I getting different values when I read the arrayed data?

A: Data read by RSLinx is handled as a background task that can be interrupted by a scheduled task or swapped with main periodic task based on the system time slice setting (see section 8). Data integrity in the ControlLogix processor is only guaranteed over a single tag boundary. For example, if you are reading 4 consecutive INT values in an array, RSLinx could start reading values in the array, get interrupted by another task that changes the data, then return to resume reading newer data in the array. We recommend using handshaking between the control program and RSLinx reading the data to ensure data integrity over a larger boundary than a single element.


clxperf

Documents