Sunteți pe pagina 1din 43

Application Guide:

ControlLogix Data Collection with RSLinx


Updated For RSLinx 2.43
Rockwell Software
Document Version: 2.43

INTRODUCTION............................................................................................................. 4
DESIGN TIPS FOR OPTIMAL PERFORMANCE ..................................................... 4
GIVE THE CONTROLLOGIX PROCESSOR ENOUGH COMMUNICATIONS BANDWIDTH ......... 4
The Continuous Task................................................................................................... 4
Periodic Tasks............................................................................................................. 6
Using Both a Continuous and Periodic Tasks ............................................................ 6
Configuring ControlLogix Processors as Data Concentrators .................................. 7
MAXIMIZE CONTROLLOGIX COMMUNICATIONS BANDWIDTH USAGE ............................. 7
Have only one RSLinx communicate to any ControlLogix Processor........................ 7
Use RSLinx Gateway to Get Data into Many Stations ............................................... 7
Collect Data from Arrays or UDT structures ............................................................. 8
Separate data collection from time critical control programs ................................... 8
Dont poll data too fast ............................................................................................... 8
KEEP TAGS ON SCAN ....................................................................................................... 8
USE A FASTER CONTROLLOGIX PROCESSOR .................................................................... 9
ENSURE RSLINX AND CONTROLLOGIX VERSIONS ARE CURRENT ENOUGH ...................... 9
CONFIGURING RSLINX ............................................................................................. 10
TOPIC PARAMETERS ....................................................................................................... 11
Polled Messages........................................................................................................ 11
Unsolicited Messages................................................................................................ 11
Communications Time-Out ....................................................................................... 11
Use Symbols .............................................................................................................. 12
RSLOGIX 5000 AUTOMATICALLY CONFIGURES TOPICS IN RSLINX .............................. 12
UNDERSTANDING CONTROLLOGIX DATA COLLECTION ............................ 13
STEP-BY-STEP ................................................................................................................ 13
READ OPTIMIZATION ..................................................................................................... 15
Array optimization .................................................................................................... 15
Boolean Array Optimization ..................................................................................... 16
UDT optimization...................................................................................................... 16
First Level or Scattered Optimization .................................................................. 18
How much data can be read in a ControlLogix Optimized Packet? ........................ 18
WRITE OPTIMIZATION .................................................................................................... 19
How to Use Write Optimization................................................................................ 19
Array optimization for writes.................................................................................... 19
How many tags can be sent in a write packet to the ControlLogix? ........................ 19
Data Type.................................................................................................................. 19
Max. Items that fit into a Write Packet ..................................................................... 19
RSLINX SMART POLLING ........................................................................................... 20
HOW RSLINX USES CONTROLLOGIX CONNECTIONS ..................................................... 20
MEMORY CONSUMPTION IN THE CONTROLLOGIX PROCESSOR ...................................... 22
COMMUNICATION EVENT LOG ............................................................................. 24
GETTING RSLINX DATA INTO APPLICATIONS ................................................. 26
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 2

LOGIX5000 TAG IMPORT UTILITY - IMPORT CONTROLLOGIX TAGS INTO RSVIEW AND
RSSQL .......................................................................................................................... 26
BROWSING AND SELECTING CONTROLLOGIX TAGS ....................................................... 26
MISCELLANEOUS RSLINX FEATURES AND TIPS ............................................. 30
BACKUP/RESTORE RSLINX CONFIGURATIONS TO/FROM A FILE ................................... 30
CONTROLLOGIX DATA MONITOR .................................................................................. 31
RSLINXS COPY DDE/OPC LINK SUPPORTS BROWSING CONTROLLOGIX TAGS ............ 32
GETTING MODULE INFORMATION IN RSLINX ................................................................ 33
APPLICATION NOTES ................................................................................................ 35
PUT TAGS ON SCAN AT THE SAME TIME ........................................................................ 35
CHANGING CONTROLLOGIX TAGS WHILE ON SCAN ..................................................... 35
REDUNDANT RSLINX GATEWAY SERVERS WITH RSVIEWS NODESWITCH COMMAND 37
REDUNDANCY FOR CONTROLLOGIX PROCESSORS.......................................................... 37
USING CONTROLLOGIX STRINGS ................................................................................... 37
TROUBLESHOOTING ................................................................................................. 37
PERFORMANCE ........................................................................................................... 38
THROUGHPUT VS. SYSTEM OVERHEAD TIME SLICE WITH A CONTINUOUS TASK ........... 38
THROUGHPUT VS. PERIODIC RATE WITH A PERIODIC TASK ............................................ 40
THROUGHPUT VS. SYSTEM OVERHEAD TIME SLICE AND PERIODIC RATE WITH A
CONTINUOUS AND A PERIODIC TASK ............................................................................. 42
PROCESSOR TYPE VS. PERFORMANCE ............................................................................ 42

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 3

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

Design Tips for Optimal Performance


