1756 pm005 - en P
1756 pm005 - en P
1756 pm005 - en P
Activities including installation, adjustments, putting into service, use, assembly, disassembly, and maintenance are required to be carried out by
suitably trained personnel in accordance with applicable code of practice. If this equipment is used in a manner not specified by the manufacturer,
the protection provided by the equipment may be impaired.
In no event will Rockwell Automation, Inc. be responsible or liable for indirect or consequential damages resulting from the use or application of this
equipment.
The examples and diagrams in this manual are included solely for illustrative purposes. Because of the many variables and requirements associated
with any particular installation, Rockwell Automation, Inc. cannot assume responsibility or liability for actual use based on the examples and
diagrams.
No patent liability is assumed by Rockwell Automation, Inc. with respect to use of information, circuits, equipment, or software described in this
manual.
Reproduction of the contents of this manual, in whole or in part, without written permission of Rockwell Automation, Inc., is prohibited.
Throughout this manual, when necessary, we use notes to make you aware of safety considerations.
WARNING: Identifies information about practices or circumstances that can cause an explosion in a hazardous environment, which may lead to
personal injury or death, property damage, or economic loss.
ATTENTION: Identifies information about practices or circumstances that can lead to personal injury or death, property damage, or economic
loss. Attentions help you identify a hazard, avoid a hazard, and recognize the consequence
Important: Identifies information that is critical for successful application and understanding of the product.
SHOCK HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that dangerous voltage may be
present.
BURN HAZARD: Labels may be on or inside the equipment, for example, a drive or motor, to alert people that surfaces may reach dangerous
temperatures.
ARC FLASH HAZARD: Labels may be on or inside the equipment, for example, a motor control center, to alert people to potential Arc Flash. Arc
Flash will cause severe injury or death. Wear proper Personal Protective Equipment (PPE). Follow ALL Regulatory requirements for safe work
practices and for Personal Protective Equipment (PPE).
Allen-Bradley, Rockwell Software, Rockwell Automation, and TechConnect are trademarks of Rockwell Automation, Inc.
Trademarks not belonging to Rockwell Automation are property of their respective companies.
Summary of changes
This manual contains new and updated information. There are a number of minor
changes throughout this publication that were made to clarify existing
information. The major changes are listed in the following table.
Change Topic
Updated the list of controllers in the table. Select Controller Tasks on page 11
Added the CompactLogix 5480 controller to the Controller Choose the Trigger for an Event Task on page 35
applicable event task table.
Chapter 1
Chapter 2
This manual is one of a set of related manuals that show common procedures for
programming and operating Logix5000 controllers.
The term Logix5000 controller refers to any controller that is based on the
Logix5000 operating system.
Studio 5000 environment The Studio 5000 Automation Engineering & Design Environment combines
engineering and design elements into a common environment. The first element is
the Studio 5000 Logix Designer application. The Logix Designer application is
the rebranding of RSLogix 5000 software and will continue to be the product to
program Logix5000 controllers for discrete, process, batch, motion, safety, and
drive-based solutions.
Resource Description
Industrial Automation Wiring and Grounding Guidelines , Provides general guidelines for installing a Rockwell
publication 1770-4.1 Automation industrial system.
Product Certifications webpage, available Provides declarations of conformity, certificates, and other
at http://ab.rockwellautomation.com certification details.
You can view the Rockwell Automation End-User License Agreement ("EULA")
by opening the License.rtf file located in your product's install folder on your hard
drive.
Trademark Notices
Other Trademarks
All other trademarks are the property of their respective holders and are hereby
acknowledged.
Warranty
This product is warranted in accordance with the product license. The products
performance may be affected by system configuration, the application being
performed, operator control, maintenance, and other related factors. Rockwell
Automation is not responsible for these intervening factors. The instructions in
this document do not cover all the details or variations in the equipment,
procedure, or process described, nor do they provide directions for meeting every
possible contingency during installation, operation, or maintenance. This
products implementation may vary among users.
This document is current as of the time of release of the product; however, the
accompanying software may have changed since the release. Rockwell Automation,
Inc. reserves the right to change any information contained in this document or
the software at any time without prior notice. It is your responsibility to obtain the
most current information available from Rockwell when installing or using this
product.
Environmental Compliance
Contact Rockwell
Manage Tasks
The default project provides a single task for all your logic. Although this is
Introduction
sufficient for many applications, some situations may require more than one task.
Select Controller Tasks A Logix5000 controller supports multiple tasks to schedule and prioritize the
running of your programs based on specific criteria. This balances the processing
time of the controller.
1768-L43 16
1768-L45
1769-L16x 32
1769-L18x
1769-L19x
1769-L24x
1769-L27x
1769-L30x
1769-L33x
1769-L36x
1769-L37x
Use Caution in the Number of Typically, each task takes controller time away from the other tasks. If you have
too many tasks, then:
Tasks That You Use
The continuous task may take too long to complete.
Other tasks may overlap. If a task is interrupted too frequently or too long,
it may not finish running before it is triggered again.
Prioritize Periodic Although a project can contain multiple tasks, the controller runs only one task at
and Event Tasks a time. If a periodic or event task is triggered while another task is running, the
priority of each task indicates what the controller should do.
Additional Considerations As you estimate the execution interrupts for a task, consider the following.
Consideration Description
Motion planner The motion planner interrupts all user tasks, regardless of their priority.
The number of axes and coarse update period for the motion group affect how long and how
often the motion planner runs.
If the motion planner is running when a task is triggered, the task waits until the motion
planner is done.
If the coarse update period occurs while a task is running, the task pauses to let the motion
planner run.
I/O task CompactLogix, FlexLogix, and DriveLogix controllers use a dedicated periodic task to process I/O
data. This I/O task:
Does not show up in the Tasks folder of the controller.
Does not count toward the task limits for the controller.
Operates at priority 6.
Runs at the fastest RPI you have scheduled for the system.
Runs for as long as it takes to scan the configured I/O modules.
As you assign priorities to your tasks, consider the I/O task.
If you want a task to Then assign one of these priorities
Interrupt or delay I/O processing 15
Share controller time with I/O processing 6
Let I/O processing interrupt or delay the task 715
System overhead System overhead is the time that the controller spends on unscheduled communication.
Unscheduled communication is any communication that you do not configure through the
I/O configuration folder of the project, such as Message (MSG) instructions and
communication with HMIs or workstations.
System overhead interrupts only the continuous task.
The system overhead time slice specifies the percentage of time (excluding the time for
periodic or event tasks) that the controller devotes to unscheduled communication.
The controller performs unscheduled communication for up to 1 ms at a time and then
resumes the continuous task.
Continuous task You do not assign a priority to the continuous task. It always runs at the lowest priority. All
other tasks interrupt the continuous task.
Example The following example shows the execution of a project with three user tasks.
Description
Initially, the controller runs the motion planner and the I/O task (if one exists).
After running the continuous task for 4 ms, the controller triggers the system overhead.
The period for periodic task 1 expires (12 ms), so the task interrupts the continuous task.
After running the continuous task again for 4 ms, the controller triggers the system overhead.
The Studio 5000 environment includes a task monitor tool on the distribution
CD. You can use this tool to analyze how tasks are running.
Leave Enough Time for Unscheduled communication occurs only when a periodic or event task is not
running. If you use multiple tasks, make sure that the scan times and execution
Unscheduled intervals leave enough time for unscheduled communication. Use the following
Communication methods to plan enough unscheduled communication time.
1. Verify that the execution time of a highest priority task is significantly less
than its specified period.
2. Verify that the total execution time of all your tasks is significantly less than
the period of the lowest priority tasks.
The execution time of the highest priority task (Task 1) is significantly less
than its specified period (20 ms is less than 80 ms).
The total execution time of all tasks is significantly less than the specified
period of the lowest priority task (50 ms is less than 100 ms).
Adjust the period of the tasks as needed to get the best balance between
running your logic and servicing unscheduled communication.
If your project has a continuous task, unscheduled communication occurs as
a percentage of controller time (excluding the time for periodic or event
tasks).
Avoid Overlaps An overlap is a condition where a task (periodic or event) is triggered while the
task is still running from the previous trigger.
Important: If an overlap occurs, the controller disregards the trigger that caused the overlap. In other words, you might
miss an important execution of the task.
Description
Task trigger occurs.
Task runs.
Task trigger occurs.
Task runs.
Task trigger occurs.
Task runs.
Overlap occurs. Task is triggered while it is still running.
The trigger does not restart the task. The trigger is ignored.
Each task requires enough time to finish before it is triggered again. Make sure that
the scan time of the task is significantly less than the rate at which the trigger
occurs. If an overlap occurs, reduce the frequency at which you trigger the task.
Manually Check for Overlaps Follow these steps to manually see if overlaps are occurring for a task.
The Task Overlap Count shows the number of overlaps since the counter
was last reset.
3. Click OK.
To write logic to check for an overlap, use a Get System Value (GSV) instruction
to monitor either of these objects.
(1) Battery for 1756-L6X, 1769-L2X, and 1769-L3X controllers. ESM for
1756-L7X and CompactLogix 5370 series controllers.
Example: 1. The GSV instruction sets Task_2_Status = Status attribute for Task_2 (DINT value).
3. If Condition_1 = 1, then clear the bits of the Status attribute for Task_2:
The SSV instruction sets the Status attribute of Task_2 = Zero. Zero is a DINT tag with a value of 0.
Configure Output At the end of a task, the controller performs overhead operations (output
processing) for the I/O modules in your system. Although these operations are not
Processing for a Task the same as updating the modules, the output processing may affect the update of
the I/O modules in your system.
As an option, you can turn off this output processing for a specific task, which
reduces the elapsed time of that task.
Manually Configure Output Follow these steps to manually configure output processing.
Processing
4. Click OK.
Programmatically Configure To write logic to configure output processing for a task, use a
Set System Value (SSV) instruction. Access the attribute of the Task object for the
Output Processing
task.
EXAMPLE
Inhibit a Task By default, each task runs based on its trigger (event, periodic, or continuous). As
an option, you can prevent a task from running when its trigger occurs (that is,
inhibit the task). This is useful when you test, diagnose, or start up your project.
Example: During the commissioning of a system that uses several tasks, you can first test each task individually.
Inhibit all the tasks except one, and then test that task.
Once the task meets your requirements, inhibit it and uninhibit a different task.
Continue this process until you have tested all your tasks.
If a task is inhibited, the controller still prescans the task when the controller
transitions from Program to Run or Test mode.
Manually Inhibit or Uninhibit a Follow these steps to manually inhibit or uninhibit the running of a task.
Task 1. In the Controller Organizer, right-click MainTask and choose Properties.
4. Click OK.
Programmatically Inhibit or To write logic to inhibit or uninhibit a task, use a Set System Value (SSV)
instruction to access the attribute of the Task object for the task.
Uninhibit a Task
Attribute Data Type Instruction Description
InhibitTask DINT GSV Prevents the task from running.
SSV To Set the attribute to
Enable the task 0 (default)
Inhibit (disable) the task 1 (or any non-zero value)
EXAMPLE
If Condition_1 = 0 then let Task_2 run.
1. The ONS instruction limits the true run of the SSV instruction to one scan.
2. The SSV instruction sets the InhibitTask attribute of Task_2 = 0. This uninhibits the task.
1. In the Controller Organizer, right-click the Tasks folder and choose New
Task.
Topic Description
Name Type a name for the task.
Description Type an optional description for the task.
Type Choose Event for the task type.
Trigger Choose a trigger for the task.
Tag Choose a tag if the field is active for the selected trigger.
Topic Description
Execute Task If No Event Occurs Within Check the box and type a time period that must elapse before
a task can run.
Priority Enter the task priority value.
Watchdog Type the watchdog time for the task.
3. Click OK.
Create a Periodic Task A periodic task performs a function or functions at a specific rate.
Important: Be sure that the time period is longer than the sum of the run times of all the programs assigned to the
task.
If the controller detects that a periodic task trigger occurs for a task that is already operating, a minor
fault occurs (overlap).
Priorities and run times of other tasks may also cause an overlap.
Topic Description
Type Choose Periodic (default) for the type of task.
Period Type a value for when (or at what time interval) you want
the task to run.
Priority Enter the task priority value.
Watchdog Type the watchdog time for the task.
4. Click OK.
Language Switching In versions 17 and later of the application, you can display project documentation,
such as tag descriptions and rung comments, for any supported localized language.
You can store project documentation for multiple languages in a single project file
rather than in language-specific project files. You define all the localized languages
that the project will support and set the current, default, and optional
custom-localized language. The software uses the default language if the current
language's content is blank for a particular component of the project. However,
you can use a custom language to tailor documentation to a specific type of project
file user.
Enter the localized descriptions in your project, either when programming in that
language or by using the import/export utility to translate the documentation
offline and then import it back into the project. When you enable language
switching, you can dynamically switch between languages as you use the software.
Adjust the A Logix5000 controller communicates with other devices, I/O modules,
System-overhead Time Slice controllers, HMI terminals, and so forth, at either a specified rate (scheduled) or
when there is processing time available to service the communication
(unscheduled).
The following table shows the ratio between the continuous task and service
communication at various system overhead time slices.
At this time slice The continuous tasks runs Service communication occurs for up to
10% 9 ms 1 ms
20% 4 ms 1 ms
25% 3 ms 1 ms
33% 2 ms 1 ms
50% 1 ms 1 ms
66% 1 ms 2 ms
75% 1 ms 3 ms
80% 1 ms 4 ms
90% 1 ms 9 ms
As shown in the table, for version 16 and later of the application, the system
overhead time slice at 50% stays fixed at 1 ms.
The same applies for 66% and higher, except that there are multiple 1 ms intervals.
For example, at 66% there are two 1 ms intervals of consecutive time and at 90%
there are nine 1 ms intervals of consecutive time.
Configure the System-overhead Follow these steps to configure the system-overhead time slice.
Time Slice 1. On the Online toolbar, click the controller properties icon.
4. Use either Run Continuous Task (default) or Reserve for System Tasks.
Select the Run Continuous Task radio button when there are no
communication or background tasks to process; the controller
immediately returns to the continuous task.
Select the Reserve for System Task radio button to allocate the entire
1 ms of the system-overhead time slice when the controller has
communication or background tasks to perform before returning to the
continuous task. This lets you simulate a communication load on the
controller during design and programming before HMIs, controller to
controller messaging, and so forth, are set up. Use this setting for testing
purposes only.
5. Click OK.
Each task contains a watchdog timer that specifies how long a task can run before
Adjust the System
triggering a major fault.
Watchdog Time
If the watchdog timer reaches a configurable preset, a major fault occurs. Depending on the controller
fault handler, the controller might shut down.
The watchdog timer begins to run when the task is initiated and stops when
all the programs within the task have run.
If the task takes longer than the watchdog time, a major fault occurs. (The
time includes interruptions by other tasks.)
You can use the controller fault handler to clear a watchdog fault. If the
same watchdog fault occurs a second time during the same logic scan, the
controller enters Faulted mode, regardless of whether the controller fault
handler clears the watchdog fault.
Adjust the Watchdog Timer for Follow these steps to change the watchdog time of a task.
a Task
1. In the Controller Organizer, right-click Main Task and choose Properties.
3. Type a numeric value for the watchdog timeout for the task.
4. Click OK.
An event task, if configured correctly, interrupts all other tasks for the minimum
Introduction
amount of time required to respond to the event.
This section describes how to set up event tasks and lists considerations, such as a
higher priority task, that can affect the execution of an event task.
Choose the trigger for an Each event task requires a specific trigger that defines when the task is to run. The
following table reviews some of these triggers.
event task
To trigger an event task Use this trigger With these considerations
when
Digital input turns On or Off Module Input Data Only one input module can trigger a specific event task.
State Change The input module triggers the event task based on the
change of state (COS) configuration for the module. The COS
configuration defines which points prompt the module to
produce data if they turn On or Off. This production of data
(due to COS) triggers the event task.
Typically, enable COS for only one point on the module. If
you enable COS for multiple points, a task overlap of the
event task may occur.
Analog module samples data Module Input Data Only one input module can trigger a specific event task.
State Change The analog module triggers the event task after each real
time sample (RTS) of the channels.
All the channels of the module use the same RTS.
Controller gets new data via a Consumed Tag Only one consumed can trigger a specific event task.
consumed tag Typically, use an IOT instruction in the producing controller
to signal the production of new data. The IOT instruction
sets an event trigger in the producing tag. This trigger
passes to the consumed tag and triggers the event task.
When a consumed tag triggers an event task, the event task
waits for all the data to arrive before the event task runs.
Registration input for an axis Axis Registration For the registration input to trigger the event task, first run
turns On (or Off) 1 or 2 a Motion Arm Registration (MAR) instruction. This lets the
axis detect the registration input and in turn trigger the
event task.
Once the registration input triggers the event task, run the
MAR instruction again to re-arm the axis for the next
registration input.
If the scan time of your normal logic is not fast enough to
re-arm the axis for the next registration input, consider
placing the MAR instruction within the event task.
The following table lists some example situations for event tasks and the
corresponding triggers.
For this example situation Use an event task with this trigger
A packaging line glues boxes closed. When a box arrives at the gluing Module Input Data State Change
position, the controller must immediately run the gluing routine.
A production line uses a proximity sensor to detect the presence of a part. Module Input Data State Change
Because the proximity sensor is on for only a very short time (pulse), the
continuous task might miss the off to on transition of the sensor.
In an engine test stand, you must capture and archive each sample of Module Input Data State Change
analog data.
Controller A produces an array of production data for Controller B. You Consumed Tag
want to make sure that Controller B does not use the values while
Controller A is updating the array.
In a line that packages candy bars, you have to make sure that the Axis Registration 1 or 2
perforation occurs in the correct location on each bar. Each time the
registration sensor detects the registration mark, check the accuracy of an
axis and perform any required adjustment.
At the labeling station of a bottling line, you want to check the position of Axis Watch
the label on the bottle. When the axis reaches the position that is defined
as the watch point, check the label.
A gluing station must adjust the amount of glue it applies to compensate Motion Group Execution
for changes in the speed of the axis. After the motion planner runs, check
the command speed of the axis and vary the amount of glue, if needed.
In a production line, if any of the programs detect an unsafe condition the EVENT instruction
entire line must shut down. The shutdown procedure is the same
regardless of the unsafe condition.
The triggers that you can use for an event task vary depending on your controller
type.
Important: The Logix Designer application may let you configure a trigger for an event task that your controller
does not support. The project verifies and successfully downloads, but the event task does not run.
Module Input Data State To trigger an event task based on data from an input module, use the Module
Input Data State Change trigger.
Change Trigger
When the task is done, do not update digital outputs in the local chassis.
How an I/O Module Triggers The following terms apply to the operation of an input module.
an Event Task
Term Definition
Multicast A mechanism where a module sends data on a network that is simultaneously received by
more than one listener (device). Describes the feature of the Logix5000 I/O line that supports
multiple controllers receiving input data from the same I/O module at the same time.
Requested packet interval The RPI specifies the interval that a module multicasts its data. For example, an input
(RPI) module sends data to a controller at the RPI that you assign to the module.
The range is 0.2750 ms.
When the specified time frame elapses, the module multicasts its data. This is also called
a cyclic update.
Real time sample (RTS) The RTS specifies when an analog module scans its channels and multicasts the data (update
the input data buffer then multicast).
The RPI specifies when the module multicasts the current contents of the input data
buffer without scanning (updating) the channels.
The module resets the RPI timer each time an RTS transfer occurs.
Change of state (COS) The COS parameter instructs a digital input module to multicast data whenever a specified
input point transitions from On Off or Off On.
You enable COS on a per-point basis.
When any point that is enabled for COS receives the specified change, the module
multicasts the data for all its points.
By default, COS is enabled for both On Off and Off On changes for all points.
You must specify an RPI regardless of whether you enable COS. If a change does not occur
within the RPI, the module sends its data at the RPI.
The following table summarizes when an input module multicasts its data and
triggers an event task within its own chassis.
If the input And Then it multicasts data And it triggers an event task
module is
Digital COS is enabled for When any point that is enabled for COS When any point that is enabled
any point on the receives the specified change for COS receives the specified
module At the RPI change
If the module is in a remote chassis, only the RPI determines when the controller
receives the data and event trigger over the network.
Important: If you use a digital module to trigger an event task, configure only one point on the module for COS. If you
configure multiple points, a task overlap could occur.
If you want this Then configure the input module like this (Point 0 is an example)
Make Sure Your Module Can To use an input module to trigger an event task, the module must support event
task triggering. If the module is in a remote location, the associated
Trigger an Event Task
communication modules must also support event triggering.
The following table lists Rockwell Automation modules that have been tested for
event task triggering. Some third-party modules may also support event task
triggering. Before you use a third-party module, check with the supplier to validate
the operation of the module.
Category Modules
Digital I/O modules that support change of state 1756-IA8D 1756-IA16
1756-IA16I 1756-IA32
1756-IB16 1756-IB16D
1756-IB16I 1756-IB16ISOE
1756-IB32 1756-IC16
1756-IG16 1756-IH16I
1756-IH16ISOE 1756-IM16I
1756-IN16 1756-IV16
1756-IV32
Analog I/O modules that support real time sample 1756-IF16 1756-IF4FXOF2F/A
1756-IF6CIS 1756-IF6I
1756-IF8 1756-IR6I
1756-IT6I 1756-IT6I2
Communication modules that provide rack-optimized 1756-CNB/A 1756-CNB/B
connections 1756-CNB/D 1756-CNBR/A
1756-CNBR/B 1756-CNBR/D
1756-DNB 1756-ENBT/A
1756-SYNCH/A 1784-PCIDS/A
Generic I/O modules that conform to CIP event 1756-MODULE
communication 1789-MODULE
Checklist for an Input Use the following checklist when creating an Input Event Task.
Event Task For This Make Sure You
1. Input module type For the fastest response, use these modules:
For fastest digital response, use a 1756-IB32/B module.
For fastest analog response, use a 1756-IF4FXOF2F module.
2. I/O module location Place the module that triggers the event and the modules that respond to the event
(outputs) in the same chassis as the controller.
Remote modules add network communication to the response time.
3. Number of local Limit the number of modules in the local chassis.
modules Additional modules increase the potential for backplane delays.
4. Change of state (COS) If a digital device triggers the event, enable COS for only the point that triggers the
event task.
Enable change of state for the type of transition that triggers the task, either Off
On, On Off, or both.
If you configure COS for both Off On and On Off, the point triggers an event
task whenever the point turns on or off. Make sure the duration of the input is
longer than the scan time of the task. Otherwise an overlap could occur.
Disable (clear) COS for the remaining points on the input module. If you configure
multiple points on a module for COS, each point could trigger the event task. This
could cause an overlap.
5. Task priority Configure the event task as the highest priority task.
If a periodic task has a higher priority, the event task may have to wait until the periodic
task is done.
6. Motion planner The motion planner interrupts all other tasks, regardless of their priority.
The number of axes and coarse update period for the motion group effect how long
and how often the motion planner executes.
If the motion planner is executing when a task is triggered, the task waits until the
motion planner is done.
If the coarse update period occurs while a task is executing, the task pauses to let
the motion planner execute.
7. Number of event Limit the number of event tasks.
tasks Each additional task reduces the processing time that is available for other tasks. This
could cause an overlap.
8. Automatic Output For an event task, you can typically disable automatic output processing (default). This
Processing reduces the elapsed time of the task.
9. IOT instruction Use an IOT instruction for each output module that you reference in the event task.
The IOT instruction overrides the RPI for the module and immediately sends the data.
Example Input Event Task As parts move past a diverter location, the controller logic determines whether to
turn on the diverter. Once the diverter is on, the controller must also turn it off
before the next part is in that position. Because of the speed of the line, an event
task controls the diverter.
The diverter photoeye (point 0) is configured for change of state for both Off and
On. This lets the photoeye trigger the event task when it turns on and when it
turns off.
The event task uses the following logic to control the diverter.
Estimate Throughput To estimate the throughput time from input to output (screw to screw), use the
following worksheet.
Consideration Value
1. What is the input filter time of the module that triggers the event task? s
This is typically shown in milliseconds. Convert it to microseconds (s).
2. What is the hardware response time for the input module that triggers the event s
task?
Make sure you use the appropriate type of transition (Off On or
On Off). See Nominal hardware response times for the 1756 I/O
modules most commonly used with Event tasks later in this section.
3. What is the backplane communication time? s
If chassis size is Use this value (worst case)
4 slot 13 s
7 slot 22 s
10 slot 32 s
13 slot 42 s
17 slot 54 s
4. What is the total execution time of the programs of the event task? s
5. What is the backplane communication time? (Same value as step 3.) s
6. What is the hardware response time of the output module. s
7. Add steps 1...6. This is the minimum estimated throughput, where execution of the s
motion planner or other tasks do not delay or interrupt the event task.
8. What is the scan time of the motion group? s
9. What is the total scan time of the tasks that have a higher priority than this event s
task (if any)?
10 Add steps 7...9. This is the nominal estimated throughput, where execution of the s
. motion planner or other tasks delay or interrupt the event task.
The following table lists nominal hardware response times for 1756 I/O modules
with event tasks.
Example Estimate The following example shows the throughput considerations for the system
shown in the following illustration. In this example, the throughput is the time
Throughput
from when the input turns on to when the output turns on.
Consideration Value
1. What is the input filter time of the module that triggers the event task? 0 s
This is typically shown in milliseconds. Convert it to microseconds (s).
2. What is the hardware response time for the input module that triggers the 330 s
event task?
Make sure you use the appropriate type of transition (Off On or
On Off). See the table, earlier in this section, that lists nominal
hardware response times for the 1756 I/O modules most commonly
used with Event tasks.
3. What is the backplane communication time? 13 s
If chassis size is Use this value (worst case)
4 slot 13 s
7 slot 22 s
10 slot 32 s
13 slot 42 s
17 slot 54 s
4. What is the total run time of the programs of the event task? 400 s
5. What is the backplane communication time? (Same value as step 3.) 13 s
6. What is the hardware response time of the output module. 51 s
7. Add steps 1...6. This is the minimum estimated throughput, where 807 s
execution of the motion planner or other tasks do not delay or interrupt the
event task.
8. What is the scan time of the motion group? 1130 s
9. What is the total scan time of the tasks that have a higher priority than this 0 s
event task (if any)?
10. Add steps 7...9. This is the nominal estimated throughput, where execution 1937 s
of the motion planner or other tasks delay or interrupt the event task.
Additional Considerations The following considerations affect the scan time of the event task, which affects
the speed at which it can respond to the input signal.
Consideration Description
Amount of code in the event task Each logic element (rung, instruction, Structured Text construct, and so forth)
adds scan time to the task.
Task priority If the event task is not the highest priority task, a higher priority task may delay
or interrupt the execution of the event task.
CPS and UID instructions If one of these instructions are active, the event task cannot interrupt the
currently running task. (The task with the CPS or UID.)
Motion Group Trigger To couple the running of an event task with the running of the motion planner,
use the Motion Group Execution trigger.
When the task is done, do not update digital outputs in the local chassis.
The base update period for the motion group triggers the running of both
the motion planner and the event task.
Because the motion planner interrupts all other tasks, it runs first. If you
assign the event task as the highest priority task, it runs immediately after
the motion planner.
This timing diagram shows the relationship between the motion planner and the
event task.
The Base Update Period for the motion group triggers both the motion planner
and the event task. See the online help for more information on the Motion
Group Properties dialog box.
Checklist for a Motion The following is the checklist for a motion group task:
Group Task For This Make Sure You
1. Scan time Make sure the scan time of the event task is significantly less than the base update
period of the motion group. Otherwise, a task overlap could occur.
2. Task priority Configure the event task as the highest priority task.
If a periodic task has a higher priority, the event task may have to wait until the periodic
task is finished.
3. Number of event Limit the number of event tasks.
tasks Each additional task reduces the processing time that is available for other tasks. This
could cause an overlap.
4. Automatic output For an event task, you can typically disable automatic output processing (default). This
processing reduces the elapsed time of the task.
To let the registration input of an axis trigger an event task, use the Axis
Axis Registration Trigger Registration 1 or Axis Registration 2 triggers.
When the task is done, do not update digital outputs in the local chassis.
When the specified registration input reaches its trigger condition, it triggers the
event task.
In the configuration of the event task, specify which registration input you
want to trigger the task. Choose either Axis Registration 1 or Axis
Registration 2.
You must first arm the registration input using a Motion Arm
Registration (MAR) instruction.
In the MAR instruction, the Trigger Condition operand defines which
transition of the registration input (Off On or On Off) triggers the
event task.
Once the registration input triggers the task, you have to re-arm the
registration input.
This timing diagram shows the relationship between the registration input and the
event task.
Checklist for an Axis The following is a checklist for an axis registration task:
Registration Task
For This Make Sure You
1. Registration input Arm the registration input (MAR instruction). This lets the axis detect the registration
input and trigger the event task.
Initially, arm the registration input to detect the first trigger condition.
Re-arm the registration input after each execution of the event task.
Re-arm the registration input fast enough to detect each trigger condition.
If your normal logic is Then
Fast enough to re-arm the registration Arm the registration input within your
input between intervals of the trigger normal logic, if desired.
condition
For example, normal logic always
completes at least two scans between
registration inputs.
Not fast enough to re-arm the registration Arm the registration input within the
input event task.
2. Task priority Configure the event task as the highest priority task.
If a periodic task has a higher priority, the event task may have to wait until the
periodic task is finished.
3. Number of event tasks Limit the number of event tasks.
Each additional task reduces the processing time that is available for other tasks. This
could cause an overlap.
4. Automatic output For an event task, you can typically disable automatic output processing (default). This
processing reduces the elapsed time of the task.
Example Axis Registration In a line that packages candy bars, you have to make sure that the perforation
Trigger occurs in the correct location on each bar.
Each time the registration sensor detects the registration mark, check the
accuracy of an axis and perform any required adjustment.
Due to the speed of the line, you have to arm the registration input within
the event task.
Continuous task
If Arm_Registration = 1 (system is ready to look for the registration mark) then
If Task_Status.0 = 1 then an EVENT instruction triggered the event task. In the continuous task, the EVENT runs to arm
registration for the first time.
The JMP instruction causes the controller to jump to the Arm LBL instruction. This skips all the logic of the routine
except the rung that arms registration for the axis.
Other logic
The MAR instruction runs each time the task runs and arms Axis_1 for registration.
The OTU instruction sets the EN bit of the MAR instruction = 0.
The MAR instruction is a transitional instruction.
For the MAR instruction to run, its rung-condition-in must go from false to true.
By first clearing the EN bit, the instruction responds as if its rung-condition-in changed from false to true.
The MAR instruction arms the axis for registration.
The controller does not clear the bits of the Status attribute once they are set. To use a bit for new status information,
you must manually clear the bit.
If Task_Status.0 = 1 then clear that bit.
The OTU instruction sets Task_Status.0 = 0.
The SSV instruction sets the Status attribute of THIS task (Task_1) = Task_Status. This includes the cleared bit.
Axis Watch Trigger To configure the watch position of an axis to trigger an event task, use the
Axis Watch trigger.
When the task is done, do not update digital outputs in the local chassis.
When the axis reaches the position that is specified as the watch position, it
triggers the event task.
You must first arm the axis for the watch position by using a Motion Arm
Watch (MAW) instruction.
In the MAW instruction, the Trigger Condition operand defines the
direction in which the axis must be moving to trigger the event task.
Once the axis reaches the watch position and triggers the event task, you
have to re-arm the axis for the next watch position.
This timing diagram shows the relationship between the watch position and the
event task.
Checklist for an Axis The following is a checklist for an axis watch task:
Watch Task For This Make Sure You
1. Watch position Use a MAW instruction to set up a watch position. This lets the axis trigger the event task
when it reaches the watch position.
Initially, arm the axis to detect the first watch position.
When the axis reaches the watch position and triggers the event task, re-arm the axis
for the next watch position.
Re-arm the axis fast enough to detect each watch position.
If your normal logic is Then
Fast enough to re-arm the axis between Arm the axis within your normal logic, if
intervals of the watch position desired.
(For example, normal logic always completes
at least two scans between watch positions.)
Not fast enough to re-arm the axis Arm the axis within the event task.
2. Task priority Configure the event task as the highest priority task.
If a periodic task has a higher priority, the event task may have to wait until the periodic
task is finished.
3. Number of event Limit the number of event tasks.
tasks Each additional task reduces the processing time that is available for other tasks. This could
cause an overlap.
4. Automatic output For an event task, you can typically disable automatic output processing (default). This
processing reduces the elapsed time of the task.
Example Axis Watch Trigger At the labeling station of a bottling line, you want to check the position of the
label on the bottle.
When the axis reaches the position that is defined as the watch point, check
the label and perform any required adjustment.
Due to the speed of the line, you have to arm axis for the watch position
within the event task.
The following logic arms and re-arms the axis for the watch position.
Continuous task
If Arm_Watch = 1 (system is ready to set up a watch position) then
the ONS instruction limits the EVENT instruction to one scan.
the EVENT instruction triggers Task_1 (event task).
If Task_Status.0 = 1 then an EVENT instruction triggered the event task. In the continuous task, the EVENT runs to set
up the watch position for the first time.
The JMP instruction causes the controller to jump to the Arm LBL instruction. This skips all the logic of the routine
except the rung that arms the axis for the watch position (MAW instruction).
Other logic
The MAW instruction runs each time the task runs and arms Axis_1 for the watch position.
The OTU instruction sets the EN bit of the MAW instruction = 0.
The MAW instruction is a transitional instruction.
To run the MAW instruction, its rung-condition-in must go from false to true.
By first clearing the EN bit, the instruction responds as if its rung-condition-in changed from false to true.
The MAW instruction arms the axis for the watch position.
The controller does not clear the bits of the Status attribute once they are set. To use a bit for new status information,
you must manually clear the bit.
If Task_Status.0 = 1 then clear that bit.
The OTU instruction sets Task_Status.0 = 0.
The SSV instruction sets the Status attribute of THIS task (Task_1) = Task_Status. This includes the cleared bit.
Consumed Tag Trigger To trigger an event task based on data from a consumed tag, use the Consumed
Tag trigger.
A produced/consumed tag relationship can pass an event trigger along with data
to a consumer controller. Typically, you use an Immediate Output (IOT)
instruction to send the event trigger to the consumer controller.
Description
In Controller A, logic updates the values of a produced tag.
Once the update is complete, the Controller A runs an IOT instruction to send the data and an event trigger
to Controller B.
Controller B consumes the new data.
After Controller B updates the consumed tag, it runs the event task.
The type of network between the controllers determines when the consuming
controller receives the new data and event trigger through the IOT instruction.
The following table lists the times when the consuming device receives the new
data and event trigger.
With this controller Over this network The consuming device receives the data
and event trigger
ControlLogix Backplane Immediately
EtherNet/IP network Immediately
ControlNet network Within the actual packet interval (API) of the
consumed tag (connection)
SoftLogix5800 You can produce and consume tags only over Within the actual packet interval (API) of the
a ControlNet network consumed tag (connection)
The following diagrams compare the receipt of data via an IOT instruction over
EtherNet/IP and ControlNet networks.
Maintain the Integrity of Data An event task with a consumed tag trigger provides a simple mechanism to pass
data to a controller and make sure that the controller doesnt use the data while
the data is changing.
Description
RPI occurs for the produced tag.
The produced tag transfers old data to the consuming controller.
The producer controller starts to update the values of the produced tag.
Although the producing controller runs the IOT instruction immediately after it
loads new data, the event task is not triggered (in the consuming controller) until
the consuming controller has received all the new data. This verifies that the
controller operates on a complete packet of new data.
Synchronize multiple Use the produced/consumed tag relationship to synchronize controllers. In this
case, the produced/consumed tag serves only as a triggering mechanism.
controllers
Description
The first controller runs an action with which other controllers need to stay synchronized.
When the action is done, the controller runs an IOT instruction. The IOT instruction uses a produced tag as
its target.
When controller A receives the produced tag, it runs its event task.
When controller B receives the produced tag, it runs its event task.
Checklist for the Producer The following is a checklist for the producer controller:
Controller
2. Produced tag On the New Tag dialog box for the produced tag, click Connection to open the Produced Tag Connection dialog box. Check
properties Send Data State Change Event to Consumer(s).
If you leave this checkbox cleared (unchecked), the producing controller triggers the event task at the end of any task that
automatically updates local outputs. In other words, the task scan triggers the event in addition to the IOT instruction.
3. IOT instruction Use an IOT instruction at the point in your logic where you want to trigger the event task.
The IOT instruction overrides the RPI for the tag and immediately sends the event trigger and the data of the tag.
Checklist for the Consumer The following is a checklist for the consumer controller:
Controller
For This Make Sure You
1. Buffer of data If you want to make sure that the controller does not use data from the consumed tag while the
data is changing, use a copy of the consumed tag. Use the event task to copy the data, as shown
in the Event Task diagram.
2. Task priority Configure the event task as the highest priority task.
If a periodic task has a higher priority, the event task may have to wait until the periodic task is
finished.
3. Number of event Limit the number of event tasks.
tasks Each additional task reduces the processing time that is available for other tasks. This could cause
an overlap.
4. Automatic output For an event task, you can typically disable automatic output processing (default). This reduces
processing the elapsed time of the task.
Example Producer Controller As parts move along a production line, each station requires production
specifications for the part at its station. To make sure that a station doesnt act on
and Consumer Controller
old data, an event task signals the arrival of new data for the next part.
Producer Controller This controller controls station 24 and produces data for the next station (station
25). To signal the transmission of new data, the controller uses the following
elements:
Produced_Tag
Ladder logic
Produced Tag Properties Produced_Tag is configured to update its event trigger through an IOT
instruction.
Ladder Logic If New_Data = on, then this occurs for one scan.
The CPS instruction sets Produced_Tag_1 = Source_Tag_1.
The IOT instruction updates Produced_Tag_1 and sends this update to the consuming controller (station 25).
When the consuming controller receives this update, it triggers the associated event task in that controller.
Consumer Controller
The controller at station 25 uses the data produced by station 24. To determine
when new data has arrived, the controller uses an event task.
Ladder Diagram in the Event When the event task runs, the CPS instruction sets Destination_Tag_1 = Consumed_Tag_1 (the values from the
producing controller). The remaining logic in this controller uses the values from Destination_Tag_1.
Task
EVENT Instruction Trigger To trigger an event task based on conditions in your logic, use the EVENT
Instruction Only trigger.
No tag is required.
The EVENT Instruction Only trigger requires that you use a Trigger Event Task
(EVENT) instruction to trigger the task. You can use an EVENT instruction
from multiple points in your project. Each time the instruction runs, it triggers the
specified event task.
Description
Program A runs an EVENT instruction.
The event task that is specified by the EVENT instruction runs one time.
Program B runs an EVENT instruction.
The event task that is specified by the EVENT instruction runs one time.
The controller does not clear the bits of the Status attribute once they are set.
To use a bit for new status information, you must manually clear the bit.
Use a Set System Value (SSV) instruction to set the attribute to a different
value.
Checklist for an EVENT The following is checklist for an EVENT instruction task:
Instruction Task For This Make Sure You
1. EVENT instruction Use a Trigger Event Task (EVENT) instruction at each point in your logic that you
want to trigger the event task.
2. Task priority Configure the event task as the highest priority task.
If a periodic task has a higher priority, the event task may have to wait until the
periodic task is finished.
3. Number of event tasks Limit the number of event tasks.
Each additional task reduces the processing time that is available for other tasks.
This could cause an overlap.
4. Automatic output For an event task, you can typically disable automatic output processing (default).
processing This reduces the elapsed time of the task.
Example EVENT A controller uses multiple programs except for a common shut down procedure.
Each program uses a program-scoped tag named Shut_Down_Line that turns on if
Instruction Trigger
the program detects a condition that requires a shut down.
No tag is required.
Define a Timeout Value for If you want your event task to run automatically, if the trigger fails to occur within
a certain time, assign a timeout value to the task. When the event task is finished,
an Event Task the timeout timer begins to increment. If the timer reaches its preset value before
the event task is triggered, the event task runs automatically.
Description
Event task runs.
Timeout time stops incrementing.
Event task is done.
Timeout timer resets and begins incrementing.
Timeout timer reaches the timeout value.
Event task automatically runs.
In the Status attribute of the TASK object, bit 1 turns on.
Assign a Timeout Value Follow these steps to assign a timeout value to an event task.
to an Event Task
6. Click OK.
Example To make sure that a timeout value is always defined and enabled for an event task, the logic configures the timeout when the controller
enters Run mode.
If S:FS = 1 (first scan) then set the timeout value for Task_2 and enable the timeout function.
1. The first MOV instruction sets Task_2_Timeout = 10000000 s (DINT value). Then the SSV instruction sets the Rate attribute for
Task_2 = Task_2_Timeout. This configures the timeout value for the task.
2. The second MOV instruction sets One = 1 (DINT value). Then the SSV instruction sets the EnableTimeout attribute for Task_2 = One.
This enables the timeout function for the task.
Programmatically To determine if an event task ran due to a timeout, use a Get System Value (GSV)
determine if a timeout instruction to monitor the Status attribute of the task. The following table lists the
occurs Status attribute for the TASK object.
Example If a timeout occurs for the event task, communication with the triggering device might have failed. This requires the process to shut down. To shut down
the controller, the event task calls the fault routine for the program and supplies a user-defined fault code (999 in this example).
1. The GSV instruction sets Task_2_Status = Status attribute for Task_2 (DINT value).
2. If Task_2_Status.1 = 1, then a timeout occurred so shut down the controller and set the major fault code to 999.
The JSR instruction calls the fault routine for the program. This produces a major fault.
The major fault code = 999 (value of the input parameter of 999).
3. If Condition_1 = 1, then clear the bits of the Status attribute for Task_2.
The SSV instruction sets the Status attribute of Task_2 = Zero. Zero is a DINT tag with a value of 0.
T
tag
trigger event task 57
task
avoid overlap 17
choose event trigger 35
create periodic 28
define timeout 67
inhibit 24
manually check for overlap 18
manually configure output processing 22
monitor 18, 19
number supported 11
output processing 20
overlap 17
programmatically check for overlap 19
programmatically configure output processing 24
trigger via EVENT instruction 64
throughput
estimate for event task 44
timeout
define for event task 67
trigger
axis registration 49
axis watch 53
choose for event task 35
consumed tag 57
EVENT instruction 64
module input data 37
motion group 47
W
watch point
trigger event task 53
In addition, we offer multiple support programs for installation, configuration, and troubleshooting. For more information, contact your local
distributor or Rockwell Automation representative, or visit http://www.rockwellautomation.com/services/online-phone .
Installation assistance
If you experience a problem within the first 24 hours of installation, review the information that is contained in this manual. You can contact
Customer Support for initial help in getting your product up and running.
United States Contact your distributor. You must provide a Customer Support case number (call the phone number above to obtain one) to
your distributor to complete the return process.
Outside United States Please contact your local Rockwell Automation representative for the return procedure.
Documentation feedback
Your comments will help us serve your documentation needs better. If you have any suggestions on how to improve this document, complete the
feedback form, publication RA-DU002.
Supercedes Publication 1756-PM005F-EN-P - June 2016 Copyright 2016 Rockwell Automation, Inc. All rights reserved. Printed in the U.S.A.