Siemens SIMATIC S7-1500 Cycle and Response Times

Preface

This manual provides information on the following topics:

• Types of program execution
• Run priorities
• Cycle and response times, and the influences to which they are subject
• Configuration options for the optimization of your user program

Basic knowledge required

The following knowledge is required in order to understand the documentation:

• General knowledge of automation technology
• Knowledge of the industrial automation system SIMATIC
• Knowledge about the use of Windows-based computers
• Knowledge about how to use STEP 7/TIA Portal

Conventions

STEP 7: We refer to the configuration and programming software as "STEP 7" in this documentation synonymously for "STEP 7 V12 (TIA Portal)" and subsequent versions.

Please also observe notes marked as follows:

Note: A note contains important information on the product described in the documentation, on the handling of the product and on the section of the documentation to which particular attention should be paid.

Scope of the documentation

This documentation mainly includes the CPU components of the cycle and reaction times of the S7-1500 automation system. You can find references at the corresponding instances for more information on the ET 200MP and ET 200SP distributed I/O systems.

Additional support

Additional information on SIMATIC products is available on the Internet. The associated documentation is likewise available on the Internet.

• You can find the available technical documentation for the individual SIMATIC products and systems in the internet (http://www.siemens.com/simatic-tech-doku-portal).
• The online catalog and the ordering system are available on the Internet (http://mall.automation.siemens.com).

Security information

Siemens provides products and solutions with industrial security functions that support the secure operation of plants, solutions, machines, equipment and/or networks. They are important components in a holistic industrial security concept. With this in mind, Siemens' products and solutions undergo continuous development. Siemens recommends strongly that you regularly check for product updates.

For the secure operation of Siemens products and solutions, it is necessary to take suitable preventive action (e.g. cell protection concept) and integrate each component into a holistic, state-of-the-art industrial security concept. Third-party products that may be in use should also be considered. You can find more information about industrial security on the Internet (http://www.siemens.com/industrialsecurity).

To stay informed about product updates as they occur, sign up for a product-specific newsletter. You can find more information on the Internet (http://support.automation.siemens.com).

Documentation guide

This modular documentation of the SIMATIC products covers diverse topics concerning your automation system.

The complete documentation for the S7-1500 system consists of a system manual, function manuals and device manuals.

The STEP 7 information system (Online Help) also helps you configure and program your automation system.

Overview of the additional documentation on the topic of cycle and response times

The following table lists additional documentation which supplements this description of cycle and response times.

SIMATIC manuals

All current manuals for the SIMATIC products are available for download free of charge from the Internet (http://www.siemens.com/automation/service&support).

Program processing

Introduction

You often program your user program with a cyclic OB, usually in OB 1. With complex applications, problems are often encountered in complying with the response time required by the application. You can often solve the response time requirements by splitting the user program up into several parts with different response time requirements. The CPU offers a number of different OB types for this purpose, the properties (priority, frequency, etc.) of which can be adapted to meet the requirements.

Program organization

You can choose from the following types of program execution for running your user program:

Program execution in the cyclic program of the CPU:

In the simplest case, you execute the entire user program in the cyclic program of the CPU. All tasks in the user program are then processed with equal rank. This also results in the same response times for all tasks.

In addition to program execution in the cyclic program, there is time-driven and event-driven program execution.

Time-driven processing:

In a complex user program, there are frequently portions with different response time requirements. You can optimize the response times by taking advantage of these differences in the requirements. To do so you can move the program parts with higher response time requirements to higher-priority OBs with shorter cycles, for example cyclic interrupt OBs. The processing of these parts can thus occur with different frequencies and priorities.

Event-driven processing:

Depending on the I/O modules used, you can configure hardware interrupts for specific process events (such as an edge change of a digital input) that result in the call of the assigned hardware interrupt OB. The hardware interrupts have a higher priority and interrupt the cyclic program of the CPU. You can achieve very short response time in the CPU with hardware interrupts by directly triggering program execution.

Keep in mind that the time characteristics of your application becomes less predictable with intense use of hardware interrupts. The reason being that the time at which the triggering events occur can result in drastically different response times.

Tip: Use hardware interrupts only for a few, select events.

Using process image partitions

If a program is distributed to various OBs, for example, due to differing response time requirements, it is advisable and often necessary to assign the update of the used I/O data directly to these OBs. You can use process image partitions for this purpose.

You group the input and output data in a process image partition according to their use in the program and assign the data to the corresponding OB.

You optimize the response times this way, because the update of the affected I/O modules is directly synchronized with the processing in the program.

A process image partition of the inputs (PIPI) permits the associated input data for an OB program to be updated immediately before the OB program starts.

A process image partition of the outputs (PIPQ) permits the output data associated with an OB program to become effective on the outputs immediately after the OB program runs.

You have 32 (0 ... 31) process image partitions at your disposal. The default assignment for the I/O is process image partition 0 (setting: "Automatic updating"). Process image partition 0 is permanently assigned to cyclic processing.

You have to configure this "system-side update of process image partitions". You can find additional information on configuration of process image partitions in the online help for STEP 7 under the keyword "Assign process image/process image partition".

Interruptability of program run

Each organization block is processed with a priority. You can adapt the priority according to the response time requirements for most organization blocks.

All cycle OBs always have the lowest priority of 1. The highest priority is 26.

Communication tasks always have priority 15. If necessary, you can change the priority of your blocks and select a higher priority than the communication.

Organization blocks or system activities with higher priority interrupt those with lower priority, and thus extend the run time of the interrupted organization blocks or system activities. If two pending tasks have the same priority, these tasks are processed in the order in which the tasks occurred.

Note
Higher priority OBs
Communication functionality is strongly influenced by too many or runtime-intensive OBs with a priority > 15.

When using OBs with a priority > 15, you should consider the runtime load that they cause in order to keep communication functionality at a reasonable level.

Cyclic program processing

3.1 Cycle

Introduction

In this section, you will learn about the concept of the "cycle".

Definition of cycle

A cycle in the S7-1500 automation system encompasses the following:

• Update of process image partition 0 of the inputs (PIPI 0)
• Processing of the cyclic program
• Update of process image partition 0 of the outputs (PIPQ 0)

The process image partition 0 is permanently assigned to the cycle. You assign I/O addresses to this process image partition using the "Automatic updating" setting (default) in the TIA Portal in HW Config for the I/O modules.

The figure below illustrates the phases that are passed through during a cycle.

Figure 3-1 Cycle

Diagram showing the phases of a cycle:

• Phase 1: PII partition Update
• Phase 2: Cyclic program
• Phase 3: PIQ partition Update
• Phase 4: Cyclic program
• Phase 5: PIQ partition Update

Description of cycle phases:

• ① The operating system starts measurement of the cycle time.
• ② The CPU reads the status of the inputs at the input module and writes the input data to the process image partition of the inputs.
• ③ The CPU processes the user program and executes the instructions specified in the program.
• ④ The CPU writes the states from the process image outputs to the output modules.
• ⑤ The operating system evaluates the determined cycle time and starts the measurement again.

3.2 Cycle time

Introduction

In this section you will learn about the concept of "cycle time", and how to estimate the cycle time.

Definition of cycle time

The cycle time is the time the CPU need to execute the cyclic program, to update the process image of the inputs and outputs as well as for all program parts and system activities that interrupt this cycle.

3.2.1 Different cycle times

Introduction

The cycle time (Tcyc) is not equally long for every cycle, because the processing times can vary. Causes for this are, for example:

• Different program runtimes (e.g. program loops, conditional commands, conditional block calls, or different program paths)
• Lengthening due to interruptions (e.g. time-driven interrupt processing, processing of hardware interrupts or communication)

Causes for different cycle times

The cycle time Tcyc2 is longer than Tcyc1, because the cyclic program is interrupted by a cyclic interrupt OB in this example (e.g: OB 30). The cyclic interrupt OB in turn is interrupted by communication.

The figure below shows the different cycle times Tcyc1 and Tcyc2.

Figure 3-2 Possible causes of differing cycle times

Diagram illustrating cycle times:

• Current cycle: Tcyc1
• Next cycle: Tcyc2
• Cycle after next:

Diagram showing priority levels:

• Priority 15: Communication
• Priority 7: PII partition Update, OB 30, PIQ partition Update
• Priority 1: CP (Cyclic program)

Minimum cycle time

In STEP 7, you can set a minimum cycle time for a CPU. The default for the minimum cycle time is one millisecond. It may be advisable to increase this setting in the following cases:

• To reduce the cycle time's fluctuation range.
• To make remaining computing time available for communication tasks.

Maximum cycle time

The cycle time is monitored by the CPU. By default, the maximum cycle time is 150 ms. This value can be changed by setting CPU parameters. When the cycle time is longer than the maximum cycle time, the time error OB (OB 80) is called.

You have the option of restarting the maximum cycle time using the "RE_TRIGR" instruction, and thus extending it.

With the user program in OB 80 you specify how the CPU responds to the time error. Under the following conditions the CPU goes to STOP.

• If you have not loaded an OB 80.
• If the cycle is still not completed after an additional maximum cycle time

Keep in mind that the cycle time is extended by interruptions as shown in the previous figure.

Cycle time statistics

In STEP 7 and in the TIA Portal, you have the option of viewing the cycle time statistics, and of determining the minimum and maximum cycle time with the instruction "RT_INFO". You need this information to determine the response times of the user program in the cycle.

To view the cycle time statistics, follow these steps:

1. Establish an online connection with the TIA Portal.
2. Select the Online tools task card on the very right.

Result: The diagram of the cycle time statistics is displayed in the cycle time section.

The following figure shows an extract from the TIA Portal with the cycle time statistics. In this example, the cycle time ranges from 7 ms to 12 ms. The current cycle time is 10 ms. The maximum cycle time that can be set in this example is 40 ms.

Figure 3-3 Cycle time statistics

Cycle time statistics display:

• Shortest: 7 ms
• Current/last: 10 ms
• Longest: 12 ms

You can find additional information on the runtime characteristics of the CPU with the "RT_INFO" instruction in the user program. You can read the utilization of the CPU in percentage with the control program and communication, and you can also read the runtime statistics of individual OBs.

Reference

You can find additional information on the "RT_INFO" instruction in the STEP 7 online help.

3.2.2 Influences on the cycle time

3.2.2.1 Update time for process images

Introduction

In this section, you will learn how you can estimate the update time of process image partitions.

Update time for process image partitions

The update time of the process image partitions depends on the quantity of assigned central and distributed I/O module data.

You can estimate the update time using the following formula:

Base load for process image update
+ Number of words in the process image x copy time for central I/O modules
+ Number of words in the process image via DP x copy time for PROFIBUS I/O
+ Number of words in the process image via PROFINET x copy time for PROFINET I/O
= Update time of the process image partition

The following table includes the times for estimating the typical update time of the process image partitions.

3.2.2.2 User program processing time

Introduction

Organization blocks or system activities with higher priority interrupt those with lower priority, and thus extend the run time of the lower-priority organization blocks or system activities.

Program execution time without interruptions

The user program has a certain runtime without interruptions. The length of the run time depends on the number of operations that are executed in the user program.

The following table contains the times for how long an operation lasts.

Note
Instruction "RUNTIME"
You can measure the run times of program sequences with the instruction "RUNTIME".

Extension due to nesting of higher-priority OBs and/or interrupts

The interruption of a user program by a higher-priority OB causes a certain basic time expenditure. Take account of this basic time expenditure in addition to the update time of the assigned process image partitions and the processing time of the contained user program.

The following tables include the corresponding times for the various interrupts and error events.

Reference

You can find additional information on the subject of error handling in the system manual for the S7-1500 Automation System (http://support.automation.siemens.com/WW/view/en/59191792), in the Events and OBs section.

3.2.2.3 Extension of cycle time due to communication load

Impact of communication on the cycle time

In the sequence model of the CPU, communication tasks are processed with priority 15. All program parts with priority > 15 are not influenced by communication.

Configured communication load

The CPU operating system provides the maximum specified percentage of total CPU processing power for communication tasks. The default setting for the communication load of the S7-1500 automation system is 50% in the TIA Portal. If the processing power is not needed for communication, then the processing power is available to the operating system and the user program.

Communication is allocated the requisite processing time in 1-ms increments, with priority 15. At 50% communication load, 500 µs of each 1 millisecond are used for communication.

The following formula may be used to estimate the extension of the cycle time by communication.

Figure 3-4 Formula: Impact of communication load

Actual cycle time = Cycle time without communication x 100 / (100 - "configured communication load in %")

With a complete use of the communication load of 50% (default), the following value results:

Figure 3-5 Extension of cycle time due to communication load

Actual cycle time = Cycle time without communication x 2

The actual cycle time is up to twice as long as the cycle time without communication when you use the default communication load.

Dependency of maximum cycle time on the configured communication load

The diagram shows the nonlinear relationship between maximum cycle time and configured communication load with a pure cycle time of 10 ms, which means without interruptions.

Figure 3-6 Maximum cycle time depending on the configured communication load

Diagram showing cycle time vs. communication load:

• The Y-axis represents Cycle time (ms), ranging from 5 ms to 30 ms.
• The X-axis represents Communication load (%), ranging from 0% to 60%.
• A shaded area indicates "You can set the communication load in this range".

The shown influence of the communication load on the processing time applies to all OBs with a priority ≤ 15.

Reducing the cycle time through low communication load

You can reduce the setting for the communication load in the hardware configuration. If you set a communication load of 20%, for example, instead of the default 50%, the cycle time is reduced from 2 x cycle time without communication to 1.25 x cycle time without communication.

3.3 Time-driven program processing in cyclic interrupts

Effect on the actual cycle time

Communication is only one cause for extension of the cycle time. All cycle time extending settings lead to the result that more asynchronous events can occur within a cycle, which additionally extend the cyclic program. This extension depends on the number of events that occur in the cyclic program and the time required to process these events.

Note
Checking parameter changes:

• Check the effects of a value change on the "Cycle load due to communication" parameter during system operation.
• To prevent time errors, take account of the communication load when setting the maximum cycle time.

Tips

Whenever possible, use the default setting for the configured communication load.

If you reduce the value of the communication load, keep in mind that communication tasks are interrupted by higher-priority OBs. This means it will also take longer to process the communication.

Definition

With a cyclic interrupt, you can have a particular program processed in a defined cycle. This program is run at a higher priority (user-assigned) and is thus independent of the execution time of the cyclic program.

Tip: By shifting program sections to cyclic interrupts, you can reduce the corresponding response times or better adapt them to your requirements.

In STEP 7, the organization blocks OB 30 to OB 38 are provided for the processing of cyclic interrupts. You can create additional cyclic interrupts starting with organization block OB 123. The number of available organization blocks depends on the CPU used.

A cyclic interrupt is an interrupt initiated according to a defined cycle that causes a cyclic interrupt OB to be processed.

Cycle of a cyclic interrupt

The cycle of a cyclic interrupt is defined as the time from the call of a cyclic interrupt OB to the next call of a cyclic interrupt OB.

The following figure shows an example of the cycle of a cyclic interrupt.

Figure 3-7 Call interval of a cyclic interrupt

Diagram showing cycle of a cyclic interrupt:

• Priority 7: PII partition Update, OB 30, PIQ partition Update
• Priority 1: CP - Cyclic program

Accuracy of a cyclic interrupt

If a cyclic interrupt is not delayed by a higher-priority OB or communication activities, the accuracy with which it is started is nevertheless subject to system-dependent fluctuations.

The following table shows the accuracy with which a cyclic interrupt is triggered:

3.4 Response time for cyclic and time-driven program processing

Introduction

In this section you will learn about the concept of "response time", and how to calculate the response time.

Definition

The response time in the case of cyclic or time-controlled program execution is the time between the detection of an input signal and the change of a connected output signal.

Fluctuation of the response time of the CPU

The actual response time of the CPU fluctuates between one and two cycle times for cyclic program execution and between one and two cyclic interrupt cycles for time-controlled program execution.

You must always reckon with the longest response time when configuring your system.

The following figure shows the shortest and longest response times of the CPU to an event.

Figure 3-8 Shortest and longest response times of the CPU

Diagram illustrating response times:

• Shortest response time: One cycle time or one cyclic interrupt
• Longest response time: Two cycle times or two cyclic interrupts

Description of response time components:

• Change of encoder signal with transfer to process image
• PII partition Update
• Cyclic program or time-controlled program
• PIQ partition Update
• Change of output signal
• Change of encoder signal without transfer to process image
• Transfer of encoder signal to process image

Factors

To determine the process response time, you must take account of the following factors in addition to the CPU response time described above:

• Delay of the inputs and outputs at the I/O module
• Update times for PROFINET IO or DP cycle times on PROFIBUS DP
• Switching times of the sensors and actuators used

Delay at the inputs and outputs of the modules

Delays in the response time occur at the inputs and outputs of the modules and as a result of device-internal delays (e.g., interface modules).

The delay and cycle times can be found in the technical specifications for the I/O modules.

Update time with distributed I/O

When distributed I/O are used, the maximum response time is also extended by the bus transmission times of PROFIBUS or PROFINET. These bus transmission times occur when process image partitions are read in and output. The bus transmission times correspond to the bus update cycle of the distributed device.

PROFINET IO

If you use STEP 7 to configure your PROFINET IO system, STEP 7 calculates the update time. Select the PROFINET interface of the I/O module. In the General tab, select "Advanced options > Real time settings > I/O cycle". The update time is displayed in the field "Update time".

PROFIBUS DP

If you use STEP 7 to configure your PROFIBUS DP master system, STEP 7 calculates the DP cycle time. Select the PROFIBUS subnet in the network view. In the Inspector window, navigate to the bus parameter in the General tab. The DP cycle time is typically displayed in the "Parameters" field at "Ttr typical".

The following figure illustrates the additional bus runtimes using distributed I/O.

Figure 3-9 Additional bus runtimes with distributed I/O

Diagram showing additional bus runtimes:

• Device-internal delay
• Delay at input of the module
• CPU cycle n
• CPU cycle n + 1
• Maximum transmission time PROFINET/PROFIBUS
• Delay at output of the module
• Device-internal delay

You can achieve a further optimization of the response times using isochronous mode.

Reference

The following links provide additional information:

• Tool for calculating the reaction time on PROFINET (http://support.automation.siemens.com/WW/view/en/21869080)
• Tool for calculating the reaction time on PROFIBUS (http://support.automation.siemens.com/WW/view/en/21178141)
• Transmission times and isochronous mode in Function Manual PROFINET with STEP 7 V13 (http://support.automation.siemens.com/WW/view/en/49948856); note also the chapter "Tips on assembly"
• Transmission times and isochronous mode in Function Manual PROFIBUS with STEP 7 V13 (http://support.automation.siemens.com/WW/view/en/59193579); note also the chapter "Network settings"
• Delays at the input or output of the modules can be found in the manual for the respective device.
• Device-internal delays can be found in the manuals for the ET 200MP and ET 200SP distributed I/O systems.

3.5 Summary of response time with cyclic and time-controlled program execution

Estimation of the shortest and longest response time

The following formulas may be used to estimate the shortest and longest response time:

Estimation of the shortest response time

The shortest response time is the sum of:

• 1 x delay in the I/O module for inputs
• 1 x (update PROFINET IO or PROFIBUS DP)*
• 1 x transfer time of the process image inputs
• 1 x processing of the user program
• 1 x transfer time of the process image outputs
• 1 x (update PROFINET IO or PROFIBUS DP)*
• 1 x delay in the I/O module for outputs

= Shortest response time

* Time is dependent on the configuration and the extent of the network.
The shortest response time is equivalent to the sum of the cycle time plus the input and output delay times.

Estimation of the longest response time

The longest response time is comprised of:

• 1 x delay in the I/O module for inputs
• 2 x (update PROFINET IO or PROFIBUS DP)*
• 2 x transfer time of the process image inputs
• 2 x processing of the user program
• 2 x transfer time of the process image outputs
• 2 x (update PROFINET IO or PROFIBUS DP)*
• 1 x delay in the I/O module for outputs

= Longest response time

* Time is dependent on the configuration and the extent of the network.
The longest response time is equivalent to the sum of twice the cycle time plus the delay times of the inputs and outputs. The longest reaction time includes twice the update time for PROFINET IO or twice the DP cycle time on PROFIBUS DP.

Event-driven program processing

4.1 Response time of the CPUs when program execution is event-controlled

Introduction

In order to detect events in the process immediately in the user program and to react to them with an appropriate program, you use hardware interrupts. In STEP 7, organization blocks OB 40 to OB 47 are provided for processing a hardware interrupt. You can create additional hardware interrupts starting with organization block OB 123. The number of available organization blocks depends on the CPU used.

Definition

A hardware interrupt is an interrupt that occurs during the running program processing, due to an interrupt-triggering process event. The operating system calls the assigned interrupt OB; as a result, the processing of the program cycle or of lower priority program parts is interrupted.

Interrupt response times of the CPUs

The interrupt response times of the CPUs start with the occurrence of a hardware interrupt event in the CPU and end with the start of the assigned hardware interrupt OB.

This time is subject to system-inherent fluctuations, and this is expressed using a minimum and maximum interrupt response time.

The following table contains the length of the response times of the CPUs for hardware interrupts.

Note that the times are extended if higher-priority interrupts are queued up for processing, and if the hardware interrupt OB is assigned to a process image partition. You can find these times in the table Times for interrupts (Page 18).

Impact of communication on interrupts

Communication tasks are always processed by the CPU with priority 15. If you do not want the interrupt processing to be delayed or interrupted by communication, configure the interrupt processing with priority > 15. The default setting for interrupt processing is priority 16.

Reference

You can find additional information on the number of available organization blocks in the S7-1500 Automation System (http://support.automation.siemens.com/WW/view/en/59191792) system manual, in the Events and OBs chapter.

You can find additional information on the topic of "Configuring hardware interrupts" in the STEP 7 online help.

See also

User program processing time (Page 17)

4.2 Process response time when program execution is event-driven

When program execution is event-driven, the process response time is determined by the following:

• Delay times of the input and output modules used
• Update times for PROFIBUS/PROFINET, if distributed modules are used
• Interrupt response time of CPU
• Runtimes of the interrupt OB including update of the process image partition

The following figure shows the individual processing steps for event-driven program processing.

Figure 4-1 Schematic representation of event-driven program processing

Diagram of event-driven program processing steps:

• Interrupt-triggering process event
• Delay time/interrupt tripping of input module
• Update time for PROFIBUS/PROFINET, if input module is used as distributed module
• Interrupt response time of CPU
• Update of process image input partition
• User program execution in interrupt OB
• Update of process image output partition
• Update time for PROFIBUS/PROFINET, if output module is used as distributed module
• Delay time of output module
• Signal change at terminal of output signal

Glossary

Automation system

An automation system in the context of SIMATIC S7 is a programmable logic controller.

Cycle time

The cycle time represents the time a CPU requires to process the user program once.

Cyclic interrupt

A cyclic interrupt is generated periodically by the CPU in a configurable time pattern. At this point in time the corresponding organization block is processed.

Diagnostic interrupt

Modules capable of diagnostics operations report detected system errors to the CPU by means of diagnostic interrupts.

Hardware interrupt

A hardware interrupt is started by interrupt-triggering modules when a specific event occurs in the process. The hardware interrupt is reported to the CPU. The assigned organization block will be processed according to interrupt priority.

Interrupt

The CPU's operating system distinguishes between various priority classes that control the processing of the user program. These priority classes include interrupts, e.g. hardware interrupts. When an interrupt occurs, the operating system automatically calls an assigned organization block, in which the user programs the desired response.

Process image

The process image is part of CPU system memory. At the start of the cyclic program the signal states of the input modules are transmitted to the process image of the inputs. At the end of the cyclic program the process image of the outputs is transmitted as signal state to the output modules.