Give the ControlLogix Processor Enough Communications Bandwidth
The ControlLogix processors task configuration determines the communications
bandwidth available for data collection. There is a tradeoff between faster task execution
times and data collection performance. The default setting in the ControlLogix processor
is optimized for fast task execution. You will need to find the appropriate balance
between task execution time and data collection performance for your application. The
ControlLogix processor can run two types of tasks; continuous and periodic. The
following gives an explanation of each and how their configurations affect
communications bandwidth.
The Continuous Task
This is the default task type and only one can exist. The ControlLogix CPU constantly
swaps between running the task and servicing communications. The System Overhead
Time Slice dictates how much relative time can be allocated for all communications vs.
running the task. Lets consider an example where the System Overhead Time Slice was
set to 10%. In this case, for every 10ms we can expect that 9ms will be spent running the
task and 1ms for all communications including RSLinx data collection, motion, I/O, and
messaging. Increasing the System Overhead Time Slice can and usually does increase the
task scan time. The System Overhead Time Slice is a property of the ControlLogix
Processor and can be set in RSLogix under Edit->Controller Properties. This can also be
modified with an OPC tag in conjunction with the ControlLogix Set command. (Ladder
logic)

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 4

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

The Configuration tab of the Task Properties in RSLogix5000 for the continuous task,
showing the Max Scan Time of the task
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 5

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

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

Using Both a Continuous and Periodic Tasks


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

Page 6

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

Configuring ControlLogix Processors as Data Concentrators


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

Maximize ControlLogix Communications Bandwidth Usage


Have only one RSLinx communicate to any ControlLogix Processor
We highly recommend having only one RSLinx communicating to any ControlLogix
processor, or two if redundant data servers are needed. RSLinx has been designed to
optimize communications to so using more than one RSLinx to any controller will bypass
these optimizations and increase the ControlLogix CPU and memory resources needed to
communicate. These resources often account for data acquisition performance
bottlenecks.
Its OK to have an RSLinx station communicate to more than one ControlLogix
processor. There is no physical limit on how many ControlLogix processors one RSLinx
can communicate to but there is a practical limit imposed by workstation CPU resources.
Use RSLinx Gateway to Get Data into Many Stations
In many applications you may need to get ControlLogix data into several HMI, batch, or
other data collection stations. Leverage RSLinx Gateway to achieve data collection on
several stations without having each station communicate to ControlLogix controller(s)
directly. Each station will connect via Remote OPC to RSLinx Gateway. RSLinx
Gateway optimizes several data collection stations requests to the ControlLogix, which
minimizes communication burden. For example, if several stations request the same tag
RSLinx Gateway will only request it once from the ControlLogix and serve it up to each
of the data collection stations. There is no physical limit on how many Remote OPC
clients can connect to RSLinx Gateway.
Leverage RSLinx Gateway Correctly
This is very important. RSLinx Gateway to remote RSView or other remote data
collection applications is used differently than with RSLogix. For data collection, remote
OPC is used. This is achieved by configuring DDE/OPC topics on the RSLinx Gateway
and having the data collection stations connect via Remote OPC. Note that RSLinx will
not even be used on the data collection stations.
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 7

In contrast, RSLogix has to have a local RSLinx with a TCP driver that references a
driver on the RSLinx Gateway. Do not use this setup for data collection as it bypasses
RSLinx optimization and creates more communication burden on the ControlLogix.
Eliminate a single point of failure with redundant RSLinx Gateways
This is easily done with having a backup RSLinx Gateway server available. If the
RSLinx Gateway server fails then all HMI stations can switch their data collection to the
backup RSLinx Gateway server. RSView for example has a simple node-switch
command that will switch the data collection from one RSLinx Gateway server to
another. See the application Note section of the document for an example.
TIP: One option to reduce hardware cost is to make one of the HMI stations the RSLinx
Gateway server or backup server.
Collect Data from Arrays or UDT structures
Collecting data contained in arrays or UDTs that can be optimized will use less
ControlLogix processor CPU resources and memory. Array optimization happens
automatically when array elements of a one dimensional array are put on scan by a data
collection application at the same time. The ControlLogix processor will internally treat a
range of these array elements as a single tag thus consuming less CPU and memory
resources.
UDT optimization works by having RSLinx grab the entire UDT structure when any of
the structures members are put on scan and the UDT optimization is enabled in RSLinx.
See the UDT Optimization section later in this document for more information.
Separate data collection from time critical control programs
In many cases a ControlLogix processor is running time critical code with little room to
allocate for communications. If more communications bandwidth is needed and there is
no tolerance for increasing task time consider consolidating data collection and I/O as
much as possible into specific ControlLogix processors that are not controlling time
critical tasks.
Dont poll data too fast
Sometimes you can get better performance by not requesting data so fast. For example, if
you are collecting data every 10ms in an HMI application and updates are too slow try
backing off to collecting the data every 250-500ms or higher. HMI screens cant update
every 10ms anyway and you will reduce the burden on the ControlLogix processor and
your data collection station.

