CompactLogix Performance Guide

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.


2

Table of Contents

Section 1: Glossary of Terms…………………………………………………………3 Section 2: CompactLogix CPU Utilization (%CPU)- Baseline Testing................7 Section 3: CompactLogix System Basics……………………………………………8 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 System………………………37 Section 14: CompactLogix on ControlNet: Connections………………………….39 Section15: CompactLogix ControlNet Messaging…………………………………42 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


3

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 it’s 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,


4

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 it’s 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 it’s 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)).


5

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.


6

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


7

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.


8

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 supply- exceptions being specialty modules.

Power Supply Distance Rating: 1769 Digital Modules 8 modules 1769 Analog Modules 8 modules 1769-HSC 4 modules 1769-SM1 6 modules 1769-SM2 4 modules 1769-SDN 4 modules 1769-ADN 5 modules 1769-ASCII 4 modules


9

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


10

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


11

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.


12

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.


13

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


14

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 it’s 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 RPI’s 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

0

10

20

30

40

50

60

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

RPI

CPU

Utili

zatio

n No Modules2 Modules 4 Modules8 Modules30 modules

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


15

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:

Throughput Main Task Scan Time Task Priority Worse/Best Max/Min Continuous 16 2.1ms / 1.0ms 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


16

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 (0-5) than Local I/O Compact Bus of 6, may cause the I/O throughput to be slowed down?


17

Logix Priority Task Levels: Priority level: 1- highest

17 –lowest

Task Priority Comments

Periodic Task (Ladder) *(1-15) Up to 7 periodic tasks can configured Local CompactBus (I/O) 6 I/O scan performed at RPI rate NetLinx Class 1 messaging 6 Scheduled I/O, produced/consumed data Continuous Task (Ladder) 16 Only one Continuous Task is supported NetLinx Class 3 17 Unscheduled messaging 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 it’s 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 Task Priority Worse/Best Max/Min Periodic 15 11.2ms / 0.9ms 3.7ms / 3.2ms Periodic 6 11.6ms / 1.6ms 2.9ms / 2.3ms Periodic 1 13.9ms / 4.2ms 2.5ms/ 2.1ms 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.


18

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.

Time (ms)

10 32 54 76 98 1110 1312 1514 1716 1918 20

CT CT

BT BT

ContinuousTask

BackgroundTask

Figure 1The 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%.

10 32 54 76 98 1110 1312 1514 1716 1918 20

Time (ms)

CT

BT

ContinuousTask

BackgroundTask

Figure 2

CT CT CT

BT BT BT


19

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.

The formula used for calculating the time slice is 1001

1% ×⎟⎠⎞⎜

⎝⎛

+=

CTTS , which

means that 1%

100 −⎟⎠⎞⎜

⎝⎛=TS

CT , where TS% is the time slice in per cent, and CT is

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 task’s 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.


20

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

10 32 54 76 98 1110 1312 1514 1716 1918 20

Time (ms)

BT

ContinuousTask

BackgroundTask

Figure 3

PeriodicTask

2 3 4 5 6 7 8 9

PT PT PT

1

PT PT PT PT PTPT

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 doesn’t 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. Let’s see how it affects the previous setup.


21

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

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.

1

ContinuousTask

BackgroundTask

PeriodicTask

Time (ms)

Figure 4

MotionTask

MT MT MT MT

CT CT CT CT

PT PT PT PT PT PT

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

32


22

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 it’s scan in a timely fashion. A finite amount of time is also used for switching between tasks.


23

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.

Example: To determine the total number of connections used on a NetLinx daughter card use the following:

1. Count the number of produced tags ______ 2. Count the number of consumers for each produced tag ______ 3. Count the number of direct I/O connections ______ 4. Count the number of rack optimized connections ______ 5. 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 HMI’s 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 ______

Device

Total Number of

Connections

Total Number of Connected/Cached

Buffers

Total Number of Unconnected/Uncached

Buffers

1769 L3x Controller 100 32 3 fixed incoming/ 10-40 expandable outgoing

**ControlNet port *32 **Ethernet port 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)


24

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.


25

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


26

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

