RSLinx: ControlLogix Data Access
Via OPC
Updated for RSLinx version 2.2 Service
Pack 1
Rockwell Software
Document Version 2.12 7/18/2000
Document Version 2.12
3/8/2016
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 ............................................. 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
Document Version 2.12
3/8/2016
Page 2
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
Document Version 2.12
3/8/2016
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.12
3/8/2016
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.
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.
Document Version 2.12
3/8/2016
Page 5
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 subelement 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.
Document Version 2.12
3/8/2016
Page 6
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:
Document Version 2.12
3/8/2016
Page 7
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.)
Document Version 2.12
3/8/2016
Page 8
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 subelement at a time.
Document Version 2.12
3/8/2016
Page 9
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.12
3/8/2016
Page 10
Communications event log states that the firmware version in the ControlLogix is
incompatible with the optimization techniques.
Document Version 2.12
3/8/2016
Page 11
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.12
3/8/2016
Page 12
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.
Document Version 2.12
3/8/2016
Page 13
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-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.12
3/8/2016
Page 14
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.12
3/8/2016
Page 15
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.12
3/8/2016
Page 16
“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.12
3/8/2016
Page 17
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
Document Version 2.12
3/8/2016
Page 18
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.12
3/8/2016
Page 19
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
Items Per Packet
122
Item per second throughput
10%
Packets Per Second
12
20%
30%
22
31
122
122
2684
3782
40%
50%
39
47
122
122
4758
5734
60%
70%
56
64
122
122
6832
7808
100% (program mode)
88
122
10736
1464
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
Packets Per Second
Items Per Packet
Item per second throughput
10%
20%
69
105
243
243
16767
25515
30%
40%
106
107
243
243
25758
26001
50%
60%
107
107
243
243
26001
26001
70%
100% (program mode)
107
130
243
243
26001
31590
Document Version 2.12
3/8/2016
Page 20
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 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
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.
Document Version 2.12
3/8/2016
Page 21
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
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.
Document Version 2.12
3/8/2016
Page 22
(The scan times would fluctuate between the shown Min time and Max time.)
Document Version 2.12
3/8/2016
Page 23
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.12
3/8/2016
Page 24
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
No Array Optimizations
100
1
1
4532 bytes
Perfect Array
Optimizations
1
1
1
1560 bytes
500 native tag
integers
No Array Optimizations
500
5
5
22660 bytes
Perfect Array
Optimizations
3
3
3
5084 bytes
1000 native tag
integers
No Array Optimizations
Perfect Array
Optimizations
1000
5
9
5
8*
5
42736 bytes
7556 bytes
* RSLinx was configured to use up to 8 connections for this test.
Document Version 2.12
3/8/2016
Page 25
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.12
3/8/2016
Page 26
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.12
3/8/2016
Page 27
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.12
3/8/2016
Page 28
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.12
3/8/2016
Page 29
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.12
3/8/2016
Page 30
Document Version 2.12
3/8/2016
Page 31
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
Tags per second
56
68
73
74
75
5600
6800
7300
7400
7500
1000 Integers (Ten packets of 100 integers)
System Time
Slice (%)
10%
20%
30%
40%
50% +
Packets per second
Tags per second
100
153
165
165
165
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.12
3/8/2016
Page 32
15) The underlying network’s 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
Ethernet Card – Ethernet
KTC Card – ControlNet
PKTX Card – DH+
Serial Port – DF1
100 Integers
(approx. tags/sec)
3000
3000
700
300
1000 Integers
~ 5000 Integers
(approx. tags/sec)
(approx. tags/sec)
4500
4600
800
300
4600
4600
900
350
RSLinx 2.2 – Using array optimizations
Ethernet Card – Ethernet
KTC Card – ControlNet
PKTX Card – DH+
Serial Port – DF1
Document Version 2.12
100 Integers
1000 Integers
~ 5000 Integers
(approx. tags/sec)
(approx. tags/sec)
(approx. tags/sec)
7800
6300
1200
500
18000
20000
1500
600
23000
26000
1700
650
3/8/2016
Page 33
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 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.
Document Version 2.12
3/8/2016
Page 34
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 doesn’t 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
Document Version 2.12
RSLinx 2.1 SP2,
50% Time Slice
(tags/second)
3050
4514
4514
4514
4514
3/8/2016
RSLinx 2.2,
20% Time Slice
(tags/second)
11421
18225
22599
26001
26001
Page 35
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.12
3/8/2016
Page 36
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.12
3/8/2016
Page 37
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.
Document Version 2.12
3/8/2016
Page 38
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.12
3/8/2016
Page 39
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.
Document Version 2.12
3/8/2016
Page 40