Keep Tags on Scan


When a data collection application puts tags on and off scan RSLinx must negotiate with
the ControlLogix processor and build up ControlLogix Optimized Packets. This accounts
for why it sometimes takes a while to get data when switching between HMI screens or
when starting up an HMI project. In many applications, its better to put all tags on scan
when the project starts. Youll get the best optimization possible and little delay when
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 8

switching between HMI screens. Keeping all tags on scan will use more memory in the
ControlLogix processor but the communications performance will be steadier. Network
traffic will be higher but in many cases thats not the bottleneck. If your HMI is
constantly putting tags on scan and taking them off, communications will be disrupted
often and you will not get the best optimization between RSLinx and the ControlLogix
processor. You may have to experiment with you particular setup to see what works best
for your particular application.

Use a Faster ControlLogix Processor


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

Ensure RSLinx and ControlLogix versions are current enough


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

Minimum RSLinx Version Minimum ControlLogix


Firmware Version

First Level optimization


Array Optimization
UDT Optimization
String Support
Write Optimization
(Greatly enhances batch and
recipe downloads)
Numerous enhancements
and fixes

RSLinx 2.1*
RSLinx 2.2
RSLinx 2.2 SP1
RSLinx 2.3
RSLinx 2.30.02

4.41*
4.41
4.41
8.x
10.x

RSLinx 2.40 and +

---

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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 9

Configuring RSLinx
Configuring RSLinx to communicate to data collection applications involves creating a
Topic. The RSLinx setup is the same for DDE or OPC applications. For the best
performance we recommend that any ControlLogix processor should not use more than
one RSLinx for data collection. Youre communications will be less efficient if you
create topics on multiple RSLinx stations to the same ControlLogix processor. If several
data collection stations are going to be collecting data then use an RSLinx Gateway. Only
the RSLinx Gateway station will need to have a topic configured. OPC applications know
how to remotely connect to the RSLinx Gateway and collect data using its topic.
Here is the easiest way to create a topic. Note this assumes that a driver is already
configured for the relevant network. We will use Ethernet in this example.
Step 1: In the RSWho window right mouse click on the ControlLogix processor that you
want to configure a topic to. Select Configure New DDE/OPC Topic. The DDE/OPC
Topic Configuration dialog will open.

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


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

Page 10

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


ControlLogix topic

Topic Parameters
Polled Messages
A topic to a ControlLogix processor has to be configured for either polled or unsolicited
messages. Polled messaging should be used if you want RSLinx to poll the ControlLogix
processor for the requested data items. The polling interval specifies how often data items
are read from the controller. This is the interval for which DDE clients will be updated.
OPC clients will be updated at their requested intervals.
Unsolicited Messages
You have to configure a separate topic for unsolicited messages when you want the
ControlLogix processor to send the data to RSLinx via a message instruction. Unsolicited
data sent to RSLinx is passed onto any clients requesting the data items.
Communications Time-Out
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. You can increase the
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 11

Communications Time-Out for the topic if you are requesting a large amount of data, and
receiving a lot of time-outs in the RSLinx Communication event log. The timeout
message for ControlLogix is CIP Messaging Error: a message timed out waiting for a
response.

Use Symbols
This is where you associate the RSLogix 5000 .acd file to the topic for offline browsing.
This will allow you to configure your data collection applications offline since the list of
available tags is associated with the topic. You need to have RSLogix5000 v10 or higher
to use this feature.
Optimize Poke Packets Enables/Disables write optimization. This option is enabled
by default when a new topic is created in RSLinx 2.30.02 and later. Make sure that this
option is enabled if you upgraded from a previous version of RSLinx and if you are going
to be sending batch/recipe downloads or any other data to the ControlLogix processor.
This option is only available for ControlLogix processors with firmware version 10.x or
above and RSLinx 2.30.02 or later.

RSLogix 5000 Automatically Configures Topics in RSLinx


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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 12

Understanding ControlLogix Data Collection


Data collection with ControlLogix processors is very different from PLC-5 and SLC
based controllers. Controller tags are structured as data tables in these legacy controllers
so RSLinx already has built in knowledge of the tag data types and how they are
structured. The ControlLogix tag and data type flexibility frees its users from such
restrictive data definitions and allows users to model their data meaningfully. This
flexibility introduces some overhead since RSLinx initially does not have any knowledge
of what tags are available and their data types.
When a data collection application initially requests data from a ControlLogix, RSLinx
will upload a list of all the available tags and their data types. RSLinx will keep this
information in memory. Each time an OPC or DDE application requests data, RSLinx
will determine how to request the data optimally to the ControlLogix packing up to 486
bytes worth of data into each request. Each of these requests from RSLinx to the
ControlLogix is referred to a ControlLogix Optimized Packet. The size of this packet is
limited by the size of a ControlNet packet, which is essentially the network that the back
plane of the 1756 chassis uses.

