RSLinx: ControlLogix Data Access Via OPC Updated for RSLinx version 2.

Rockwell Software
Document Version 2.11 6/23/2000

Document Version 2.11

1/10/2013

Page 1

1) Optimizations an overview...........................................................................................4 2) ControlLogix Optimized Packets....................................................................................5 ControlLogix Array Optimization...............................................................................5 Boolean Array Optimization........................................................................................5 3) Firmware Requirements for ControlLogix Optimization................................................9 4) Checking your ControlLogix firmware version in RSLinx...........................................11 5) ControlLogix Optimized Packet creation .....................................................................12 6) How RSLinx performs reads on a ControlLogix processor..........................................13 7) RSLinx Configuration Settings.....................................................................................15 Limit Maximum Packets............................................................................................15 Communications Time-Out.......................................................................................15 CIP Options for ControlLogix...................................................................................16 8) System Overhead Time Slice........................................................................................18 Using non-array-optimized items:.............................................................................19 Using array-optimized items:.....................................................................................19 System TimeSlice effects on Program Scan Time.....................................................21 9) RSLinx Smart Polling................................................................................................23 10) Setting up RSLinx to use PLC-5 mapped tags............................................................23 11) Memory Consumption in the ControlLogix................................................................24 12) ControlLogix Data Monitor.........................................................................................25 13) OPC Browsing.............................................................................................................26 OPC Browsing Using the OPC Test client................................................................26 OPC Browsing Using RSView..................................................................................27 14) PLC-5 Mapped Tag performance................................................................................30 15) The underlying networks effect on performance.......................................................31 Comparison of Tags Per Second Throughput performance on different networks...31 16) Effects of Connections on a ControlLogix processor ................................................32 1000 Integers..............................................................................................................33 5000 Integers..............................................................................................................33 17) RSLinx 2.1 vs. RSLinx 2.1 Service Pack vs. RSLinx 2.2..........................................34 RSLinx 2.1 method no optimized packets..............................................................34 RSLinx 2.1 Service Pack method optimized packets.............................................34 RSLinx 2.2 method optimized packets (w/array optimizations)............................34 Side-by-side comparison of all three versions:..........................................................35 Tags per second throughput:..........................................................................................35 ControlLogix Optimized Packets Needed: (Fewer is better).........................................35

Document Version 2.11

1/10/2013

Page 2

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. ....................................35 18) Frequently Asked Questions.......................................................................................36 Is it possible to use up too much of the Logix5550s memory? ...............................36 How much memory will be used in the processor if I have multiple clients getting data from a single Logix5550?..................................................................................36 Why cant I access my new tags using DDE/OPC? I can even see them in RSLogix. ....................................................................................................................................36 Is it possible for RSLinx to use up too many connections to the Logix5550?..........36 What happens when communications are disrupted between RSLinx and the Logix5550? ...............................................................................................................37 What happens with optimization when your MMI screen changes?.........................37 What happens with the optimized packets when multiple topics communicate to a Logix5550 processor?................................................................................................37 What other performance enhancements are planned for improved communications to the Logix5550?..........................................................................................................37 Why can I only get 81 Boolean tags in a single optimized packet?..........................37 To what extent are ControlLogix structured data types and UDTs optimized?.......38 Does the array optimization apply to an array of UDT's?.........................................38 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?.............................38

Document Version 2.11

1/10/2013

Page 3

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

Document Version 2.11

1/10/2013

Page 4

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. 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, lets 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 takes 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. 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:

Document Version 2.11

1/10/2013

Page 5

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.
Document Version 2.11 1/10/2013 Page 6

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

Document Version 2.11

1/10/2013

Page 7

DDE/OPC Server Diagnostics for our example setup

Note- You will need to scroll down to view the ControlLogix information on this diagnostics screen.

Document Version 2.11

1/10/2013

Page 8

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.

Document Version 2.11

1/10/2013

Page 9

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

Document Version 2.11

1/10/2013

Page 10

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.
Document Version 2.11 1/10/2013 Page 11

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

Document Version 2.11

1/10/2013

Page 12

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 UDTs when it performs this particular tag upload. Any information about UDTs 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 its dealing with the most up-todate 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.

Document Version 2.11

1/10/2013

Page 13

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

Document Version 2.11

1/10/2013

Page 14

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.

Document Version 2.11

1/10/2013

Page 15

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.

Document Version 2.11

1/10/2013

Page 16

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.

Configure CIP Options settings

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

Document Version 2.11

1/10/2013

Page 17

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.

Document Version 2.11

1/10/2013

