CompactLogix Performance and Capacity

CompactLogix Performance and Capacity

The purpose of this document is to provide CompactLogix system performance and capacity information, along with design considerations, that can be used to achieve increased performance from a CompactLogix system. These recommendations may not be the best solution for all applications, but rather are guidelines and indications of performance.

CompactLogix Performance and Capacity Table of Contents

Section 1: Glossary of Terms3 Section 2: CompactLogix CPU Utilization (%CPU)- Baseline Testing................7 Section 3: CompactLogix System Basics8 Section 4: Local I/O (CompactBus I/O) Performance..12 Section 5: CompactBus RPI Effects on Program Execution...14 Section 6: Utilizing the Periodic Task and Minimum RPI to Obtain Fastest Possible Screw-to-Screw Performance: ....15 Section 7: Periodic and Event Based Tasks..16 Section 8: How System Overhead Time Slice Affects Tasks..18 Section 9: Limitations Imposed by Connections..23 Section 10: CompactLogix on Ethernet Performance..25 Section 11: CompactLogix on Ethernet: Connections and Packets Per Second.26 Section 12: CompactLogix Ethernet Messaging..31 Section 13:CompactLogix on ControlNet: Nominal System37 Section 14: CompactLogix on ControlNet: Connections.39 Section15: CompactLogix ControlNet Messaging42 Section 16: Bridging Through a CompactLogix Controller..49 Section 17: Other CompactLogix Configurations.50 Section18: Hardware and Firmware Differences in CompactLogix ..51 Appendix A: Table of Message Types (Connected vs Unconnected).. 52 Appendix B: Flex I/O vs. Point I/O Performance Comparison....53

CompactLogix Performance and Capacity

Section 1: Glossary of Terms Background Task: This happens during the System Overhead Time Slice. Communications, application messaging, I/O monitoring occur in this task. Buffer: A register or group of registers used for temporary storage of data. Logix has these three buffer types: Unconnected Outgoing, Unconnected Incoming and Cached. Cached- This term applies to ladder logic message instructions or messages to HMIs. These messages are always connected (use an available connection). Therefore, they will use resources such as buffers, bandwidth and memory even when the message is done or not executing. 32 cached buffers are available on both the CompactLogix ControlNet and Ethernet network ports. Class 1 (Implicit)- refers to any connection that uses an RPI (Requested Packet Interval). These include I/O and produce/consume connections. Another name for a class 1 message is implicit. Implicit refers to information (source address, data type, destination address, etc.) which is implied in the message but not contained in the message. Class 3 (Explicit) -refers to any connection that does not use an RPI. Class 3 connections are non time critical. Example: MSG instruction and program upload. Another name for a class 3 message is explicit. Explicit messages include basic information (source address, data type, destination address, etc.) in every message, hence they are explicit. Connected- A message that uses a connection buffer to transfer data to a device. Once the connection is established, buffers and resources will remain allocated to the message. The connection will remain open even if the data does not change. When data does change, data transfer rates are faster than unconnected messaging since the connection to the buffer has already been established. Connections- A connection is a communication path. Effectively, data passes through a connection. I/O, messaging, Produced/Consumed tags, RSLinx Connections to PCs or HMIs all use connections. The number of connections used in a Logix product must be considered since they take up buffers, resources and memory in both processors and network cards. Continuous Task- A task that runs through all its program and routines continuously, from top to bottom unless interrupted by another task. A project doe not require a continuous task, however you can only configure one per project. All CPU time not allocated to other operations such as motion,

CompactLogix Performance and Capacity communications and periodic or event based tasks, is used to execute the programs within this task. CPU Utilization (%CPU)- The CPU utilization (%CPU) is a representation of how much time the controller is having to perform the sum total of all its functions in the Continuous Task, including ladder execution, time slicing and communications. The lower the CPU%, the more logic, I/O and communications can be added. Direct Connection- A communication connection used to communicate to I/O in a remote chassis, typically analog modules. (Digital modules can also be configured for direct connections, but typically are configured for rack connections to conserve the number of connections used by the controller and network cards). Each module with a direct connection can be configured with its own RPI. Event Task- Is a user defined task that can run code based upon a trigger of a specific event. When the event is triggered it interrupts any lower priority tasks, executes one time, and returns control to the task that was interrupted, at the point it was interrupted. The trigger for the event based task can be: a change of a digital input a new sample of analog data a consumed tag an EVENT instruction certain motion operations Inhibit- Inhibiting a module causes the connection to the module to be broken, and may result in the loss of data. NUT -The Network Update Time is the smallest user configurable repetitive time cycle in milliseconds at which data can be sent on a ControlNet network. The range is 2 to 100 milliseconds and is configured in RSNetWorx for ControlNet. Periodic Task- Is a user defined task that can run code at a user defined time period. When the end of the time period defined by the user is reached, the task is triggered and interrupts any lower priority task (either continuous, periodic, or event). All programs assigned to that task are executed and scanned once, from top to bottom. After this single scan, an output update is triggered and control is returned to the tak that was interrupted, at the point it was interrupted. Up to 7 periodic tasks can be configured, each with a interrupt priority and with independent rates. (Execution rate range (.1ms-2,000,000ms, in increments of 1ms)).

CompactLogix Performance and Capacity Produced/Consumed- Type of data format. Each produced tag and each consumed tag uses a connection. With Produced/Consumed data multiple nodes can consume the same data at the same time from a single producer, resulting in more efficient use of bandwidth. Also, nodes can be synchronized. Benefits over Source/Destination methods: Highly Efficient- No wasted effort delivering data to those who do not care. Accurate Data - Everyone received the data at the same time. Deterministic - Length of time to deliver data is independent of the number of nodes Rack Connection- A communication connection a user may choose to use when using digital I/O in a remote chassis. A rack connection uses only one connection to the digital I/O in the remote chassis, economizing connections. A rack connection is available only to digital I/O. (Analog modules use direct connections.) Only one RPI value can be set to all the modules configured to use the rack connection. RPI- Requested Packet Interval - The requested rate of data arrival to or from a module and a controller. The data will be sent at least this often or the connection will fail with the Connection Not Scheduled Fault. This value is configured in the properties for each module when added to the module configuration tree. Scheduled Connection -allow you to send and to receive data repeatedly at a predetermined and configured rate on ControlNet. Produced/consumed tags, and scheduled I/O communication on ControlNet are scheduled connections A scheduled connection stays open as long as the network, the target, and the connection originator are alive. If either the target or originator drops off the link, then the connection is closed and periodically retried by the connection originator. System Overhead Time Slice-The system overhead time slice is the ratio of the amount of time spent running the continuous task versus the amount of time running the background task, which includes handling communication requests.

CompactLogix Performance and Capacity

Uncached- This terms applies to ladder logic message instructions. These messages use in a connection when starting the message and then closes the message when complete, therefore freeing up resources such as buffers, bandwidth and memory. Unconnected- A message that does not use a connection buffer to transfer data to a device, such as a UCMM. Unconnected messages can not be cached. Unscheduled Connection - are used when data is being produced on demand by the user program or HMI on ControlNet. MSG instructions and RSLinx message are examples that use unscheduled connections. Unscheduled connections can timeout if they are not used within the timeout interval. Network services will use an unconnected message to close the unscheduled connection