Step-by-Step
Reading ControlLogix data:
1. A data collection application puts tags on scan through RSLinxs OPC or DDE
interfaces.
2. RSLinx uploads a list all of the available ControlLogix tags and their data types.
RSLinx stores this list in memory.
3. RSLinx builds ControlLogix optimized packets. Each optimized packet can hold
up to 488 bytes worth of data.
4. Once the packets are built, data can be delivered from RSLinx to data collection
applications via OPC or DDE. It can take several seconds to put several thousand
tags on scan.
Note: RSLinx 2.3 SP1 and ControlLogix firmware 10.x and above employ a faster
method of putting tags on scan and taking them off.
Tags taken off/put on scan: (Typically when switching HMI screens)
5. When tags are taken off scan RSLinx will remove those tags from their
corresponding ControlLogix Optimized Packets. RSLinx will re-optimize
whatever tags are on scan after the removal and recreate as few packets as
possible. All data from that ControlLogix will stop updating until re-optimization
is complete. The ControlLogix cannot send a packet of data while the contents of
the packet are changing.
6. When new tags are put on scan RSLinx will build new optimized packets. If the
tags are already on scan then RSLinx will simply get the data from the existing
ControlLogix Optimized Packets. This is where using RSLinx Gateway to serve
data to multiple data collection stations is more efficient over having several
independent RSLinx stations. The ControlLogix processor needs to build and
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 13

service one set on ControlLogix Optimized Packets for the RSLinx Gateway.
Multiple RSLinx stations would require the ControlLogix processor to build and
service a set of ControlLogix Optimized Packets to each RSLinx station, even
when each station is collecting the same data!
Adding, removing, or modifying tags in the ControlLogix processor while collecting
data:
Typically, data collection stations will be running while new programs are downloaded
and/or online changes are made to ControlLogix processors. If you are using a version of
RSLinx earlier then 2.30 then any change to the ControlLogix processors tags will
require that all data collection applications be stopped before the changes are made and
then restarted once the ControlLogix processor has been updated. RSLinx 2.30 has the
capability of detecting these changes but you need to manually instruct RSLinx to update
the ControlLogix tag information.
Improvements have been made to RSLinx 2.30.02 so that data collection can continue
largely uninterrupted when the tags inside of the ControlLogix processor change. RSLinx
now frequently checks the ControlLogix processor to see if any changes have been made
to its tags and in many cases automatically updates the ControlLogix tag information.
Here are some scenarios involving changing the ControlLogix tags while collecting data
with RSLinx 2.30.02.
1. Tags are added to the ControlLogix processor when online with RSLogix
5000:
RSLinx will detect that tags have been added to the ControlLogix processor, log
an event into the RSLinx communication event log, and then update the list of
available tags to include the newly added tags. Data collection stations can start
collecting data from the new tags without stopping the data collection project.
2. Tags are added to the ControlLogix processor by downloading an updated
program:
RSLinx will detect a download, log an event in the communication event log, and
refresh its list of available tags. Data collection will stop while a new program is
being downloaded and will resume when after the download. Data collection
stations can start collecting data from the new tags without stopping the data
collection project.
3. Tags are removed from the ControlLogix processor when online with
RSLogix 5000:
RSLinx will detect that tags have been removed from the ControlLogix processor,
log an event into the RSLinx communication event log, and then update the list of
available tags. All data collection projects should be stopped prior to making
these changes. Restart data collection after the tags are removed from the
ControlLogix processor. All items on scan while removing any tags from the
ControlLogix processor will cause all tags to stop updating until data collection
applications are restarted.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 14

4. Tags are removed from the ControlLogix processor by downloading an


updated program:
RSLinx will detect a download, log an event into the RSLinx communication
event log, and then update the list of available tags to no longer include the
removed tags. All data collection projects should be stopped prior to making these
changes. Restart data collection after the tags are removed from the ControlLogix
processor. All items on scan will stop updating after downloading a new program
into the ControlLogix processor that results in the removal of tags.
5. When the tags in the ControlLogix processor have their data types changed
or when alias tags are re-referenced:
All data collection projects should be stopped prior to making these changes.
Restart them after the data types of the tags in the ControlLogix processor have
changed. RSLinx cannot update this information while data collection is in
progress.
6. When arrayed tags in the ControlLogix processor are re-dimensioned in any
way:
All data collection projects should be stopped prior to making these changes.
Restart them after the data types of the tags in the ControlLogix processor have
changed. RSLinx cannot update this information while data collection is in
progress.
7. Changes of any kind to User Defined Types (UDTs) whether adding,
deleting, or modifying its members in the ControlLogix processor:
All data collection projects should be stopped prior to making these changes.
Restart them after the data types of the tags in the ControlLogix processor have
changed. RSLinx cannot update this information while data collection is in
progress.