Page 18

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 OPTIMIZATIONS 4880 individual native tag integers on scan (optimized into 40 packets of exactly 122 integers each) Network: Ethernet Using 8 connections TimeSlice 10% 20% 30% 40% 50% 60% 70% 100% (program mode) Packets Per Second 12 22 31 39 47 56 64 88 Items Per Packet 122 122 122 122 122 122 122 122 Item per second throughput 1464 2684 3782 4758 5734 6832 7808 10736

Using array-optimized items:

Effects of the System Time Slice setting on item throughput- WITH ARRAY OPTIMIZATIONS 4860 individual native tag integers on scan (optimized into 20 packets of exactly 243 integers each) Network: Ethernet Using 8 connections TimeSlice 10% 20% 30% 40% 50% 60% 70% 100% (program mode) Packets Per Second 69 105 106 107 107 107 107 130 Items Per Packet 243 243 243 243 243 243 243 243 Item per second throughput 16767 25515 25758 26001 26001 26001 26001 31590

Document Version 2.11

1/10/2013

Page 19

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

Effects of the System Time Slice setting on item throughput

35000 30000

Items per Second

25000 20000 15000 10000 5000 0 0 10 20 30 40 50 60 70 80 90 100

Non-Array Optimized Items Array Optimized Items

System Timeslice (%)

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 arrayoptimized 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 Slices 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.

Document Version 2.11

1/10/2013

Page 20

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: ControlNet Using 4 connections TimeSlice 10% 20% 30% 40% 50% 60% 70% Updates per Item (per second) 1.8 4.1 6.3 8.4 10.8 12.8 14.8 Min. Program Scan Time 12.7 13.8 16.5 19.7 23.8 30.8 42.7 Max Program Scan Time 14.4 15.7 18.1 21.8 25.8 33.1 45.6

Update Rates Achieved For Items as System Time Slices Vary 16

Update Rate pe r Ite m (update s/se c)

14 12 10 8 6 4 2 0 0 10 20 30 40 50 60 70 80
System Timeslice (%)

Update Rate

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.)
Document Version 2.11 1/10/2013 Page 21

Logix5550 Program Scan Times as System Time Slices Vary

50 Scan Time (ms) 40 30 20 10 0 0 10 20 30 40 50 60 70 80 System Time Slice (%)
Min time Max time

Document Version 2.11

1/10/2013

Page 22

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.

Document Version 2.11

1/10/2013

Page 23

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. If your data clients were already set up in RSLinx 2.1 SP to request contiguous data items from an array, when you upgrade to RSLinx 2.2, you will automatically begin to use the reduced amounts of memory.
Test setup Array optimizations? ControlLogix Optimized Items 1 1 ControlLogix Optimized Packets 1 1 Connections to processor used Memory consumed in processor 1364 bytes 1364 bytes

1 native tag integer

No Array Optimizations Perfect Array Optimizations No Array Optimizations Perfect Array Optimizations No Array Optimizations Perfect Array Optimizations No Array Optimizations Perfect Array Optimizations

1 1

100 native tag integers

100 1

1 1

1 1

4532 bytes 1560 bytes

500 native tag integers

500 3

5 3

5 3

22660 bytes 5084 bytes

1000 native tag integers

1000 5

9 5

8* 5

42736 bytes 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.
Document Version 2.11 1/10/2013 Page 24

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

Document Version 2.11

1/10/2013

Page 25

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:

Document Version 2.11

1/10/2013

Page 26

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.

Document Version 2.11

1/10/2013

Page 27

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.

Document Version 2.11

1/10/2013

Page 28

Document Version 2.11

1/10/2013

Page 29

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 (%) 10% 20% 30% 40% 50% + Packets per second 56 68 73 74 75 Tags per second 5600 6800 7300 7400 7500

1000 Integers (Ten packets of 100 integers)

System Time Slice (%) 10% 20% 30% 40% 50% + Packets per second 100 153 165 165 165 Tags per second 10000 15300 16500 16500 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.

Document Version 2.11

1/10/2013

Page 30

15) The underlying networks effect on 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), 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: RSLinx 2.1 SP RSLinx 2.1 SP, using tag requests with the ,L specifier to read the data in maximum size blocks. RSLinx 2.2 with tags that cannot be array-optimized RSLinx 2.2 with tags that can be array-optimized Refer to the data for: RSLinx 2.1 SP RSLinx 2.2 RSLinx 2.1 SP 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) 3000 3000 700 300 1000 Integers
(approx. tags/sec)

~ 5000 Integers
(approx. tags/sec)

Ethernet Card Ethernet KTC Card ControlNet PKTX Card DH+ Serial Port DF1 RSLinx 2.2 Using array optimizations