CompactLogix Performance and Capacity Section 2: CompactLogix CPU Utilization (%CPU)- Baseline Testing Since CompactLogix has one processor to handle multiple tasks such as I/O, network communications and messaging, the CPU Utilization (%CPU), has been used throughout this document as a mechanism to measure the load on the processor and to determine performance and capacity of the CompactLogix controller. Objective: A baseline program was written to determine the CPU utilization percentage using a cross section of instructions. The program used: 1200 discrete instruction (XIC, XIO, OTE) 50 counter instructions 50 timer instructions 50 multiple instructions 50 add instructions 100 move instructions 50 compare instructions 50 copy instructions 50 FIFO instructions (FFL) 12 JSR instructions From this program the CPU utilization (%CPU) was calculated. The %CPU is based on the number of times the baseline program is executed in 1 second. As the %CPU calculated increases this means the controller is having to perform more operations and is spending less time on ladder execution. A ladder program calculates the %CPU. This baseline program had the CompactBus Local I/O virtual backplane enabled with an RPI of 3ms, had no I/O or traffic configured for the 1769-L35CR ControlNet Port LocalCNB, had the System Overhead Time Slice (TS) set to 10%, and had no RS232 communications. The controller used was a 1769-L35CR processor. In a CompactLogix controller inhibiting the CompactBus Local I/O does not actually disable the scanning of the CompactBus so inhibiting it with a larger RPI uses less CPU than just inhibiting it alone. Test Results. The baseline results are: Memory used 89,232 bytes Memory Available 1,483,632 bytes Main Task Scan Times Max 4.982 ms Min 2.500 m %CPU processor used 1.0% (typical) Summary: This test provides a baseline of CompactLogix CPU usage that will be used as a comparison for the tests in this document. 7

CompactLogix Performance and Capacity

Section 3: CompactLogix System Basics CompactLogix is designed to provide a Logix solution for low-end to medium applications. Typically these applications are machine-level control applications that require limited I/O quantities and limited communications capabilities. The 1796-L31 has 2 serial ports. The 1769-L32C and 1769-L35CR has an integrated ControlNet port and 1 serial port. The 1769-L32E and1769-L35E controllers has an integrated EtherNet/IP port and 1 serial port.. Note- the first bank of I/O must contain the processor and it must be in the leftmost slot. Note- To validate your system, the total 5V dc current and 24V dc current consumed must be considered. The I/O modules must be distributed such that the current consumed from the left or right side of the power supply never exceeds 2.0A at 5V dc and 1.0A at 24Vdc. The power supply distance rating of all 1769 digital and analog I/O modules is 8 modules, allowing them to be placed up to 8 slots from the power supplyexceptions being specialty modules. Power Supply Distance Rating: 1769 Digital Modules 1769 Analog Modules 1769-HSC 1769-SM1 1769-SM2 1769-SDN 1769-ADN 1769-ASCII 8 modules 8 modules 4 modules 6 modules 4 modules 4 modules 5 modules 4 modules

CompactLogix Performance and Capacity 1769-L31 Controller:

Up to 3 banks of modules Supports: 16 I/O modules with up to 32 points per digital modules and 8 points per analog modules Mix and match any combination of discrete, analog and specialty modules Connect the banks with 1m or 1ft of cable Requires one power supply for each bank Has two RS-232 serial ports: Can be configured for ASCII, DH-485, DF1,ModBus, and Modems 512K Memory Removable compact flash to store programs, tag values and firmware Supports multiple DeviceNet modules

CompactLogix Performance and Capacity 1769-L32C and L35CR Controller:

Removable compact flash to store programs, tag values and firmware Multiple DeviceNet modules Mix and match any combination of discrete, analog and specialty modules Connect the banks with 1m or 1ft of cable Requires one power supply for each bank L32C supports: : 16 I/O modules with up to 32 points for Digital modules and 8 points for analog modules 750K Memory and a single ControlNet connector

L35CR supports: : 30 local modules with up to 32 points for Digital modules and 8 points for analog modules 1.5M Memory and redundant ControlNet connectors

10

CompactLogix Performance and Capacity 1769-L32E and L35E Controllerr:

Removable compact flash to store programs, tag values and firmware Multiple DeviceNet modules Mix and match any combination of discrete, analog and specialty modules Connect the banks with 1m or 1ft of cable Requires one power supply for each bank L32E: supports: 16 I/O modules with up to 32 points for Digital modules and 8 points for analog modules 750K Memory and a single EtherNet/IP port. L35E supports: 30 local modules with up to 32 points for Digital modules and 8 points for analog modules 1.5M Memory and a single Ethernet/IP port.

11

CompactLogix Performance and Capacity Section 4: Local I/O (CompactBus I/O) Performance As you install modules, the minimum backplane RPI increases to handle larger amounts of data going across the backplane. The CompactBus local RPI (Requested Packed Interval) defines the frequency at which the controller sends and receives all I/O data on the backplane. *There is one RPI for the entire 1769 backplane. *(Release of 1769-L4x processor, individual RPIs for local modules will be supported).

This setting can be found in the local CompactBus Properties.

This value range is (1-750ms). Default is 2ms for V15 of RSLogix5000 or earlier Default is 5 ms in V16 of RSLogix5000.

12

CompactLogix Performance and Capacity Minimum settings for the CompactBus local RPI: These numbers are minimum (fastest) RPI settings. Depending on how much communications, program processing, I/O, a higher RPI may be needed. (See Section 5).

*Digital and Analog (any mix):

1-4 modules can be scanned in 1.0ms 5-16 modules can be scanned in 1.5ms 17-30 modules can be scanned in 2.0ms

1769-HSC (High Speed Counter): Add 0.5ms for each used 1769-SDN (DeviceNet Scanner): Add 1.5ms per module

*Input modules defined with a F , ie 1769-IQ16F, at the end of the catalog number have user selectable filters that can be configured for faster filter rates (0.0msec- 2.0ms) and can provide faster throughput times. Those modules without the F have fixed 8ms filters, that is new data will only be transmitted every 8ms, even if the RPI is set lower. Note: These considerations show how fast modules can be scanned - not how fast an application can use the data. The RPI is asynchronous to the program scan. Other factors, such as program execution duration, affect I/O throughput. You can always select an RPI that is slower than your calculated minimum RPI The RPI rule is a conservative benchmark. A RPI set below the recommended may result in task overruns and unpredictable I/O update behavior Caution: When using the default RPI of 2ms (in v15 or earlier) be cautious going over 8 modules to assure that you do not slow down your program execution too much for your particular application.(see Section 5.)

13

CompactLogix Performance and Capacity

Section 5: CompactBus RPI Effects on Program Execution The CPU utilization (%CPU) is a representation of the load on the processor. It takes into account how much time the controller is having to perform its functions in the Continuous Task, including ladder execution, time slicing and communications. The lower the CPU%, the more logic, I/O and communications can be added. Too high a CPU%, then messaging, HMI communications, uploads and downloads may be slowed. The %CPU increases as modules are added to the CompactBus, and slower RPIs need to be considered for your particular application. Guideline: Set the RPI greater than 5ms if you want the CompactBus I/O to have the least affect on messaging/HMI/upload and downloads. (Even if you are using no modules and inhibit the CompactBus, set the RPI to 5ms to achieve the best utilization.)