(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 Maximum Recommended

ThruPut** ENetPort ENetPort

RPI*** of all Connections

CPU% #Conn CPU% #Conn 4-12ms 3ms 84% 5 61% 3 9-14ms 5ms 86% 10 64% 7 8-23ms 10ms 86% 20 72% 15 12-36ms 16ms 85% 32 70% 23 15-42ms 26ms 73% 32

Ethernet I/O Connections

0

5

10

15

20

25

30

35

3ms 5ms 10ms 16ms 26ms

RPI of All Connections

Supp

orte

d C

onne

ctio

ns

MAX Connections

Recommended Connections


27

Guidelines:

It is recommended that for most applications, all I/O RPI’s 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.


28

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 controller’s 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.


29

Table: Packets Per Second for Various RPI and Connections Combinations Connections RPI (ms) PPS Fastest RPI

5 2.0 5,000 Exceeds PPS limit 5 3.0 3,333 5 connections at 3ms 5 4.0 2,500 5 5.0 2,000 5 6.0 1,667 5 7.0 1,429 5 8.0 1,250 5 9.0 1,111 5 10.0 1,000 5 20.0 500

10 2.0 10,000 Exceeds PPS limit 10 3.0 6,667 Exceeds PPS limit 10 4.0 5,000 Exceeds PPS limit 10 5.0 4,000 Exceeds 90% Recommendation 10 6.0 3,333 10 connections at 6ms 10 7.0 2,857 10 8.0 2,500 10 9.0 2,222 10 10.0 2,000 10 20.0 1,000

20 2.0 20,000 Exceeds PPS limit 20 3.0 13,333 Exceeds PPS limit 20 4.0 10,000 Exceeds PPS limit 20 5.0 8,000 Exceeds PPS limit 20 6.0 6,667 Exceeds PPS limit 20 7.0 5,714 Exceeds PPS limit 20 8.0 5,000 Exceeds PPS limit 20 9.0 4,444 Exceeds PPS limit 20 10.0 4,000 Exceeds 90% Recommendation 20 12.0 3,333 20 connections at 12ms 30 18.0 3,333 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


30

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.


31

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 port’s 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,)


32

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.


33

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


34

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

0

20

40

60

80

100

120

140

6 12 18 24 30

Cached Messages

Tim

e (m

s) Avg Program Scan - CachedAvg MSG Completion- CachedAvg Program Scan-UncachedAvg MSG Completion- Uncached

X

X

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


35

Test Results: Effects of Cached Messaging on Program Scan and Message Completion for 1769-L32E L35CR Total # of

CACHED MSG’s

Executing Prog Scan Time (AVG)

L32E ENet Port

%CPU

L32E PLC

%CPU

Typical L32E MSG DN

Time (AVG)

Memory Used in the L32E

6 4 16-50% 33% 40 179,309 12 5 70-93% 43% 40 188,886

18 * 6 100% 45% 65 195,716 24* 7 100% 44% 80 203,824 30* 8 100% 44% 120 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

L35CR Total # of UNCACHED

MSG’s Executing

Prog Scan Time

(AVG)

L32E ENet Port

%CPU

L32E PLC

%CPU

Typical L32E MSG DN

Time (AVG)

Memory Used in the L32E

6 5 90-98% 37% 110ms 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.


36

Test: Effects of Mixing Cached Ethernet Messaging with Ethernet I/O on a 1769-L32E.

Message Performance with Addition of Ethernet I/O

0

20

40

60

80

100

120

2 4 6

Number of I/O Connections

Number of Explicit Cached MSGAVG Enet Port %CPU AVG MSG DN Time (ms)

(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 L32E ENet Port

%CPU Approx MAX

WITHOUT Explicit Number of Explicit

MSG Cached

Number of I/O Conn

MSG

L32E ENet Port %CPU WITH Explicit

MSG

Typical L32E MSG DN Time

2 36% 8 65-95% 30-60ms 4 50% 6 90-100% 30-60ms 6 75% 4 100% 50-60ms


37

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 RPI’s based on the type of device used:

Analog I/O 80ms RPI Produced / Consumed Tags 40ms RPI PowerFlex Drives 40ms RPI

Nominal System - CompactLogix

...

3 scheduled connections per Bank

( 9 total scheduled connections)

• Each Bank has 6 digital and 2 analog module

Scheduled Connections Unscheduled Connections

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. - Panelview Plus - Explicit Messages - RSLogix 5000

• 16 Scheduled Connections

• 16 Unscheduled Connections

• 10 ms NUT

• < 70% CNET CPU Utilization

1 scheduled connection per Drive

( 3 total scheduled connections)

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

40ms RPI

10ms RPI Digital

40ms RPI

80ms RPI Analog


38

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 RPI’s 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 1769-L35CR

User Memory 750K 1.5 Meg

Local I/O Modules 16 Local I/O 30 Local I/O

Minimum Local RPI 1 ms RPI 1 ms RPI

ControlNet Media Coaxial (BNC) Coaxial (BNC)

ControlNet Connections

32 Max 32 Max

Media Redundancy No (1 BNC) Yes (2 BNC)

Setting ControlNet Node Address

Rotary Switch or software selectable

Rotary Switch or software 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


39

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

Number of ControlNet Connections

0

5

10

15

20

25

30

35

2ms 3ms 5ms 10ms 10ms 12ms 14ms 20ms 64ms

2ms 3ms 5ms 5ms 10ms 12ms 14ms 5ms 4ms

RPI

NUT

Num

ber o

f Con

nect

ions

Max# of Connections

Recommended #ofConnections

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.


40

Test Results: Number of connections supported by various NUT/RPI settings on1796-L35CR

Maximum Recommended Typical

Throughput NUT RPI of

Connections CNET Port CPU% #

Connections CNET Port

CPU% # Connections 9-15ms 2ms 2ms 78% 1 34% 014-19ms 3ms 3ms 82% 2 60% 114-24ms 5ms 5ms 86% 4 70% 320-38ms 5ms 10ms 90% 9 69% 624-44ms 10ms 10ms 88% 9 64% 628-46ms 12ms 12ms 95% 12 68% 832-48ms 14ms 14ms 85% 12 71% 1024-56ms 5ms 20ms 86% 16 69% 1270-129ms 4ms 64ms* 67% 31

*32 max connections for ControlNet port.

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


41

– 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


42

Section15: CompactLogix ControlNet Messaging ControlNet connections can be scheduled or unscheduled.

A Scheduled connection lets you send and receive data repeatedly at a pre-determined 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 port’s 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,)