Read Optimization
Read optimization allows many tags to be read from the ControlLogix processor in fewer
requests. This conserves valuable ControlLogix CPU and memory resources as well as
minimizing network traffic. Requests from data collection applications to RSLinx are
optimized down to a fewer number of requests from RSLinx to the ControlLogix. These
fewer requests are each ControlLogix Optimized Packets. Without optimization each tag
request from data collection applications would correspond to a request from RSLinx to
the ControlLogix.
There are a few different levels of optimization. Namely UDT, Array, and First Level or
Scattered. RSLinx determines the kind of optimization used when tags are put on scan.
The next few sections discuss the different types of optimization.
Array optimization
This kind of optimization grabs several elements of an array and treats them as one item
in the controller. The benefits of this kind of optimization are often reduced as HMI
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 15

clients typically must request array elements individually and not a range of elements at
one time. In other words to get the most out of this optimization reference elements of an
array like this: INTArray[0],L10. Instead of INTArray[0], INTArray[1],,INTArray[9].
If you are not able to use the L notation then array optimization will still occur between
the ControlLogix and RSLinx but there will be more resources used on the PC.
Requirements:
One dimensional array of BOOLS, SINTS, INTS, DINTS, or REALS.
There is no option to set in RSLinx. Array optimization happens automatically.
If the size of the array being requested exceeds 488 bytes then RSLinx will still
array optimize but just use more packets. Try to use tags like
Scenario:
INTArray[100] is defined. The following tags are requested: INTArray[0], INTArray
[20], and INTArray[90]. RSLinx will create a packet requesting all elements between
INTArray[0] and INTArray[90]. The ControlLogix will treat all of these array
elements as one item and one ControlLogix Optimized Packet will be used for
delivering these tags. If later on INTArray[60] is requested then RSLinx will already
have this on scan and no more overhead is needed to deliver the data.
Boolean Array Optimization
Starting with RSLinx 2.2 optimizations to Boolean arrays allow each individual Boolean
item as a single bit object, as opposed to a 32-bit object, as it had done previously. Using
this method, up to 3872 Booleans can fit into one ControlLogix Optimized Packet.
Previously, the maximum was 81 Booleans. When dealing with individual Boolean tags,
and not Boolean-array tags, the tags will still be treated 32-bit items, and only 81 items
will fit into a ControlLogix Optimized Packet.
UDT optimization
A UDT or User Defined Type is a custom data type in the ControlLogix processor. Users
create UDTs containing native data types like INTS, DINTS, FLOATS, other UDTs, and
etc. When elements of a UDT are requested from data collection applications and the
UDT Optimization option is enabled in RSLinx, RSLinx will grab the entire UDT
structure as one item from the ControlLogix processor. This reduces the ControlLogix
processors CPU and memory resources needed to serve up data. The more elements of
the UDTs that are used by data collection applications the better the performance. If a
minority of the UDT elements is on scan then it is inefficient for RSLinx to serve up the
entire UDT. In that scenario it would be wise to disable UDT optimization. UDT
optimization can be enabled or disabled for all ControlLogix processors/Topics. This
option cannot be set on a per topic basis. Here is how the option is set.
1. Open the CIP Options.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 16

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

RSLinx Configure CIP Options dialog


ControlLogix Data Collection with RSLinx
Version: 2.43

Page 17

UDT Optimization Requirements:


The above option must be enabled in RSLinx.
The UDT must be 480 bytes or less.
.
Some scenarios regarding UDT optimization:
1. A UDT is larger than 480 bytes:
RSLinx will not perform UDT optimization, just Scattered optimization.
2. A UDT contains arrays of SINTS, INTS, DINTS, or REALS:
RSLinx will perform UDT optimization and grab the whole structure. If the UDT is
greater than 480 bytes then array optimization will be performed on any arrays.
Scattered optimization will be performed on the remaining elements.
3. An array of UDTs:
RSLinx not will perform UDT optimization for each UDT element of the array.
4. A UDT contained in a UDT:
RSLinx will perform UDT optimization on the outer UDT providing that is less than 480
bytes.
First Level or Scattered Optimization
This is the default optimization that occurs when UDT or array optimization does not
apply. RSLinx will pack up to 480 bytes worth of tags into a ControlLogix Optimized
Packet. The tags are usually scattered throughout the memory of the ControlLogix
Processor. This type of optimization uses more ControlLogix CPU and memory than with
UDT or array optimization.
How much data can be read in a ControlLogix Optimized Packet?
This table outlines how many items of each native ControlLogix processor data type can
fit into a ControlLogix Optimized Packet. This data is accurate with RSLinx 2.2 and
greater.
Data Type

Max. Items that fit into a Read Packet

Boolean
Boolean Arrayed
SINT
SINT Arrayed
INT
INT Arrayed
DINT
DINT Arrayed
REAL
REAL Arrayed

81
3872
81
81
121
243
81
121
81
121
ControlLogix Data Collection with RSLinx