Test: Effects of RPI on CPU Utilization for 1769-L35CR

RPI Effects on % CPU
60

50

CPU Utilization

40

No Modules 2 Modules 4 Modules 8 Modules 30 modules

30

20

10

0 1ms 2ms 3ms 4ms RPI 5ms 10ms 15ms 20ms

(The above chart is only for the Local CompactBus I/O only. See Baseline test used for this document).

14

CompactLogix Performance and Capacity

Section 6: Utilizing the Periodic Task and Minimum RPI to Obtain Fastest Possible Screw-to-Screw Performance: Some applications require not only a fast screw-to-screw update but also need to know screw-to-screw repeatability also known as Screw-to-Screw Jitter Our backplane scan is asynchronous to the program execution. I/O updates can happen anytime throughout the program scan. Guideline: With 4 or less non-specialty modules, the system can handle a 1ms RPI and 1ms Periodic Task: -Average screw-to-screw performance is 2ms -Repeatability or Screw-to-Screw Jitter is 3ms or less

Throughput test of 1769-IQ16F/A module:

Task Continuous Priority 16 Throughput Worse/Best 2.1ms / 1.0ms Main Task Scan Time Max/Min 2.5ms / .04ms

(Test used: Only the local CompactBus used with a 1769-IQ16F/A input module and a 1769-OB16/B output module. RPI was set to 1ms. 100 samples taken of input turning on an output.) Caution: It is possible to starve the update of your I/O if you set the priority of a Periodic task higher than the Local CompactBus priority of 6. Higher priority tasks interrupt lower tasks.

Note-Your minimum screw-to-screw performance will suffer as you add more modules and/or specialty modules to your system

15

CompactLogix Performance and Capacity

Section 7: Periodic and Event Based Tasks When a project is created in RSLogix5000, the Continuous Task is automatically created, called the Main Task. Only one Continuous task is supported in the software.

Optional Periodic and Event based tasks can be created by the user by right clicking on Task and choosing New task.

The priorities the user selects for Periodic/Event Task can affect both I/O throughput and program scan. The user needs to determine what is more important for his application and adjust the priorities accordingly. Note- Use of a periodic/event task will interrupt any programs in the Continuous task, therefore affecting their program scan. Setting the Periodic task higher (05) than Local I/O Compact Bus of 6, may cause the I/O throughput to be slowed down?

16

CompactLogix Performance and Capacity Logix Priority Task Levels: Priority level: 1- highest 17 lowest Priority Comments Up to 7 periodic tasks can configured I/O scan performed at RPI rate Scheduled I/O, produced/consumed data Only one Continuous Task is supported Unscheduled messaging

Task

Periodic Task (Ladder) *(1-15) Local CompactBus (I/O) 6 NetLinx Class 1 messaging 6 Continuous Task (Ladder) 16 NetLinx Class 3 17 Other Communications 17

* The only priorities that can be changed by the user are the priority numbers of the Periodic tasks.

Guideline: If your application requires a high amount of communications, only have a maximum of 1 Periodic Task configured and have its priority set to 7 or above. This will avoid the Periodic Task interrupting the CompactBus I/O scan running at priority level 6. Be sure to set the period time larger than the Periodic Tasks execution time and have a 30% null time to be able to service your communications once the task execution is complete.

Test: Effects of Changing Priorities of Periodic Task: Throughput Main Task Scan Time Worse/Best Max/Min 11.2ms / 0.9ms 3.7ms / 3.2ms 11.6ms / 1.6ms 2.9ms / 2.3ms 13.9ms / 4.2ms 2.5ms/ 2.1ms

Task Periodic Periodic Periodic

Priority 15 6 1

This test was based on the baseline program. This time the Main Task, which was Continuous, was now made Periodic with a priority of 6, the same priority as the local CompactBus I/O updates. The Main Periodic Task was run at a rate of 10 ms. Only the Local CompactBus was used, with two modules configured a 1769-IQ16F/A with all filters set to 0ms and a 1769-OB16/B both configured for rack-optimized connections at 1ms. Caution: We do not recommend going below a 1ms Periodic Task. Setting the periodic task below 1ms may produce excessive task overlaps.

17

CompactLogix Performance and Capacity Section 8: How System Overhead Time Slice Affects Tasks The system overhead time slice is the ratio of the amount of time spent running the continuous task versus the amount of time running the background task, which includes handling communication requests. Increasing the time slice will interrupt the continuous task to allow for more backround time to communicate to HMIs, perform trending, execute messaging and perform serial port communications. Setting too low can starve your communications to HMI, trending, messaging and serial communications. The time slice is based on a 1 millisecond tick rate for the background task. Example 1: The project consists of just one continuous task. There are no periodic tasks or motion. TS is set to the default of 10%. For each 1 msec of background time, the continuous task runs for 9 ms.

Continuous Task Background Task 0 1 2 3 4

CT

CT

BT

BT

10 11 12 13 14 15 16 17 18 19 20

Time (ms)

Figure 1

The continuous task executes for 9 of every 10 ms, and the background task executes every 10 ms. Example 2: The project consists of just one continuous task. There are no periodic tasks or motion. TS is set to 20%.
Continuous Task Background Task 0 1 2 3 4
CT CT CT CT

BT

BT

BT

BT

10 11 12 13 14 15 16 17 18 19 20

Time (ms)

Figure 2

18

CompactLogix Performance and Capacity The continuous task executes for 4 of every 5 ms, and the background task executes every 5 ms.

For RSLogix the default is set to 20% and can be changes in the Properties of the Controller.

1 The formula used for calculating the time slice is TS % = 100 , which CT + 1 100 means that CT = 1 , where TS% is the time slice in per cent, and CT is TS % the amount of time spent running the continuous task.
Note this is not the time to scan the Continuous task from top to bottom. Many scans of the continuous task may occur during this time, or only a partial scan of the task may occur. It is simply the amount of time spent executing the continuous task. Since the time allocated to running the background task is fixed at 1 ms, the processor adjusts the continuous tasks time to meet the time slice constraint. This setting only applies to the continuous task in a project. The background task may be further delayed due to any periodic or motions task interruptions also.

19

CompactLogix Performance and Capacity Example 3: The project consists of one continuous task and a periodic task with an interval of 2 ms, and a scan time of 1 ms. TS is set to 10%.
Continuous Task Background Task Periodic Task 0 1 2
2 3 4 5 6 7 8 9 1

BT

PT

PT

PT

PT

PT

PT

PT

PT

PT

10 11 12 13 14 15 16 17 18 19 20

Time (ms)

Figure 3

The numbers in the continuous task line are the accumulated processor time for the continuous task at the end of the tick. Both the continuous and background tasks are interrupted by the periodic task. The TS setting still means that the continuous task has to run for a certain number of ms before the background task can run. So, here, the background task doesnt get run until almost 20 ms have elapsed overall and every 20 ms after that, but that is still after just 9 ms of continuous task execution, given the 10% TS setting. Remember that the TS% is a ratio between the continuous task and background task running times, not between the absolute system time and the background task time. Therefore, as the continuous task gets interrupted by periodic tasks, the time between background task updates will increase. The final kind of task that we will consider is the motion task. It has the highest priority, so it will interrupt periodic, continuous and background tasks. The period at which the motion task runs is governed by the coarse update rate (CUR). As a rule of thumb, assume about ms per axis for the actual calculations. Lets see how it affects the previous setup.