43

*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


44

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.


45

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


46

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

Unscheduled ControlNet MSG Performance

0

50

100

150

200

250

6 12 18 24 30

Total Number of Unscheduled MSG's

Tim

e(m

s) cached scan timecached MSG DN Timeuncached scan timeuncached MSG DN time

(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 Program Scan Time

# Cnet Connections

used by Controller

Cnet Port

CPU% Controller

CPU%

Typical MSG DN

Time Memory

Used 6 3-9ms 7 85% 39% 23 155,620

12 3-9 ms 13 98% 44% 35 160,77218 3-9 ms 19 99% 43% 61 168,94024 3-10ms 26 99% 40% 81 177,10830 4-10ms 31 99% 40% 100 185,284


47

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

0

10

20

30

40

50

60

70

80

90

100

2 4 6 8 9

Number of Connections

%CPU of CNET port w/ounscheduled MSGMAX number of unsched cachedmsg


48

(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 1769-L35CR

Number of scheduled

Connections

L35 Cnet Port %CPU

w/o unscheduled

messages

MAX number of unscheduled

cached messages

L35 MSG

DN time2 36% 24 98 4 53% 24 120 6 69% 18 120 8 86% 2 181 9 91% 0 NA


49

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.


50

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

CompactLogix SCADA:


51

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.


52

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 Connection Type CIP Generic U/C CIP Datatable Read C/U CIP Datatable Write C/U SLC Typed Read - serial U SLC Typed Read - DH+ C SLC Typed Read - unsol U SLC Typed Write - serial U SLC Typed Write - DH+ C SLC Typed Write - unsol U Cnet BT Read C Cnet BT write C BT Read - RIO C BT Write - RIO C PLC2 Read - serial U PLC2 Read - CIP U PLC2 Read - DH+ C PLC2 Read - unsol U PLC2 Write - serial U PLC2 Write - CIP U PLC2 Write - DH+ C PLC2 Write - unsol U PLC-3/5 WdRng Read - serial U PLC-3/5 WdRng Read - CIP U PLC-3/5 WdRng Read - DH+ C PLC-3/5 WdRng Read - unsol U PLC-3/5 WdRng Write - serial U PLC-3/5 WdRng Write - CIP U PLC-3/5 WdRng Write - DH+ C PLC-3/5 WdRng Write - unsol U PLC-3/5 Typed Read - serial U PLC-3/5 Typed Read - CIP U PLC-3/5 Typed Read - DH+ C PLC-3/5 Typed Read - unsol U PLC-3/5 Typed Write - serial U PLC-3/5 Typed Write - CIP U PLC-3/5 Typed Write - DH+ C PLC-3/5 Typed Write - unsol U IO Reconfig U


53

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

1 Input 1 Output Module

2 Input 2 Output Modules


Flex I/O 9.0-13.0 mS 10.0-13.5 mS 10.0-14.5 mS 2 mS RPI Point I/O 9.5-14.5 mS 10.0-14.0 mS 10.5-14.5 mS Flex I/O 12.0-16.5 mS 11.0-16.5 mS 14.5-17.5 mS 3 mS RPI Point I/O 10.5-22.0 mS 11.0-16.0 mS 11-16.5 mS Flex I/O 13.5-23.0 mS 13.5-26.0 mS 14.5-23.5 mS 5 mS RPI Point I/O 15.5-23.5 mS 15.0-23.0 mS 14.5-27.0 mS

Ethernet Throughput

1 Input 1 Output Module



Flex I/O 4.5-9.5 mS 5.0-8.5 mS 5.0-8.5 mS 2 mS RPI Point I/O 8.0-15.5 mS 5.5-12.2 mS 7.5-11.5 mS Flex I/O 4.5-9.5 mS 5.0-9.0 mS 5.0-9.5 mS 3 mS RPI Point I/O 8.0-13.0 mS 7.0-13.0 mS 8.0-11.0 mS Flex I/O 5.0-13.0 mS 6.0-12.5 mS 7.0-13.5 mS 5 mS RPI Point I/O 8.5-16.5 mS 8.5-19.0 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.


54

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 0640Asia 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. All Rights Reserved. Printed in USA.

CompactLogix Performance Guide

Documents

Transcript of CompactLogix Performance Guide