Version: 2.43

Page 18

Write Optimization
Write optimization enhances performance for batch or recipe downloads to the
ControlLogix processor. Often times the ControlLogix processor is so busy that write
requests occasionally time-out and the batch/recipe downloads fail. With write
optimization there will be fewer write requests generated from RSLinx to the
ControlLogix processor. Fewer write requests will reduce the work the ControlLogix
processor has to do to accept the batch/recipe downloads and will reduce the occurrence
of batch/recipe download failures.
Each write request from RSLinx to the ControlLogix processor is referred to as an
Optimized Network Write Packet. Before RSLinx 2.30.02 every single tag being written
to had to be sent in its own Optimized Network Write Packet. With write optimization
many tags being written to can be sent in fewer Optimized Network Write Packets. For
write optimization First Level or Scattered optimization is used for tags within the
ControlLogix processor that have little or no relation to each other. Write optimization
groups them together into as few Optimized Network Write Packets as possible.
Additionally, there is array optimization but no UDT optimization.
How to Use Write Optimization
The RSLinx topic communicating to the ControlLogix processor needs to have the
Optimize Poke Packets Option option enabled. See the Configuring RSLinx section for
details. Also, you should have ControlLogix firmware 10.x or higher.
Array optimization for writes
This is similar to array optimization for reads. Array elements can be optimized even
better as to allow more data to fit into an Optimized Network Write Packet. To take
advantage of array optimization, the array elements being written to must be contiguous
and the write must be issued as once command.
Boolean Arrays note that when using write optimization for Boolean arrays the L
specifier should not be used. Each array element should be individually referenced as a
separate tag.
How many tags can be sent in a write packet to the ControlLogix?
Data Type

Max. Items that fit into a Write Packet

Boolean
Boolean Arrayed
SINT
SINT Arrayed
INT
INT Arrayed
DINT
DINT Arrayed

32
32
32
460
30
230
26
115
ControlLogix Data Collection with RSLinx

Version: 2.43

Page 19

REAL
REAL Arrayed

26
115

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

RSLinx Smart Polling


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

How RSLinx Uses ControlLogix Connections


RSLinx uses connections, a dedicated communications pipe, when collecting data from a
ControlLogix. When reading data from a ControlLogix processor each ControlLogix
Optimized Packet makes use of a connection. It gets its connection from a pool of
connections that is shared by all ControlLogix Optimized Packets. The maximum number
of connections that are used in this pool is configurable but the default is four, which in
many cases is the optimal setting.
RSLinxs use of connections when writing data to the ControlLogix processor is different
then reads. When writing data to the ControlLogix processor it has the ability to use one
connection or none at all for all writes. If writes to the ControlLogix processor are very
frequent (within 32sec. by default) or continuous then you are better off using a
connection for writes. If you are sending data less frequently then you should not use a
connection for writes. For example, if you had a batch\recipe running every few minutes
you would be better off not using a connection for writes.
How to access the dialog for configuring the maximum number of read connections used
per ControlLogix and to enable/disable the use of connections for writes.
1. From the RSLinx main menu select CommunicationsConfigure CIP Options.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 20

2. Select the Connections for ControlLogix Processor tab.


3. The maximum number of read connections that RSLinx will use for each
ControlLogix is set here. Also the option for enabling/disabling connections for
writes is on this dialog.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 21

RSLinx Configure CIP Options dialog

Memory Consumption in the ControlLogix Processor


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

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)

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 22

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

1364 bytes

Perfect Array
Optimizations

1364 bytes

100 native tag


integers

No Array Optimizations

100

4532 bytes

Perfect Array
Optimizations

1560 bytes

500 native tag


integers

No Array Optimizations

500

22660 bytes

Perfect Array
Optimizations

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.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 23

Communication Event Log


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

Opening up the Communication Event Log from RSLinxs main menu


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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 24

RSLinxs Communication Event Log

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 25

Getting RSLinx Data into Applications


Logix5000 Tag Import Utility - Import ControlLogix Tags Into RSView
and RSSQL
Use the Logix5000 Tag Import utility to import ControlLogix tags from an L5K file into
RSView or RSSQL. The utility generates a csv file that RSView ME and RSView SE can
import from. It also generates a TSV file for RSSQL. RSView32 can import the tags
directly from the utility.
Download this utility and application note from Rockwell Softwares online
knowledgebase: A839 Logix 5000 Tag Import Utility for RSView32, RSView ME / SE
and RSSQL (RSView32)

Browsing and Selecting ControlLogix Tags


Another way of getting tags into applications is by browsing the available ControlLogix
tags and picking the tags of interest. The mechanism that allows this kind of support
RSView and RSSQL are examples of applications that support this OPCBrowse
interface. Note that you can browse the list of available tag online or offline.
Online - RSLinx directly queries the controller for a list of available tags.
Offline RSLinx queries an RSLogix 5000 .acd file. A topic must be configured to Use
Symbols with the .acd file associated with it. RSLogix 5000 will automatically create this
for you when you save a project. This feature requires RSLinx 2.3 SP1 and RSLogix
version 10 and higher.
Here is an example of browsing ControlLogix tags in RSView.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 26

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.