20

CompactLogix Performance and Capacity

Example 4: The project consists of one continuous task and a periodic task with an interval of 2 ms, and a scan time of 1 ms. TS is set to 10%. There are 4 axes of motion with the L4x processor, with a CUR of 5 ms, and about 2.5 ms of calculation time ( ms per axis * 5 axes).
CT CT CT CT

Continuous Task Background Task

1
Periodic Task Motion Task
MT PT PT

2
PT

3
PT PT PT

MT

MT

MT

10 11 12 13

14 15 16 17 18 19 20

Time (ms)

Figure 4

The periodic task set to run at 2 ms was delayed by 0.5 ms due to the motion task running. The periodic task set to run at 6 ms was delayed by 1.5 ms due to the motion task running. This caused the task to overlap with the 8 ms start of the next occurrence. An overlap error will be generated and the 8 ms occurrence will be missed. The periodic task set to run at 10 ms was delayed by 2.5 ms due to the motion task running. This caused the start of the task to overlap with the 12 ms start of the next occurrence. An overlap error will be generated and the 10 ms occurrence will be missed. The task set to run at 12 ms is delayed by 0.5 ms due to the motion task running. With motion added, by the end of our sample 20 ms run, the continuous task has only accumulated 4 ms of run time, and the background task has not run at all! Extrapolating, it will take about 45 ms before the background task gets to run. Another thing to note is that the 2 ms task does not actually run at 2 ms intervals. In some cases it gets delayed, and in other cases it does not run at all due to an overlap condition with the previous interval.

21

CompactLogix Performance and Capacity Note-If there is no continuous task, the time slice setting has no effect. All processor time not used for other tasks will be used for background operations. Caution: Setting the System Overhead Time Slice above 35% starts to reach the threshold of diminishing returns whereas the tasks start to switch back and forth to often, and no task finishes its scan in a timely fashion. A finite amount of time is also used for switching between tasks.

22

CompactLogix Performance and Capacity Section 9: Limitations Imposed by Connections You indirectly determine the number of connections that the Logix controller requires by configuring the controller to communicate with other devices in the system. The CompactlLogix system uses a connection to establish a communication link between two devices. This includes controllers, communication modules, input/output modules, produced/consumed tags and messages. Each module in the CompactLogix system supports a limited number of active connections. Take these connection limits into account when designing your system.
Device Total Number of Connections Total Number of Connected/Cached Buffers Total Number of Unconnected/Uncached Buffers 3 fixed incoming/ 10-40 expandable outgoing 32

1769 L3x Controller **ControlNet port **Ethernet port

100 *32 32

32 32

*(supports any combination of scheduled, unscheduled, cached or uncached) ** (Each of these connections must be subtracted from the 100 total controller connections) Example: To determine the total number of connections used on a NetLinx daughter card use the following: 1. 2. 3. 4. 5. Count the number of produced tags Count the number of consumers for each produced tag Count the number of direct I/O connections Count the number of rack optimized connections Count the number of messages incoming or outgoing 6. Count the number of programming terminals online and the number of RSLinx packages browsing over the network 7. Count the number of HMIs polling controller (typically 5 connections per HMI are used) ______ ______ ______ ______ ______ ______ ______

To get the total number of connections used on the NetLinx daughter card (out of 32) in your controller: Add the individual results from steps 1 thru 7 Total Connections used by NetLinx daughter card ______

23

CompactLogix Performance and Capacity Note: It is not recommended to use all 32 connections on the built in Network ports. Caution: Although Connections impose limitations on the capacity of the system, other factors impose limitations, as well: For example, when using Ethernet, packets per second capability of the modules needs to be taken into account. When using ControlNet, NUT and RPI need to be taken into account. %CPU is another factor. See Network sections for more information.

24

CompactLogix Performance and Capacity Section 10: CompactLogix on Ethernet Performance Two CompactLogix processor have built-in Ethernet/IP ports, the 1769-L32E and 1769-L35E. : A Nominal CompactLogix on Ethernet system can be comprised of: 7 chassis of discrete I/O in 20ms 7 analog modules in any chassis in 80ms 7 drives at 40ms I/O cards in local chassis in 5ms PV+, HMI and programming terminal CompactLogix EtherNet/IP Capacity and Performance 10/100 Megabits per Second, Full Duplex Up to 4000 packets per second (Class 1, I/O, produced/consumed data) Up to 32 simultaneous CIP connections 2 millisecond minimum RPI 512 Byte maximum packet size

EtherNet/IP Rules and Guidelines: As the packet size increases the number of connections per second decreases. Producer/Consumer packets tend to be much larger than I/O packets and may reduce the maximum connections per second If all packets are completely full (512 bytes) the maximum connections per second count is reduced to around 2600 Performance is based upon: 1) Identifying and counting the number of connections 2) Calculating the Packets Per Second for loading 3) Estimating Maximum Input and Output times

25

CompactLogix Performance and Capacity Section 11: CompactLogix on Ethernet: Connections and Packets Per Second Digital I/O (rack optimized connection), each analog module (direct connection) and each produced and each consumed tag each require a connection. 32 Max connections supported on by L3x Ethernet port. Note, there is a limit to how many connections the controller can have for a given RPI. As the RPI in increased, the number connections supported also increases. Test: Effects of RPI and Number Ethernet Connections for 1769-L32E Ethernet I/O Connections
35 30 25 Supported Connections 20 15 10 5 0 3ms 5ms 10ms RPI of All Connections 16ms 26ms

MAX Connections Recommended Connections

(Baseline program used with Ethernet I/O in the form of 1794-AENTs containing two discrete modules in a rack optimized connection with a size of 2. Local Compact Bus RPI set to 3ms. All Ethernet traffic was 100Mbps full duplex.)

Test Results: Effects of RPI and Number Ethernet Connections for 1769-L32E
Typical RPI*** of all Connections Maximum Recommended

ThruPut**

ENetPort CPU% 84% 86% 86% 85% #Conn 5 10 20 32

ENetPort CPU% 61% 64% 72% 70% 73% #Conn 3 7 15 23 32

4-12ms 9-14ms 8-23ms 12-36ms 15-42ms

3ms 5ms 10ms 16ms 26ms

26

CompactLogix Performance and Capacity

Guidelines: It is recommended that for most applications, all I/O RPIs be set to 3ms or greater, the CompactBus RPI set to 5ms, System Overhead Time Slice set to 30% or greater and keep the Ethernet port CPU% under 70% when only Class 1 connections are active. It is recommended to choose the number of connections where the ENet Port CPU% stays below 70%, as measured in the 1769-L3x web page.