4500 4600 800 300

4600 4600 900 350

100 Integers
(approx. tags/sec)

1000 Integers
(approx. tags/sec)

~ 5000 Integers
(approx. tags/sec)

Ethernet Card Ethernet KTC Card ControlNet PKTX Card DH+ Serial Port DF1

7800 6300 1200 500

18000 20000 1500 600

23000 26000 1700 650

Document Version 2.11

1/10/2013

Page 31

16) Effects of Connections on a ControlLogix processor

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 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: RSLinx 2.1 SP RSLinx 2.1 SP, using tag requests with the ,L specifier to read the data in maximum size blocks. RSLinx 2.2 with tags that cannot be array-optimized RSLinx 2.2 with tags that can be array-optimized Refer to the data for: RSLinx 2.1 SP RSLinx 2.2 RSLinx 2.1 SP 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 comparisons 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.

Document Version 2.11

1/10/2013

Page 32

100 Integers
Number of connections: 1 2 4 8 12 RSLinx 2.1 SP2, 20% Time Slice (tags/second) 1500 1500 1500 1500 1500 RSLinx 2.1 SP2, 50% Time Slice (tags/second) 2800 2800 2800 2800 2800 RSLinx 2.2, 20% Time Slice (tags/second) 7800 7800 7800 7800 7800

Since all 100 items are placed in one ControlLogix Optimized Packet, only one connection will ever be used, so varying the connections here doesnt have any effect on the system. 1000 Integers
Number of connections: 1 2 4 8 12 RSLinx 2.1 SP2, 20% Time Slice (tags/second) 1556 1778 1889 1889 1889 RSLinx 2.1 SP2, 50% Time Slice (tags/second) 3000 4333 4556 4556 4556 RSLinx 2.2, 20% Time Slice (tags/second) 10400 15600 17600 18200 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
Number of connections: 1 2 4 8 12 RSLinx 2.1 SP2, 20% Time Slice (tags/second) 1464 1830 1830 1830 1830 RSLinx 2.1 SP2, 50% Time Slice (tags/second) 3050 4514 4514 4514 4514 RSLinx 2.2, 20% Time Slice (tags/second) 11421 18225 22599 26001 26001

Document Version 2.11

1/10/2013

Page 33

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 packets Packets per Tags per packet Second (average) 100 integers 21 1 1000 integers 21 1 10000 integers 21 1 100 reals 21 1 1000 reals 16 1 10000 reals 25 1 RSLinx 2.1 Service Pack method optimized packets Packets per Tags per packet Second (average) 100 integers 32 100 1000 integers 47 111 10000 integers 87 122 100 reals 66 50 1000 reals 64 77 10000 reals 83 81 Tags Per Second 21 21 21 21 16 25 Tags Per Second 3200 5217 10614 3300 4928 6723

RSLinx 2.2 method optimized packets (w/array optimizations) Packets per Tags per packet Tags Per Second Second (average) 100 integers 78 100 7800 1000 integers 100 200 20000 10000 integers 107 238 25466 100 reals 63 100 6300 1000 reals 145 111 16095 10000 reals 174 119 20706

Document Version 2.11

1/10/2013

Page 34

Side-by-side comparison of all three versions: Tags per second throughput: 100 integers 1000 integers 10000 integers 100 reals 1000 reals 10000 reals RSLinx 2.1 21 21 21 21 16 25 RSLinx 2.1SP 3200 5217 10614 3300 4928 6723 RSLinx 2.2 7800 20000 25466 6300 16095 20706

ControlLogix Optimized Packets Needed: (Fewer is better) 100 integers 1000 integers 10000 integers 100 reals 1000 reals 10000 reals RSLinx 2.1 100 1000 10000 100 1000 10000 RSLinx 2.1SP 1 9 82 2 13 124 RSLinx 2.2 1 5 42 1 9 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.

Document Version 2.11

1/10/2013

Page 35

18) Frequently Asked Questions

Is it possible to use up too much of the Logix5550s 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 cant 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? Its 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.
Document Version 2.11 1/10/2013 Page 36

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 reestablished 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 reoptimized. 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?

Document Version 2.11 1/10/2013 Page 37

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 UDTs optimized? A: Currently, there is not a method for a client to request an entire structured data type (e.g. Timer, Counter or UDT structure) as a single request. A client must request each component as an individual item. These single item requests are still combined in an optimized packet based on the guidelines described in this document. If an UDT structure contains an array of a simple data types, array optimizations will be performed on those items. 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.

Document Version 2.11

1/10/2013

Page 38