ControlLogix Data Collection with RSLinx


Version: 2.43

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.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 28

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.

Browsing ControlLogix tags in RSView

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 29

Miscellaneous RSLinx Features and Tips


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

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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 30

ControlLogix Data Monitor


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

RSWho pop-up menu for the ControlLogix processor

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 31

ControlLogix Data Monitor


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

RSLinxs Copy DDE/OPC link supports browsing ControlLogix Tags

Select Copy DDE/OPC Link from the RSLinx main menu

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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 32

Copy DDE/OPC Link dialog.

Getting Module Information 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 higher)
1. Use the mouse to right-click a ControlLogix processor in RSWho, to bring up the
following pop-up menu.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 33

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

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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 34

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

Put Tags on Scan at the Same Time


See tech notes from Rockwell Softwares online knowledgebase
A2062 ControlLogix communication packet optimization techniques and observations
(RSView32)

Changing ControlLogix Tags While On Scan


You may need to make a process for changing tags in the ControlLogix processor while
performing data collection. The actions that you must take depend on the changes that are
made. RSLinx uploads all of the ControlLogix tags and their data types when the first tag
gets put on scan. RSLinx uses this information to build the ControlLogix Optimized
Packets. If the tags in the ControlLogix change then RSLinx will have to upload the new
tag information. Here are the actions necessary when making changes to tags in a
ControlLogix processor.
Changing data types, array resizing, UDT definition changes or if tags are deleted
from the ControlLogix processor. This applies even if the tags are not on scan by
data collection applications.
1. Disconnect data collection applications from RSLinx. If connecting remotely via
RSLinx Gateway then disconnect all data collection stations. RSLinx does not
have to be shutdown and restarted. Computers do not have to be rebooted.
RSView for example has a node disable command that could be assigned to a
button or run as part of a script.
2. Restart the data collection applications after changes are made to the
ControlLogix processor.
If tags are added to the ControlLogix controller No data type changes or tag
deletions:
Option 1 (RSLinx 2.3 or later required)
1. Add tags offline in RSLogix 5000
2. Download the program into the ControlLogix
3. RSLinx will log an event to its Communication Event Log and upload the new tag
information automatically. Data collection stations will resume data collection
after download is complete.
Option 2 (RSLinx 2.3 or later required)
1. Add tags to the ControlLogix Processor online while collecting data.
2. Command RSLinx to re-upload ControlLogix tags. This is done in one of three
ways:
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 35

a. RSLinx will automatically detect changes and the re-upload the


ControlLogix tag information. RSLinx queries the ControlLogix Processor
for these changes every 20-30 seconds. An event will be logged to the
RSLinx Communication Event Log when changes are detected and
uploaded. (RSLinx 2.31 and later)
b. Perform a read on the predefined item @CLTagUpdateAddressSpace
c. Select the option from RSLinxs main menu under DDE/OPC

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 36

Redundant RSLinx Gateway Servers with RSViews NodeSwitch


Command
See tech notes from Rockwell Softwares online knowledgebase.
R679 RSView32 6.30.16 Patch for switching between OPC nodes (RSView32)

Redundancy for ControlLogix processors


There are a few options of incorporating redundancy at the ControlLogix level into your
data collection system.
Option 1: Use hardware redundancy. This option will only work if your data collection is
over ControlNet requires
Option 2: Use Alias Topics is RSLinx
Option 3: Use RSViews node switch command.
See tech note from Rockwell Softwares online knowledgebase
A952 Node Level Redundancy - A comparison of the Alias Topic and the NodeSwitch
Command (RSView32)

Using ControlLogix Strings