If you are using a Periodic task, set the priority appropriately (7-15),as not to starve the Ethernet I/O communications , in the NetLinx Class 1 connection task. Caution: If the ENet Port CPU% exceeds 100%, the connection will fail with Error (Code 16#302) Connection Request Error: Out of communication bandwidth.

27

CompactLogix Performance and Capacity Packets Per Second: The maximum number of packets per second for a 1769 Ethernet controller is 4000 pps. Bandwidth should be allocated as follows: Reserve 10% of the Ethernet controllers bandwidth to allow for processing of Class 1 messages (I/O and Produced/Consumed tags.) The total for Class 3 messages (messaging, HMI, upload/download) should not exceed 90% for the EtherNet I/P interface A CIP connections is bidirectional and requires a minimum of 2 packets per RPI. Using 2 packets/RPI/connection, the number of packets/second to or from each EtherNet/IP controller can be calculated as follows: A. Rack Optimized: Packets/Second= (2 x connections)/RPI B. Direct Connection: Packets/Second = (2 x connections)/RPI C. Produced Tag: producer and all consumers are in different chassis and are operating at a uniform RPI): At Producer: Packets/Second = (1+ connections)/RPI for each produced tag At Consumer: Packets/Second = 2/RPI for each consumed tag Total Packets Per Second is the sum of the above and should not exceed the recommended 90% packets/second, 3600 pps for CompactLogix.

28

CompactLogix Performance and Capacity

Table: Packets Per Second for Various RPI and Connections Combinations
Connections 5 5 5 5 5 5 5 5 5 5 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 30 RPI (ms) 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 20.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 20.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 12.0 18.0 PPS 5,000 3,333 2,500 2,000 1,667 1,429 1,250 1,111 1,000 500 10,000 6,667 5,000 4,000 3,333 2,857 2,500 2,222 2,000 1,000 20,000 13,333 10,000 8,000 6,667 5,714 5,000 4,444 4,000 3,333 3,333 Fastest RPI Exceeds PPS limit 5 connections at 3ms

Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds 90% Recommendation 10 connections at 6ms

Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds PPS limit Exceeds 90% Recommendation 20 connections at 12ms 30 connecitons at 18ms

Estimate the Fastest RPI: The fastest RPI for an EtherNet/IP interface is: RPI = (2 x connections)/pps Example 1: The 1769_L35E supports 4000 pps. If there are only four connections that are all at the same RPI, the fastest RPI is: RPI(Fastest) = (2 x 4)/4000 = 2.0 ms

29

CompactLogix Performance and Capacity Example 2: Assume there are three connections already running at an RPI of 2 ms on a 1769_L35E. These connections are already using some of the communication packets: pps = (2x3)/2 ms = 3000 pps The fastest RPI possible for a fourth connection is: RPI(Fastest) for 4th connection = (2 x 1)/(4000-3000) = 2 ms The same concept can be used for produced tags and consumed tags by replacing the (2 x connections) with (1 + connections) for produced tags or (2/RPI) for consumed tags.

Estimate maximum input or output times for CIP connections System response is dependent on several factors. The dominant factors are RPI and the number of Class 1 connections. To simplify, the response time of a connection can be approximated with only the RPI. The maximum input (I/O to controller) or output (controller to I/O) times for Class 1connections can be estimated as follows. A. Rack Optimized: 1 RPI B Direct Connect: Discrete: 1 RPI Analog (non-isolated): 2 RTS Analog (isolated): 1 RTS C. Produced/Consumed Tag: 1 RPI With this approximation, the error will be less than 10% if the RPI (in milliseconds) is at least 10 times the number of connections through the EtherNet/IP interface.

30

CompactLogix Performance and Capacity Section 12: CompactLogix Ethernet Messaging Explicit Ethernet Messaging Performance When performing only messaging across Ethernet there are Pros and Cons of adding modules into the module configuration. Pros: Provides visual overview of the network Provides status on the modules of the I/O tree Makes it easier to use a MSG instruction by allowing you to browse to your destination during development (see Browse button in MSG Instruction.)

Cons Creates additional traffic on the network because a Ping is regularly sent to the destination module. The traffic generated uses unconnected messaging and will use some of the unconnected message buffers on the processor. The Pings will occupy the Ethernet ports unconnected buffers (When using messages Instructions to devices in tree no ping occurs to that device. Also, CompactBus local I/O does not use buffers,)

31

CompactLogix Performance and Capacity

Guidelines: Place the modules in the I/O Tree but inhibit them. This will give a visual representation of the network, allow you to browse to the destination of MSG instruction, but will not generate any Pings. All inhibited modules will have a yellow information circle indicating it is inhibited and no connection will be established to them.

Leave the I/O tree empty and type the path into the MSG instruction manually, ie. 1,1,2,5,1,5. This will not generate any additional traffic, but the status of remote modules will be unavailable and the user must understand the Rockwell path convention. 1, to the backplane o #, across the backplane to the slot number of module o 2 (or 3 if 2 ports on the front), out the front of the module to the network o #, address of next module

When configuring a ladder message in Logix, the user may or may not have the availability to cache a message, depending on the type of message being configured.

32

CompactLogix Performance and Capacity

Both use a connection, however cached messaging continues to use the connection, even when the message is completed, tying up buffers and resources. Uncached messages open a connection and then close the connection once the message is completed, freeing up the resources and buffers. Cached message performance is faster, since the connection is already established, where as the uncached message needs time to re-open the connection. Use cached messaging when sending data often, more than once every 30 sec. uncached when sending data infrequently. Note: It is recommended to always use a connected message if possible, they will be faster and more efficient. However, the user may need to choose unconnected messaging if the connection limitation of 32 connections is reached for the network interface.

Cached Messaging: The number of cached messages used has little impact on the Program scan. You can expect the time to complete a message to increase as more cached messages are executed. About 1K of memory is used for each cached message. Caution: As the Enet port CPU% ramps close to 100%, measured in the 1769-L32 web page, it may create excessive time for UCMM messages to complete. UCMM messages are used to open I/O connections. Note, all open I/O connections will continue to operate- however, when trying to establish new I/O connections may take an excessive amount of time

33

CompactLogix Performance and Capacity

UnCached Messaging: Only a total of 6 uncached messages are supported simultaneously do to impact on the Enet Port CPU%. Uncached messaging has little effect on program scan time. Time to complete an uncached message is about twice as slow as cached messaging. Caution: DO NOT run with the ENET Port %CPU at 100%.

Test: Effects of Cached and Uncached Messaging on Program Scan and Message Completion for 1769-L32E
Ethernet Messaging Performance
140 X 120 100 Tim e (m s) 80 60 40 20 X 0 6 12 18 Cached Messages 24 30 Avg Program Scan - Cached Avg MSG Completion- Cached Avg Program Scan-Uncached Avg MSG Completion- Uncached

(Baseline test used with 1769-L32E and five 1756-L55/1756-ENBT pairs. 30 messages sent to and 30 from CompactLogix to other controllers consisting of 100 element DINT array. No class 1 messages and outgoing buffers set to 40.)

34

CompactLogix Performance and Capacity Test Results: Effects of Cached Messaging on Program Scan and Message Completion for 1769-L32E
Total # of CACHED MSGs Executing L35CR Prog Scan Time (AVG) 4 5 6 7 8 L32E ENet Port %CPU L32E PLC %CPU Typical L32E MSG DN Time (AVG) 40 40 65 80 120 Memory Used in the L32E

6 12 18 * 24* 30*

16-50% 70-93% 100% 100% 100%

33% 43% 45% 44% 44%

179,309 188,886 195,716 203,824 212,132

*Not Recommended since Enet Port CPU% increases to 100%

Test Results: Effects of UnCached Messaging on Program Scan and Message Completion for
1769-L32E Total # of UNCACHED MSGs Executing L35CR Prog Scan Time (AVG) 5 L32E ENet Port %CPU L32E PLC %CPU Typical L32E MSG DN Time (AVG) 110ms Memory Used in the L32E

