Table of Contents Section 1: Introduction /CompactLogix System Basics:.. 3 Section 2: Glossary of Terms. 12 Section 3: CompactLogix CPU Utilization (%CPU) Baseline Testing... 15 Section 4: 1769 CompactBus I/O RPI Guidelines for the 1769-L3X Family..... 18 Section 5: CompactBus RPI Effects on %CPU/ Program Execution...20 Section 6: Utilizing the Periodic Task and Minimum RPI to Obtain Fastest Possible Screw-to-Screw Performance:......24 Section 7: Periodic and Event Based Tasks.26 Section 8: System Overhead Time Slice.....29 Section 9: Limitations Imposed by Connections.....36 Section 10: CompactLogix on Ethernet Overview.......... 39 Section 11: CompactLogix on Ethernet: Connections and Packets Per Second 44 Section 12: CompactLogix Ethernet Explicit Messaging...63 Section 13: CompactLogix on ControlNet Overview... 81 Section 14: CompactLogix ControlNet: Explicit Messaging...87 Section 15: Bridging Through a CompactLogix Controller.......101 Section16: Other CompactLogix Configurations........ 103 Section17: Comparing the CompactLogix L3X, L4X, and ControlLogix..104 Section 18: CompactLogix 5370 L3 and Integrated Motion on EtherNet/IP.106 Appendix A: Table of Message Types (Connected vs Unconnected).. 111 Appendix B: Flex I/O vs. Point I/O Performance Comparison...112 2
Section 1: Introduction/ CompactLogix System Basics Section 1a: Introduction The purpose of this document is to provide CompactLogix system performance and capacity information, along with design considerations, that can be used to achieve optimized performance from a CompactLogix system. These recommendations may not be the best solution for all applications, but rather are guidelines and indications of performance. This document has had three revisions: IASIMP-QR007A-EN-P (August 2006) covered the 1769-L3X family of CompactLogix processors. IASIMP-QR007B-EN-P (March 2009) added the 1769-L4X family of CompactLogix processors. IASIMP-QR007C-EN-P (July 2012) added the 5370 L3 family of CompactLogix processors. The CompactLogix family of processors are 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 1769-L3X family consists of the 1769-L31, the 1769-L32C, the 1769-L32CR, the 1769-L32E and the 1769-L35E. The 1768-L4X family consists of the 1768-L43 and the1768-l45. The 5370 L3 family consists of the 1769-L30ER-NSE, the 1769-L30ER, the 1769-L30ERM, the 1769-L33ER, the 1769-L33ERM, and the 1769-L36ERM For a comparison of the 1769-L3X, the 5370 L3, and 1768-L4X Family see Section 17.This section also compares the L4X with the ControlLogix family. Section 1b: 1769-L3x Family Basics The 1769-L31 has two serial ports. The 1769-L32C and 1769-L35CR have an integrated ControlNet port and one serial port. The 1769-L32E and1769-l35e controllers have an integrated EtherNet/IP port and one serial port. The 1769-L3X controllers all use the 1769 CompactBus local I/O bus. Note- the first bank of I/O must contain the controller which must be in the leftmost slot. 3
The power supply distance rating of all 1769 digital and analog I/O modules is eight modules, allowing them to be placed up to eight slots from the power supply except for 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 4
1769-L31 Controller 1769-L31 Controller Capabilities Mix and match any combination of discrete, analog and specialty modules Up to three banks of local 1769 I/O modules Connect the banks with 1m or 1ft of cable Requires one power supply for each bank Two RS-232 serial ports can be configured for ASCII, DH-485, DF1, and modems Supports multiple 1769-SDN DeviceNet modules Removable CompactFlash to store programs, tag values and firmware L31 Supports 512K Memory Up to 16 local I/O modules with up to 32 points per digital modules and 8 points per analog modules 5
1769-L32C and L35CR Controller 1769-L32C and L35CR Controller Capabilities Mix and match any combination of discrete, analog and specialty modules Up to three banks of local 1769 I/O modules Connect the banks with 1m or 1ft of cable Requires one power supply for each bank One RS-232 serial port can be configured for ASCII, DH-485, DF1, and Modems Supports multiple 1769-SDN DeviceNet modules Removable CompactFlash to store programs, tag values and firmware L32C supports 750K Memory and a single ControlNet connector Up to 16 local I/O modules with up to 32 points for digital modules and 8 points for analog modules L35CR supports 1.5M Memory and redundant ControlNet connectors Up to 30 local I/O modules with up to 32 points for digital modules and 8 points for analog modules 6
1769-L32E and L35E Controller 1769-L32E and L35E Controller Capabilities Mix and match any combination of discrete, analog and specialty modules Up to three banks of local 1769 I/O modules Connect the banks with 1m or 1ft of cable Requires one power supply for each bank One RS-232 serial port can be configured for ASCII, DH-485, DF1, and modems Supports multiple 1769-SDN DeviceNet modules Removable CompactFlash to store programs, tag values and firmware L32E: supports: 750K Memory and a single EtherNet/IP port. Up to 16 local I/O modules with up to 32 points for digital modules and 8 points for analog modules L35E supports: 1.5M Memory and a single Ethernet/IP port. Up to 30 local I/O modules with up to 32 points for digital modules and 8 points for analog modules, 7
Section 1c:1768-L4X Family Basics The 1768-L43 and L45 processors are a modular platform consisting of: The same1769 CompactBus local I/O bus used by the 1769-L3X to the right of the processor and; An enhanced 1768 bus to the left. This bus supports up to four 1768 modules and adds enhanced communications and motion capabilities to the L4X platform. The following 1768 modules are available: 1768-ENBT/EWEB module provides EtherNet/IP connectivity 1768-CNB module provides ControlNet connectivity 1768-CNBR module provides redundant ControlNet connectivity 1768-M04SE SERCOS module.provides up to 4 Axis of Motion capability. The CompactLogix 1768 power supply requires that a 1768 CompactLogix controller be installed to power the system. The power supply sends 24V dc to the controller located in slot 0. The controller converts the 24V dc to 5V dc and 24V dc and distributes it as needed. 5V and 24V power to 1769 I/O modules on the right side of the controller 24V power to 1768 modules on the left side of the controller Never put a 1769 power supply in the 1768 system. Each additional 1769 I/O bank must have its own power supply. Use a standard 1769 power supply such as 1769-PA4. Since the 1768-L4X processors use the same 1769 CompactBus as the 1769-L3X processors, the same rules apply when using the L4X with this bus. The power supply distance rating of all 1769 digital and analog I/O modules is eight modules, allowing them to be placed up to eight slots from the power supply except for 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 8
1768-L43 and L45 Controller 1768-L43 and L45 Controller Capabilities Mix and match any combination of 1769 discrete, analog and specialty modules Connect the banks with 1m or 1ft of cable Requires one power supply for each 1769 bank One RS-232 serial port can be configured for ASCII, DH-485, DF1, and modems Supports multiple 1769-SDN DeviceNet modules Removable compact flash to store programs, tag values and firmware L43 supports 2M Memory 16 I/O modules with up to 32 points for digital modules and 8 points for analog modules Two 1768 network communication modules 4 axis SERCOS system (one SERCOS card supported) L45 supports: 3M Memory 30 I/O modules with up to 32 points for digital modules and 8 pionts for analog modules Two 1768 network communication modules 8 axis SERCOS system (two SERCOS cards supported) 9
A 4-axis system with Kinetix drives supports: execution of 4 axes per 1 ms velocity bandwidth > 400 Hz and current loop bandwidth > 1000 Hz high resolution, unlimited travel, and absolute feedback features two feedback ports per Kinetix drive optional 2094 Line Interface Module (LIM) as the incoming power source for an entire control panel Section 1d: CompactLogix 5370 L3 Family Basics The L3 controllers all have a USB port and an integrated dual EtherNet/IP port with DLR connectivity, IEEE-1588 support, and sockets. The L3 controllers all use the 1769 CompactBus local I/O bus. Note- the first bank of I/O must contain the controller which must be in the leftmost slot. The power supply distance rating of all 1769 digital and analog I/O modules is eight modules, allowing them to be placed up to eight slots from the power supply except for 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 10
1769-L36ERM Controller L3 Controller Capabilities Mix and match any combination of discrete, analog and specialty modules. Up to three banks of local 1769 I/O modules. Connect the banks with 1m or 1ft of cable. Requires one power supply for each bank. One USB port. Supports multiple 1769-SDN DeviceNet modules. Removable SecureDigital (SD) card to store programs, tag values and firmware. Support for Integrated Motion on EtherNet/IP. IEEE-1588 Time Synchronization Socket Support Choose your controller based on the number of EtherNet/IP I/O nodes it will use on the network no need to keep track of CIP connections. Here is a summary of the L3 capabilities: CompactLogix L3 5370 L30ER-NSE L30ER L30ERM L33ER L33ERM L36ERM Overview Memory 1MB 1MB 1MB 2MB 2MB 3MB Local Expansion Modules 8 8 8 16 16 30 EtherNet/IP I/O Nodes 16 16 16 32 32 48 Integrated Motion on EtherNet/IP No No 1-4 Axis No 1-8Axis 1-16 Axis 11
Section 2: Glossary of Terms Summary: This section defines terms and concepts important to understand the performance and capacity information provided in this document. 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: Outgoing Unconnected, Incoming Unconnected 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 produced/consumed 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 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 since the connection 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 programs and routines continuously, from top to bottom, unless interrupted by another task. A project does not require a continuous task, however, you can only configure one per project. All CPU time not allocated to other operations such as motion, communications and periodic or event based tasks, is used to execute the programs within this task. 12
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, task switching and communications. The lower the CPU%, the more logic, I/O and communications can be added for processing by the controller. Direct Connection- A communication connection used to communicate to I/O in a remote chassis, specifically 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 runs 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 runs 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 within 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 task that was interrupted, at the point it was interrupted. Up to 7 periodic tasks can be configured, each with an interrupt priority and with independent rates. (Execution rate range (0.1ms-2,000s, in increments of 1ms)). 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. 13
Benefits over Source/Destination methods: Highly Efficient- No wasted effort delivering data to those who do not require it. Accurate Data - Everyone receives the data at the same time. Deterministic - Length of time to deliver data is independent of the number of nodes Rack Optimized 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. (Note, if diagnostic digital modules are placed in a Rack Optimized Connection, the diagnostic information will be lost. Use a Direct Connection to save the diagnostic data.) 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. Uncached- This terms applies to ladder logic message instructions. These messages use a connection when starting the message and then close the message when complete, therefore freeing up resources such as buffers, bandwidth and memory. Unconnected- A message that does not use a connection to transfer data to a device. 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 14
Section 3: CompactLogix CPU Utilization (%CPU)- Baseline Testing Summary: This section describes the test run to provide a baseline of CompactLogix CPU usage that will be used as a comparison for the other tests in this document. Since the CompactLogix controller handles multiple tasks such as I/O, network communications and messaging, CPU utilization percentage (%CPU), will be used in this document to measure the load on the controller and to determine the performance and capacity of the CompactLogix system. A baseline program was written to determine the CPU utilization percentage using a cross section of the following instructions: 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 the controller has to perform more operations and is spending less time on ladder execution. A ladder program calculates the %CPU. This identical baseline program was run on a 1769-L35E processor to test the 1769-L3X platform, a 1768-L45 processor to test the 1768-L4X platform, and a 1769-L36ERM processor to test the 5370 L3 platform. 1769-L35E (V20): The 1769-L35E (v20) had no I/O or traffic configured for the 1769- L3E Ethernet Port, had the System Overhead Time Slice (TS) set to 20%, and had no RS232 communications. 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. 15
Test Results. The baseline results are as follows: System Overhead Time Slice = 20% Memory used 140,184 bytes Memory Available 1,432,680 bytes Main Task Scan Times Max 4.21 ms Last 2.344 m %CPU processor used 1.0% (typical) MaxScan = 500; CPUUsed = -6 (ie -0.6%) 1768-L45: The 1768-L45 had no I/O or traffic configured for the 1768-L45 with the System Overhead Time Slice (TS) set to 20% and had no RS232 communications. Test Results. The baseline results are as follows: System Overhead Time Slice = 20% I/O Memory used 19,084 bytes bytes I/O Memory Available 486,772 bytes Data and Logic Memory Used 94,676 bytes Data and Logic Memory Available 3,051,052 bytes Main Task Scan Times Max 3.468ms Last 2.462ms %CPU processor used (typical) 0.7 % MaxScan = 570; CPUUsed = -8 (ie -0.8%) 1769-L36ERM: The 1769-L36ERM had no I/O or traffic configured for the 1769- L36ERM with the System Overhead Time Slice (TS) set to 20% and had no USB communications. Test Results. The baseline results are as follows: System Overhead Time Slice = 20% I/O Memory used 1,264 bytes I/O Memory Available 1,047,312 bytes Data and Logic Memory Used 111,272 bytes Data and Logic Memory Available 3,034,456 bytes Main Task Scan Times Max 2.516ms Last 1.457ms %CPU processor used (typical) 0.0 % MaxScan = 890; CPUUsed = -5 (ie -0.5%) 16
Processor Comparison: Proc Type IO Mem Used IO Mem Available Data & Logic Used Data & Logic Available Main Task Max Scan (ms) Max Scan CPU Used L35e 140,184 1,432,680 Na Na 4.21 500-6 20 L45 19,084 486,772 94,676 3,051,052 3.468 570-8 20 L36ERM 1,264 1,047,312 111,272 3,034,456 2.516 890-5 20 SOTS (%) 17
Section 4: 1769 CompactBus I/O RPI Guidelines for the 1769-L3X (Pre V18 Only) Guideline: If you are using a pre V18 1769-L3X, set the RPI for CompactLocal Bus modules to 5ms or higher (5ms is default in v16 and V17), unless faster RPIs are required for your application. See information below for impacts of faster RPIs. 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 when using Pre V18 1769-L3X family processors. (The 1769-L3x V18 and later, 1768-L4X and CompactLogix 5370 L3 families supports independently set RPIs for each module in the local chassis see Section 5.) As you install modules, the minimum backplane RPI may need to be increased to handle larger amounts of data going across the backplane This setting can be found in the local CompactBus Properties. This value range is (1-750ms). Default is 2ms for V15 of RSLogix 5000 or earlier Default is 5 ms in V16 of RSLogix 5000. Minimum settings for the CompactBus local RPI: These numbers are minimum (fastest) RPI settings. Depending on communications, program processing, and I/O, a higher RPI may be needed. (See Section 5). 18
*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 (*Note - 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, this means that the module can only capture an input signal of 8ms or more. Anything lower that the filter value will be treated as noise and ignored.. Additional Notes: These considerations show how fast modules can be scanned. They are not an indication of screw to screw performance. The CompactBus Local scan 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. An 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.) 19
Section 5: CompactBus RPI Effects on %CPU /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 code execution and task switching. 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 may need to be considered for your particular application. Section 5a: 1769-L3X Family (Pre V18) Guideline: For the Pre V18 L3X Family, 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.) The graph below shows the results of testing performed to determine the effects of RPI on CPU Utilization for the 1769-L35CR RPI Effects on %CPU 60 50 CPU Utilization 40 30 20 No Modules 2 Modules 4 Modules 8 Modules 30 modules 10 0 1ms 2ms 3ms 4ms 5ms 10ms 15ms 20ms RPI (The above chart is only for the 1769 Local CompactBus I/O only. See Baseline test used for this document). 20
Section 5b: 1769-L3X Family (V18 and Later) Summary: For the L3X Family (V18 and Later), set the individual modules RPI greater than 5ms if you want the CompactBus I/O to have the least affect on messaging,hmi, uploads, and downloads. The 1769-L3X (V18 and Later) family of processors support individual RPI s for local modules. The range for RPI values is 1ms 750ms; except for the 1769-SDN and 1769-ASCII modules which are 2ms 750ms. The default RPI value depends on the module type. The graph below shows the results of testing performed to determine the effects of RPI on CPU Utilization for a 1769-L35E V19.11. 70.0% 60.0% CPU Utilization 50.0% 40.0% 30.0% 20.0% 2 Discrete 2 Analog 2 Discrete, 2 Analog 5 Discrete, 3 Analog 1 HSC 1 ASCII 1 SDN 10.0% 0.0% 1ms 2ms 3ms 4ms 5ms 10ms 15ms 20ms RPI 21
Section 5c: 5370 L3 Family Summary: For the 5370 L3 processor family, set the individual modules RPI greater than 5ms if you want the CompactBus I/O to have the least affect on messaging,hmi,uploads, and downloads The 5370 L3 processors support individual RPI s for local modules. The range for RPI values is 1ms 750ms; except for the 1769-SDN module which is 2ms 750ms. Default RPI value depends on the module type. The graph below shows the results of testing performed to determine the effects of RPI on CPU Utilization for a 1769-L36ERM. Section 5d: 1768-L4X Family Summary: The 1768-L4x processor %CPU is minimally affected by either the number of 1769 CompactBus modules in the rack or the individual RPI s selected for the modules The 1768-L4X processors support individual RPI s for local modules. The range for RPI values is 1ms 750ms; except for 1769-SDN and 1769-ASCII modules which are 2ms 750ms. Default RPI value depends on the module type. 22
The graph below shows the results of testing performed to determine the impact of populating the1769 bus with modules of different types at different RPI values on %CPU. The results of the testing show that the 1768-L4x processor is minimally affected by either the the number of 1769 CompactBus modules being connected or the RPI s selected. 23
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 The CompactLogix backplane scan is asynchronous to the program execution. I/O updates can happen anytime throughout the program scan. Note: Your minimum screw-to-screw times will increase as you add modules to your system Section 6a: 1769-L3X Family Summary: 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. Make sure you set the priority of the Periodic task greater than 6. The following shows the results of testing performed to determine min/ max/ typical screw to screw time possible with 1768-L3X platform. Only the local CompactBus was used with a 1769-IQ16F/A input module and a 1769-OB16/B output module. RPI was set to 1ms. 100 samples were taken of an output turning on an input. Throughput Main Task Scan Time Task Priority Worse/Best Max/Min Continuous 15 2.1ms / 1.0ms 2.5ms /.4ms -Average screw-to-screw performance is 2ms -Repeatability or Screw-to-Screw Jitter is 3ms or less 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. Section 6b: 1769-L4X Family Summary: With 4 or less non-specialty modules, the system can handle a 1ms RPI. Average screw-to-screw performance is 1.2ms. Repeatability or Screw-to-Screw Jitter is 2ms or less. The following shows the results of testing performed to determine min/ max/ typical screw to screw time possible with 1768-L4X platform. Only the local CompactBus was 24
used with a 1769-IQ16F/A input module and a 1769-OB16/B output module. RPI for each was set to 1ms. Throughput Main Task Scan Time Task Priority Worse/Best Max/Min Continuous 15 1.9ms / 0.4ms 1.9ms /.4ms -Average screw-to-screw performance is 1.2 ms -Repeatability or Screw-to-Screw Jitter is 2ms or less The histogram chart below displays the distribution of scan time values captured during L4X testing with 35 samples taken. Typical throughput ranged from.8 1.6 ms. Histogram Frequency 20 10 0 0.4 0.8 1.2 1.6 2 Frequency msec Section 6c: 5370 L3 Family Summary: With four or less non-specialty modules, the system can handle a 1ms RPI. Average screw-to-screw performance is 1.287ms. Repeatability or Screw-to-Screw Jitter is 1ms or less. The following shows the results of testing performed to determine min/ max/ typical screw to screw time possible with the 5370 L3 platform. Only the local CompactBus was used with a 1769-IQ16F/A input module and a 1769-OB16/B output module. RPI for each module was set to 1ms. Throughput Main Task Scan Time Task Priority Worse/Best Max/Min Continuous 15 1.64ms / 0.856ms 1.935ms/0.03ms Average screw-to-screw performance is 1.287ms Repeatability or Screw-to-Screw Jitter is 1ms or less 25
Section 7: Periodic and Event Based Tasks Summary: The priorities the user selects for Periodic/Event Tasks will affect both I/O throughput (5370 L3 and L3X) and Continuous (Main) Task program scan. The user needs to determine what is important for his application and adjust the priorities accordingly. For applications where speed is NOT of great concern, this will not be an issue. Section 7a: Introduction When a project is created in RSLogix 5000, a 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 right clicking on Task and choosing New task: 26
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 (5370 L3 and L3X) NetLinx Class 1 messaging** 6 I/O, produced/consumed data Continuous Task (Ladder) 15 Only one Continuous Task is supported NetLinx Class 3 messaging** 17 Explicit Messaging Other Communications 17 * The only priorities that can be changed by the user are the priority numbers of the Periodic tasks. ** The 1769-L3X and 5370 L3 controllers must process these message types, whereas the1768-l4x/ ControlLogix controllers do not (they have dedicated communication modules for this function) The priorities the user selects for Periodic/Event Tasks will affect both I/O throughput (5370 L3 and L3X) and Continuous (Main) Task program scan. Use of a periodic/event task will interrupt any programs in the Continuous task, thereby affecting their program scan. The user needs to determine what is important for his application and adjust the priorities accordingly. For applications where speed is NOT of great concern, this will not be an issue. 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. Caution: We do not recommend going below a 1ms Periodic Task. Setting the periodic task below 1ms may produce excessive task overlaps. Tip: Triggering an event task from an input event: 1. Create an event task with the code in it that you need to execute when the event occurs. Set this to the highest priority. 2. Create a periodic task at a high priority (but less than the event task) that has just the code in it that is needed to monitor the event. 3. Trigger the event task from the periodic when the event condition is met. 27
Section 7b: 1769-L3X Family 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. Test: Effects of Changing Priorities of Periodic Task: I/O 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 1769-L35CR baseline program. This time the Main Task, which was Continuous, was 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. The priorities the user selects for Periodic/Event Tasks will affect both I/O throughput and program scan. For high speed applications the user needs to determine what is more important for his application, I/O throughput or program scan, and adjust the priorities accordingly. For applications where speed is NOT of great concern, this will not be an issue. Section 7c: 1768-L4X Family The L4X processors do not assign a priority to the Local CompactBus I/O task as do the L3X processors therefore you do not have to consider this when selecting a task priority. Remember that your selection still impacts program scan times (as discussed in Section 7a), however. Section 7d: 5370 L3 Family Guideline: If your application requires a high amount of communications, only have a maximum of one Periodic Task configured and set it s priority to 7 or above. This will avoid the Periodic Task interrupting the CompactBus I/O scan running at priority level 6. The priorities the user selects for Periodic/Event Tasks will affect both I/O throughput and program scan. For high speed applications the user needs to determine what is more important for his application, I/O throughput or program scan, and adjust the priorities accordingly. For applications where speed is NOT of great concern, this will not be an issue. 28
Section 8: System Overhead Time Slice Summary: The System Overhead Time Slice, or SOTS, 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 background time to communicate to HMIs, perform trending, execute messaging and perform serial port communications. Setting it too low can starve your communications to HMI, trending, messaging and serial communications. Setting it too high can increase the scan time of the programs in the continuous task beyond what is acceptable for the application. Changes made in Logix V16 that affects the way the SOTS works are also discussed. For RSLogix5000 the default value is set to 20% and can be changes in the Properties of the Controller on the Advanced tab. 1 The formula used for calculating the time slice ists % = 100, which means that CT + 1 100 CT = 1, where TS% is the time slice in percent, and CT is the amount of time TS % 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. 29
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. The SOTS can only preempt or interrupt the continuous task. When the SOTS preempts the continuous task it can only perform the preemption for 1ms before it must return to the continuous task. That is the SOTS can only run in 1ms intervals of time. If there is no continuous task in the controller the SOTS will run in the null time that is when no periodic, event, or motion tasks are running. Changes to the %SOTS will only have an effect on the controller communications performance if there is a continuous task present. If you have only periodic, event, or motion tasks in the application, changes to the %SOTS will have no effect. Examples Example 1: The project consists of just one continuous task. There are no periodic tasks or motion. SOTS is set to 10%. For each 1 msec of background time, the continuous task runs for 9 ms. Continuous Task CT CT Background Task BT BT 0 1 2 3 4 5 6 7 8 9 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. 30
Example 2: The project consists of just one continuous task. There are no periodic tasks or motion. SOTS is set to 20%. Continuous Task CT CT CT CT Background Task BT BT BT BT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Time (ms) Figure 2 The continuous task executes for 4 of every 5 ms, and the background task executes every 5 ms. 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. SOTS is set to 10%. Continuous Task 2 3 4 5 6 7 8 9 1 Background Task BT Periodic Task PT PT PT 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 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 SOTS 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% SOTS 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 31
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. 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. SOTS is set to 10%. There are 5 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). Continuous Task CT CT CT CT Background Task Periodic Task 1 2 3 PT PT PT PT PT PT Motion Task MT MT MT MT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Time (ms) Figure 4 From the numbers on the Periodic task above: 1. The periodic task s first scheduled occurence at the 2 ms mark was delayed by 0.5 ms due to the motion task running. The second occurence at 4 ms ran as scheduled. 2. The periodic task s third scheduled occurence at the 6 ms mark 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. 3. The periodic task s next scheduled occurrence 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 s occurrence at 12ms is then delayed by an additional 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. 32
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. 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. Changes to the System Overhead Time Slice in Logix Release V16 In the V16 release of all Logix controllers there were 2 changes made to how the System Overhead Time Slice or SOTS works. It is important to know how these changes will effect your application, specifically if you are migrating forward from older firmware revisions. The first change can be seen by looking at the Advanced tab of the Controller Properties. The area that is circled tells the controller how to use the SOTS when it is executed. Run Continuous Task: This is how the SOTS worked prior to V16. When the SOTS was triggered to execute and there was no communication or background tasks to process the controller would return to the continuous task immediately. 33
Reserve for Systems Task, eg Communications: This is a new option added with the release of V16. With this setting active the controller will spend the entire 1ms in the SOTS whether it has communications or background tasks to perform, before returning back to the continuous task. This feature is intended to be used as a design and test tool allowing a user to simulate a communication load on the controller during design and programming before HMIs, controller to controller messaging, etc are up and running. The other change made in V16 was how the %SOTS value was calculated. In V15 and earlier the %SOTS would be calculated as follows in the table below: SOTS Setting Time Allocated to the SOTS Time Allocated to the Continuous Task 10% 1ms 9ms 20% 1ms 4ms 25% 1ms 3ms 33% 1ms 2ms 50% 1ms 1ms 60% 1ms < 1ms 70% 1ms < 1ms 80% 1ms < 1ms 90% 1ms < 1ms In V16 the %SOTS would be calculated as follows in the table below: SOTS Setting Time Allocated to the SOTS Time Allocated to the Continuous Task 10% 1ms 9ms 20% 1ms 4ms 25% 1ms 3ms 33% 1ms 2ms 50% 1ms 1ms 66% 2ms 1ms 75% 3ms 1ms 80% 4ms 1ms 90% 9ms 1ms The tables show that in V16 you will actually see a benefit of setting the SOTS% to a value greater than 50%. Earlier it is stated that the SOTS can only run in 1ms intervals of time, but the table shows that at a setting of 90% the time allocated to the SOTS will be 9ms. The SOTS in this case is given 9 1ms intervals of consecutive time. Now when you put both of these changes to the SOTS together you can see drastic changes in continuous task performance. This will be outlined in the tables below. A simple program was created that has only a Continuous Task with a loop to create a 10ms task scantime. 34
Table 1 (During unused System Overhead Time Slice, Run Continuous Task selected): SOTS Setting Continuous Task Scan time 10% 11.366ms 20% 11.378ms 30% 11.614ms 40% 11.666ms 50% 11.670ms 60% 11.678ms 70% 11.756ms 80% 11.654ms 90% 11.610ms Note: This is about the same performance you would see in V15 and earlier versions. Table 2 (During unused System Overhead Time Slice, Reserve for System Tasks, eg Communications selected): SOTS Setting Continuous Task Scan time 10% 12.342ms 20% 13.464ms 30% 15.458ms 40% 17.644ms 50% 20.862ms 60% 26.064ms 70% 34.442ms 80% 51.554ms 90% 112.440ms Note: 1. You can see the drastic effect this has on the continuous task s scantime. 2. The values in Table 1 could approach the values seen in Table 2 if there is enough communication occurring in the controller to consume the SOTS s 1ms interval of time. 35
Section 9: Limitations Imposed by Connections Summary: The CompactLogix system uses connections to establish a communication link between two devices. This includes controllers, communication modules, input/output modules, produced/consumed tags and messages. You indirectly determine the number of connections that the Logix controller requires when configuring the controller to communicate with other devices in the system. Each module in the CompactLogix system supports a limited number of active connections. Take these connection limits into account when designing your system. An alternative to calculating these values manually is the EtherNet/IP Capacity Tool, available at www.ab.com/go/iatools Section 9a: 1769-L3x Family 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/IP 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 Example: To determine the total number of connections used on a CompactLogix processor 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 in your controller, add the individual results from steps 1 thru 7 Total Connections used by CompactLogix controller Note: It is not recommended to use all 32 connections on the built in Network ports. 36
Section 9b:1768-L4X Family Device Total Number of Connections Total Number of Connected/Cached Buffers Total Number of Unconnected/Uncached Buffers 1769 L4x Controller 250 32 3 fixed incoming / 10-40 expandable outgoing **1768-CNB(R) module *48 **1768-ENBT V1 module 64 128 **1768-ENBT V2 module *Supports any combination of scheduled, unscheduled, cached or uncached ** Each of these connections must be subtracted from the 250 total controller connections 128 128 Example: How to determine the total number of connections used on a network communication module 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 a network communication module: Add the individual results from steps 1 thru 7 Total Connections used by network communication module Note: The 1768-L4X will support up to two network communication modules. Remember not to exceed the total number of L4X controller connections. Also, it is not recommended to use all connections available on a communication module. 37
Section 9c: 5370 L3 Family With the 5370 L3 Family of processors, you only need to consider the number of EtherNet/IP nodes on the network when sizing your system Processor L30ER-NSE L30ER L30ERM L33ER L33ERM L36ERM EtherNet/IP I/O Nodes 16 16 16 32 32 48 The information related to connections and the 5370 L3 family is included below for reference purposes. Device Total Number of Connections Total Number of Cached Connections Total Number of Unconnected Buffers 5370 L3 Controller/EtherNet/IP port 256 32 10-40(10 default) Example: How to determine the total number of connections used on a network communication module 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 a network communication module: Add the individual results from steps 1 thru 7 Total Connections used by network communication module 38
Section 10: CompactLogix on Ethernet Overview Guidelines: Performance of an Ethernet network is based upon the following: Identifying and counting the number of connections Calculating the packets per second for loading. Estimating maximum input and output times Note: You can use the EtherNet/IP Capacity Tool, available at www.ab.com /go/iatools to size your system. Section 10a: 1769-L3x Family 1769-L3X 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 760 packets per second (Class 3, Messaging, HMI, OPC combined) Up to 32 CIP I/O connections Up to 64 TCP connections 2 ms minimum RPI 512 Byte maximum packet size EtherNet/IP Rules: As the packet size increases the number of packets per second decreases. Producer/Consumer packets tend to be much larger than I/O packets and may reduce the maximum packets per second NOTE: Class 1 and Class 3 values of packets per second (PPS) listed above are maximums. It is not possible for the 1769-L3X to handle 760 PPS of HMI traffic while also handling 4000 PPS of I/O traffic. When the 1769-L3X is required to handle both class 1 and class 3 traffic reference the graph listed below to determine if the requested class 1 and 3 traffic is possible. 39