You must be at least RSLinx 2.3 and ControlLogix firmware 8.x to use strings.
RSLinx 2.31 and later
The addressing syntax for a ControlLogix string data type is just the tag name of the
string. So if I had a string named MyString You would address it as MyString in
your data collection application regardless of how many characters you want to read.
RSLinx will automatically update the length of the string in the ControlLogix processor
when writing a new value to the string.
Prior to RSLinx 2.31
The addressing syntax for a ControlLogix a string data type is StringTag.DATA,SC#
(where # is the number of characters). For example, if you had a string tag in the
ControlLogix processor named MyString you would use MyString.DATA,SC10 to
read the first ten characters of MyString..

Troubleshooting
Click here to get the troubleshooting guide from our support website. For reference here
is the link.
http://www.software.rockwell.com/download/comms/rslinx/controllogix data collection
troubleshooting guide.doc

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 37

Performance
Throughput vs. System Overhead Time Slice with a Continuous Task
Test setup:
One continuous task running in a 1756-5555 firmware 10.24.
5000 tags of type DINT were collected with the OPC test client. Update
Rate=1ms
ENBT on a 100MBPS switched network. Ethernet driver in RSLinx. The PC was
the only other node on the network.
DELL Optiplex GX260. 1.8Ghz
RSLinx 2.40.01
No motion or I/O was running
The test was run for three different organizations of tags. The tags were either scattered,
UDT optimized, or in Arrays. Here is an explanation of each.
Scattered means either one of three things.
1. Each tag was individually defined in the ControlLogix processor.
2. Tags were defined as elements in User Defined Types with the Optimize
User Defined Data Types disabled in RSLinx.
3. Tags were defined as elements in User Defined Types that were too large to
be optimized. (UDT>480 bytes)
Array All data was defined in one big array. The OPC test client put all 5000 tags on
scan at the same time to yield the best array optimization.
UDT 120 elements of type DINT were defined in UDTs. (480 byte UDT) Optimize
User Defined Data Types is enabled in RSLinx.
Tags per Second = (5000 Tags/Number of ControlLogix Optimized Packets from
RSLinx Server Diagnostics) * Packets per second from RSLinx driver diagnostics.

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 38

Time Slice Scattered


Tags Per
Second
10%
20%
30%
40%
50%
60%
70%
80%
90%

1270
2680
4070
5340
6620
7940
9190
10360
11530

UDTs
Tags per
Second

Arrays
Tags Per
Second

10400
21600
32500
42400
45000
45000
45000
45000
45000

10400
21700
32700
42700
45300
45300
45300
45300
45300

Performance vs. Time Slice


50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0

10

20

30

40

50

60

70

80

90

Time Slice (%)

Scattered
UDT
Array

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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 39

Throughput vs. Periodic Rate with a Periodic Task


Test Setup:
One periodic task running in a Logix5555 that takes 63 ms. to execute
5000 tags of type DINT were collected with the OPC test client. Update
Rate=1ms
ENBT on a 100MBPS switched network. Ethernet driver in RSLinx. The PC was
the only other node on the network.
DELL Optiplex GX260. 1.8Ghz
RSLinx 2.40.01
ControlLogix firmware 10.24
No motion or I/O was running
The test was run for two different organizations of tags. The tags were either scattered or
in Arrays. UDTs are not published here as results were similar to arrays.
Tags per Second = (5000 Items/Number of ControlLogix Optimized Packets from
RSLinx Server Diagnostics) * Packets per second from RSLinx driver diagnostics.
The periodic task for this test takes 63 ms to execute. To increase performance we have
to increase the Periodic Rate.

Periodic Items Per


Task Rate Second no
(ms)
arrays or
UDTs
260
64
1300
70
4840
100
8890
200
10250
300
10950
400
11350
500

Items Per
Second
Arrays
1450
7400
18450
30300
35700
37700
39600

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 40

Performance vs. Periodic Rate


45000
40000
35000
30000
25000
20000
15000
10000
5000
0

64

70 100 200 300 400 500

Scattered
Arrays

Periodic Rate

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

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 41

Throughput vs. System Overhead Time Slice and Periodic Rate with
a Continuous and a Periodic Task
This test uses both a continuous task and a Periodic task. The periodic takes 63ms to
execute.
Time Slice

10%
50%
90%
10%
50%
90%
10%
50%
90%
10%
50%
90%

Periodic
Rate of the
Periodic
Task
70
70
70
100
100
100
200
200
200
400
400
400

Maximum
Continuous
Task
Execution
Time (ms)
696
1,190
6,376
196
388
1,801
134
187
795
134
192
914

Scattered
Tags Per
Second

140
610
1150
480
1990
4230
860
2340
6600
1070
1960
7660

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

Processor Type vs. Performance


Test setup:
One continuous task running in a 1756-5555
5000 scattered tags of type DINT were collected with the OPC test client. Update
Rate=1ms
ENBT on a 100MBPS switched network. Ethernet driver in RSLinx. The PC was
the only other node on the network.
DELL Optiplex GX260. 1.8Ghz
RSLinx 2.40.01
ControlLogix firmware 10.xx
No motion or I/O was running
ControlLogix Data Collection with RSLinx
Version: 2.43

Page 42

Time Slice

Tags per second


(DINT) 5550

Tags per second


(DINT) 5555

Tags per
second
(DINT) 5563

10%
20%
30%
40%
50%
60%
70%
80%
90%

970
1970
2980
3920
4840
5850
6700
7570
8410

1270
2675
4070
5340
6620
7940
9190
10360
11532

4670
9540
14230
19300
20500
21050
21050
21050
21050

Performance vs. Processor Type

25000
20000
15000

5550
5555
5563

10000
5000
0
10

20

30 40

50

60

70 80

90

Time Slice (%)

ControlLogix Data Collection with RSLinx


Version: 2.43

Page 43

S-ar putea să vă placă și