90-98%

37%

190K195K

Effects of Mixing Ethernet I/O with Explicit Cached Messaging Ethernet I/O traffic is not affected by the addition of explicit messaging. However, the number of explicit messages is limited by the I/O traffic. Caution: With both the I/O connections and explicit traffic active you must keep the ENET port %CPU under 100%, measured in the 1769-L32 web page.

35

CompactLogix Performance and Capacity Test: Effects of Mixing Cached Ethernet Messaging with Ethernet I/O on a 1769-L32E.
Message Performance with Addition of Ethernet I/O
120

100

80 Number of Explicit Cached MSG 60 AVG Enet Port %CPU AVG MSG DN Time (ms) 40

20

0 2 4 Number of I/O Connections 6

(Base test used with rack optimized connections to Flex adapter with IB16 and OB16 with RPI=5ms and messaging to five 1756-L55/1756-ENBT pairs. 30 messages sent to and 30 from CompactLogix to other controllers consisting of 100 element DINT array.)

Test Results: Effects of Mixing Cached Ethernet Messaging with Ethernet I/O on a 1769-L32E
Number of I/O Conn L32E ENet Port %CPU WITHOUT Explicit MSG 2 4 6 36% 50% 75% Approx MAX Number of Explicit Cached MSG 8 6 4 L32E ENet Port %CPU WITH Explicit MSG Typical L32E MSG DN Time

65-95% 90-100% 100%

30-60ms 30-60ms 50-60ms

36

CompactLogix Performance and Capacity Section 13:CompactLogix on ControlNet: Nominal System Scheduled devices on the ControlNet Network should have RPI update rates that correspond to the type of data being transferred. Typically, Digital I/O has the fastest update rate and analog I/O has the lowest scheduled update rate Recommend using the following RPIs based on the type of device used: Analog I/O 80ms RPI Produced / Consumed Tags 40ms RPI PowerFlex Drives 40ms RPI

Nominal System - CompactLogix

16 Scheduled Connections 16 Unscheduled Connections 10 ms NUT < 70% CNET CPU Utilization
Scheduled Connections

...

Unscheduled Connections

1 scheduled connection per Drive ( 3 total scheduled connections) 40ms RPI

1 connection for each produced tag (array) 1 connection for each consumed tag (array) ( 4 total scheduled connections) 40ms RPI

Nominal System: 9 connections for I/O 3 Connections for Drives 4 Connections for P/C --------------------------------16 scheduled connect. 16 connections remain for unscheduled devices, i.e.

10ms RPI Digital 80ms RPI Analog 3 scheduled connections per Bank ( 9 total scheduled connections)

- Panelview Plus - Explicit Messages - RSLogix 5000

Each Bank has 6 digital and 2 analog module

37

CompactLogix Performance and Capacity The Nominal System is NOT the Maximum system configuration: Nominal System: Shows a typical small automation application. Shows a configuration that is Guaranteed to work with NO performance or communication bandwidth issues, such as lost connections, missed updates, or slower than expected unscheduled packet updates Shows a Typical Network update time (10ms) that fits a majority of customer application needs. Faster Digital I/O RPI can be obtained, -by compensating one of the other factors: Slow down the RPIs on the other non-critical devices Substitute some scheduled connections for unscheduled connections This Nominal System has Room to Grow: Our testing showed that at 70% or better ControlNet CPU utilization for scheduled connections the system was extremely stable. 70% scheduled utilization provides enough overhead to easily handle large amounts of unscheduled data Simple rule: the more scheduled connections you add the higher the RPI should be set. Always try to stay within 70% ControlNet CPU utilization for the most stable system. CompactLogix ControlNet Controllers: 1769-L32C User Memory Local I/O Modules 750K 16 Local I/O 1769-L35CR 1.5 Meg 30 Local I/O 1 ms RPI Coaxial (BNC) 32 Max Yes (2 BNC)

Minimum Local RPI 1 ms RPI ControlNet Media Coaxial (BNC)

ControlNet 32 Max Connections Media Redundancy No (1 BNC) Setting ControlNet Node Address

Rotary Switch or Rotary Switch or software software selectable selectable The L32C and L35CR have the same processing and I/O performance. The only differences are: Memory, Local I/O, and Redundant ControlNet Media

38

CompactLogix Performance and Capacity

Section 14: CompactLogix on ControlNet: Connections The L3x ControlNet interface supports up to 32 Max connections. There is a trade-off between the maximum number of connections that can be handled and the update rate or performance of the individual devices. (As connections are added, the update rate (RPI) needs to be increased to assure that the ControlNet Interface CPU is not over utilized.) Network Update Times (NUT), above 4ms, has very little effect on ControlNet Interface CPU Utilization. RPI must be equal to or greater than the NUT

As the NUT is increased so is the number of connections supported. There is a limit to how many scheduled connections the controller can handle for a given NUT/RPI combination. Test: Number of connections supported by various NUT/RPI settings on1796L35CR
Number of ControlNet Connections
35 30 Number of Connections 25 20 15 10 5 0 2ms 2ms 3ms 3ms 5ms 5ms 10ms 5ms 10ms 10ms 12ms 12ms 14ms 14ms 20ms 5ms 64ms 4ms RPI NUT Max# of Connections Recommended #of Connections

Baseline program with 1794-ACNR with 2 discrete modules in Rack Optimized connection with size of 2. Local CompactBus was inhibited with RPI set to 3ms.

39

CompactLogix Performance and Capacity

Test Results: Number of connections supported by various NUT/RPI settings on1796-L35CR Maximum RPI of Typical Throughput NUT Connections CNET Port CPU% 9-15ms 2ms 2ms 78% 14-19ms 3ms 3ms 82% 14-24ms 5ms 5ms 86% 20-38ms 5ms 10ms 90% 24-44ms 10ms 10ms 88% 28-46ms 12ms 12ms 95% 32-48ms 14ms 14ms 85% 24-56ms 5ms 20ms 86% 70-129ms 4ms 64ms* *32 max connections for ControlNet port. # Connections 1 2 4 9 9 12 12 16 Recommended CNET Port CPU% # Connections 34% 0 60% 1 70% 3 69% 6 64% 6 68% 8 71% 10 69% 12 67% 31

Guidelines: It is recommended that the Local ControlNet Port %CPU, as measured in RSLinx, under Module Statistics, should never go above 70% when only scheduled connections are active.

It is recommended that for most typical applications the NUT be set to 4ms or greater, the CompactBus RPI set to 5ms or greater, the System Overhead Time Slice be set at 30% or greater and you keep the ControlNet port CPU% under 70% with only scheduled connections active. Tip: To determine worse case throughput use: Throughput= (2*NUT) +(2*RPI of module)+(2*Program Scan)

Note: The Local I/O is not burdened by the ControlNet connections

Recommendations: 1) If your application requires some I/O to updated faster than the typical I/O, consider putting this I/O on the local 1769 bus. This bus offers a 1ms I/O update RPI. 2) Always reserve some connections (2 or more) for network overhead, such and Programming using RSLogix5000, OPC topics, and data monitoring. 3) Reduce the total number of unscheduled connections, i.e. MSG instructions by using an array of tags rather than individual tags. 4) Setup banks of all digital distributed I/O as Rack Optimized

40

CompactLogix Performance and Capacity Banks of all Digital I/O setup as rack optimized only consume (1) connection per bank instead of (1) connection per module

5) If sharing Produce/Consumed data between a ControlLogix and CompactLogix. Setup the ControlLogix as the data Producer and the CompactLogix as the Consumer when ever possible Producer Controllers use (1) connection for every consumer ControlLogix 1756-CNB has more connections to use

41

CompactLogix Performance and Capacity Section15: CompactLogix ControlNet Messaging ControlNet connections can be scheduled or unscheduled. A Scheduled connection lets you send and receive data repeatedly at a predetermined interval (RPI) Distributed I/O, HMI, Drives, Controller to Controller (Producer/Consumer), all use scheduled connections. An unscheduled connection is a message transfer between a controller and a device that is triggered by a MSG instruction. Unscheduled messages let you send and receive data when needed Peer to Peer messaging between controllers, Controller Programming, HMI/RSLinx all use unscheduled connections Note: HMI devices, like Panelview Plus or RSView SE, can be setup to use both scheduled and unscheduled connections

Unscheduled Data Message instructions in ladder and RSLinx communications to a HMI or PC is unscheduled. Note- Scheduled traffic is NEVER burdened by the addition of unscheduled traffic When performing only messaging across ControlNet there are Pros and Cons of adding modules into the module configuration. Pros: Provides visual overview of the network Provides status on the modules of the I/O tree Makes it easier to use a MSG instruction by allowing you to browse to your destination during development Cons Creates additional traffic on the network because a Ping is regularly sent to the destination module. The traffic generated uses unconnected messaging and will use some of the 3 incoming and 10-40* outgoing unconnected message buffers on the processor. The Pings will occupy the ControlNet ports unconnected buffers (When using messages Instructions to devices in tree no ping occurs to that device. Also, CompactBus local I/O does not use buffers,)

42

CompactLogix Performance and Capacity *Buffer size is increased by using CIP Generic Message Instruction. (Setting the maximum # of buffers has been outlined in Pub 1756-UM518B-EN-P Feb 2003 pg. Appendix C-2 through C-5 DHRIO User Manual, or 1756-pm001-f-en-p June 2003.)

For every buffer increased you will consume 1200 bytes of memory. The memory tab under controller properties provides an estimate of memory used in the controller. In CompactLogix there is only one area of memory.

Guidelines: Place the modules in the I/O Tree but inhibit them. This will give a visual representation of the network, allow you to browse to the destination of MSG instruction, but will not generate any Pings. All inhibited modules will have a yellow information circle indicating it is inhibited and no connection will be established to them.

Leave the I/O tree empty and type the path into the MSG instruction manually, ie. 1,1,2,5,1,5. This will not generate any additional traffic, but the status of remote modules will be unavailable and the user must understand the Rockwell path convention. 1, to the backplane o #, across the backplane to the slot number of module o 2 (or 3 if 2 ports on the front), out the front of the module to the network o #, address of next module

43

CompactLogix Performance and Capacity

Explicit ControlNet Messaging Performance When configuring a ladder message in Logix, the user may or may not have the availability to cache a message, depending on the type of message being configured. Both use a connection, however cached messaging continues to use the connection, even when the message is completed, tying up buffers and resources. Uncached messages open a connection and then close the connection once the message is completed, freeing up the resources and buffers. Cached message performance is faster, since the connection is already established, where as the uncached message needs time to re-open the connection. Use cached messaging when sending data often, more than once every 30 sec. uncached when sending data infrequently.

44

CompactLogix Performance and Capacity

. Cached Messaging: When doing cached messages, only 1 connection will be used for all messages with the same path destination. The time to complete each cached message is low and cached messages have little effect on the scan time. Tip: You could expect to use a little more than 1K of memory for each cached message. Caution: The limit of the number of cached messages could affect the use of the PanelView Plus with the L35CR controller. The PanelView Plus uses cached buffers.

Uncached Messaging: Only 6 messages are supported simultaneously . The time to complete an uncached message is about 10 times slower than a cached message. Caution: The limit of the number of uncached messages could affect the use of the Standard PanelViews with the L35 controllers. The Standard PanelViews use uncached buffers.

45

CompactLogix Performance and Capacity Test: Effects of Unscheduled Messaging on ControlNet on a 1769-L35CR
Unscheduled ControlNet MSG Performance
250

200

Time(ms)

150

cached scan time cached MSG DN Time uncached scan time

100

uncached MSG DN time

50

0 6 12 18 24 30 Total Number of Unscheduled MSG's

(The baseline test was used with 1 1769-L35CR and 5 pairs of 1756-L55/1756-CNBR pairs. No scheduled traffic. NUT=5ms. Number of outgoing message buffers was changed ot 40. All modules in I/O tree were inhibited. 30 messages sent to and 30 from CompactLogix to other controllers consisting of 100 element DINT array.)

Test Results: Effects of Unscheduled Messaging on ControlNet on a 1769-L35CR

Total Number of Cached MSG's executing 6 12 18 24 30 # Cnet Connections used by Controller 7 13 19 26 31 Cnet Port CPU% 85% 98% 99% 99% 99% Typical MSG DN Time 23 35 61 81 100

Program Scan Time 3-9ms 3-9 ms 3-9 ms 3-10ms 4-10ms

Controller CPU% 39% 44% 43% 40% 40%

Memory Used 155,620 160,772 168,940 177,108 185,284

46

CompactLogix Performance and Capacity

Mixing Scheduled ControlNet I/O with Unscheduled Cached Messaging: Scheduled traffic, I/O and Produced/Consumed data, is not affected by addition of unscheduled messaging. Additional unscheduled traffic can be added to scheduled I/O on a network if CNet %CPU port stays below 70% with only scheduled communications first. (You only need to consider the ControlNet Interface CPU utilization. The CompactLogix Processor CPU utilization will NEVER be over taxed ahead of the Interface CPU.) The amount of unscheduled messaging is limited by the number of connections available on the L3x processor and the amount of time needed for the message to complete. Caution: If the CNet Port %CPU was over 70% with scheduled traffic only, as measured in RSLinx, under Module Statistics, then adding additional unscheduled traffic is not likely to be successful. Caution: A maximum of only 6 uncached messages is supported simultaneously, adding schedule data will cause the number to go down. Test: Effects of adding Unscheduled cached messaging to Scheduled I/O on a 1769-L35CR
Adding Unscheduled Cached MSG to Scheduled I/O
100 90 80 70 60 50 40 30 20 10 0 2 4 6 8 9 Number of Connections %CPU of CNET port w/o unscheduled MSG MAX number of unsched cached msg

47

CompactLogix Performance and Capacity

(The baseline test was used with the NUT=5ms, all RPIs= 10ms, Local Backplane RPI= 3ms, System Overhead Time Slice=30% and all scheduled connections being rack optimized to a Flex adapter with an IB-16 and OB16 module.)

Test Results: Effects of adding Unscheduled cached messaging to Scheduled I/O on a 1769L35CR L35 Cnet Port %CPU w/o unscheduled messages 36% 53% 69% 86% 91%

Number of scheduled Connections 2 4 6 8 9

MAX number of unscheduled cached messages 24 24 18 2 0

L35 MSG DN time 98 120 120 181 NA

48

CompactLogix Performance and Capacity Section 16: Bridging Through a CompactLogix Controller Recommended: 1) ControlNet to DeviceNet via the 1769-SDN. (For configuration only, not data collection.) 2) Ethernet to DeviceNet via the 1769-SDN. (For configuration only, not data collection.)

Not Recommended: 1) Serial to ControlNet a. Bridging only recommended for simple tasks like browsing ControlNet or monitoring a single node. b. DO NOT configure ControlNet with RSNetworx for ControlNet by bridging through the serial port of the CompactLogix controller. c. DO NOT use this path to go online to other controllers 2) Serial to Ethernet a. Bridging only recommended for simple tasks like browsing Ethernet or monitoring a single node. b. DO NOT configure ControlNet with RSNetworx for ControlNet by bridging through the serial port of the CompactLogix controller. c. DO NOT use this path to go online to other controllers 3) Serial to DeviceNet a. Bridging via this route is only recommended for simple tasks like browsing DeviceNet or monitoring a single node via DeviceNet.

49

CompactLogix Performance and Capacity

Section 17: Other CompactLogix Configurations: High Speed Redundant ControlNet:

CompactLogix SCADA:

50

CompactLogix Performance and Capacity

Section18: Hardware and Firmware Differences in CompactLogix CompactLogix is in the Logix Family of Controllers, but because of hardware and firmware differences the following should be noted: 1) The CompactLogix controller must service system functions such as I/O, network communications that in a 1756 ControlLogix controller are handles by other hardware , ie 1756-CNBs, I/O modules, etc. As a result, performance in a 1756 ControLogix controller will be increased in comparison to a 1756 CompactLogix controller. 2) The 1756 ControlLogix controller has more processing horsepower than the CompactLogix controller because the CompactLogix processor has additional tasks to run (I/O, network communication tasks, and messaging) that the 1756 ControlLogix processor does not need to utilize resources for. As a result the CompactLogix controller can take longer to power up when compared to a 1756 controller. The CompactLogix controller has a serial boot sequence with the Logix engine powering up first followed by the CompactBus and then the network port.

51

CompactLogix Performance and Capacity Appendix A: Table of Message Types (Connected vs Unconnected) Below is a table of all the message types that are supported and the connection type that is uses U = unconnected C = connected
Message Type CIP Generic CIP Datatable Read CIP Datatable Write SLC Typed Read - serial SLC Typed Read - DH+ SLC Typed Read - unsol SLC Typed Write - serial SLC Typed Write - DH+ SLC Typed Write - unsol Cnet BT Read Cnet BT write BT Read - RIO BT Write - RIO PLC2 Read - serial PLC2 Read - CIP PLC2 Read - DH+ PLC2 Read - unsol PLC2 Write - serial PLC2 Write - CIP PLC2 Write - DH+ PLC2 Write - unsol PLC-3/5 WdRng Read - serial PLC-3/5 WdRng Read - CIP PLC-3/5 WdRng Read - DH+ PLC-3/5 WdRng Read - unsol PLC-3/5 WdRng Write - serial PLC-3/5 WdRng Write - CIP PLC-3/5 WdRng Write - DH+ PLC-3/5 WdRng Write - unsol PLC-3/5 Typed Read - serial PLC-3/5 Typed Read - CIP PLC-3/5 Typed Read - DH+ PLC-3/5 Typed Read - unsol PLC-3/5 Typed Write - serial PLC-3/5 Typed Write - CIP PLC-3/5 Typed Write - DH+ PLC-3/5 Typed Write - unsol IO Reconfig Connection Type U/C C/U C/U U C U U C U C C C C U U C U U U C U U U C U U U C U U U C U U U C U U

52

CompactLogix Performance and Capacity Appendix B:Flex I/O vs. Point I/O Performance Comparison Objective: To determine any differences from a performance standpoint between Flex I/O and Point I/O. The test consisted of a single Flex adapter or a single Point adapter on ControlNet or Ethernet controlled by a CompactLogix controller. The RPI and the number of input/output modules used was varied. The communications format was Rack Optimized. Flex I/O used the1794-IB16 as an input card and the 1794-OB16 as an output card. Point I/O used the1734-IB4 as an input card and the 1734-OB4E as an output card. All modules were set at their default filter time. Each configuration used 20 samples and the low and high numbers are shown. 20 samples are not enough to be statistically accurate but are enough samples for a general comparison. Note: Flex and Point were compared based on the number of modules used not on identical number of I/O points. I.E. A Flex module has 16 points per module but Point had 4 points per module.

ControlNet Throughput 2 mS RPI Flex I/O Point I/O 3 mS RPI Flex I/O Point I/O 5 mS RPI Flex I/O Point I/O

1 Input 1 Output Module 9.0-13.0 mS 9.5-14.5 mS 12.0-16.5 mS 10.5-22.0 mS 13.5-23.0 mS 15.5-23.5 mS

2 Input 2 Output Modules 10.0-13.5 mS 10.0-14.0 mS 11.0-16.5 mS 11.0-16.0 mS 13.5-26.0 mS 15.0-23.0 mS

4 Input 4 Output Modules 10.0-14.5 mS 10.5-14.5 mS 14.5-17.5 mS 11-16.5 mS 14.5-23.5 mS 14.5-27.0 mS

Ethernet Throughput 2 mS RPI Flex I/O Point I/O 3 mS RPI Flex I/O Point I/O 5 mS RPI Flex I/O Point I/O

1 Input 1 Output Module 4.5-9.5 mS 8.0-15.5 mS 4.5-9.5 mS 8.0-13.0 mS 5.0-13.0 mS 8.5-16.5 mS

2 Input 2 Output Modules 5.0-8.5 mS 5.5-12.2 mS 5.0-9.0 mS 7.0-13.0 mS 6.0-12.5 mS 8.5-19.0 mS

4 Input 4 Output Modules 5.0-8.5 mS 7.5-11.5 mS 5.0-9.5 mS 8.0-11.0 mS 7.0-13.5 mS 8.0-18.0 mS

Summary: This summary is based off of general trends from the data above and not all data points will fall into the general trend primarily because the number of samples taken was not large. On both Ethernet and ControlNet for a typical number of I/O modules used the throughput is not affected by the number of modules contained in the Flex or Point chassis. Since Flex only supports 8 modules per chassis and Point supports 63 no statement is made about the performance of a Point chassis with 63 modules. On ControlNet there is no significant performance difference between Flex and point I/O.

53

CompactLogix Performance and Capacity

www.rockwellautomation.com
ACIG Logix Americas: Rockwell Automation, 1201 South Second Street, Milwaukee, WI 53204-2496 USA, Tel: (1) 414.382.2000, Fax: (1) 414.382.4444 Europe/Middle East/Africa: Rockwell Automation SA/NV, Vorstlaan/Boulevard du Souverain 36, 1170 Brussels, Belgium, Tel: (32) 2 663 0600, Fax: (32) 2 663 0640 Asia Pacific: Rockwell Automation, Level 14, Core F, Cyberport 3, 100 Cyberport Road, Hong Kong, Tel: (852) 2887 4788, Fax: (852) 2508 1846
Publication Number IASIMP-QR007A-EN-P 8/06 Copyright 2006 Rockwell Automation, Inc.

54

All Rights Reserved. Printed in USA.