TIP: S7-1500 - cycle and response times

Hi,

The manual “SIMATIC S7-1500, ET 200MP, ET 200SP Cycle and response times”
(http://support.automation.siemens.com/WW/view/en/59193558) gives a complete information about Cycle and response times.

Overview

There is a suptil difference between cycle time and response time:

- Cycle time comprises the image update time and OB execution time.

-Response time is the time from then incoming of an input signal up to the response at an output signal.

The cycle time is a part of the response time. The response time includes also module read/write times, communication over networks and inside decentral periphery (IO module / IM times).

Many factors that are taking account on the response time should be counted once for the best case or twice for the last. Reason: it is possible that an incoming signal could come an infinitesimal instant before (or after) the input is read. If it comes after, that means that the software will just recognize the signal at next program execution cycle.

TIPs:

Central x distributed IO

As in the manual, for cycle time calculation, the update time for central IO modules is something about 90 micro seconds / word x 0,5 micro seconds / word for IO modules in PROFIBUS or PROFINET. That is a fact, but it could leave to a miss understanding that the response time of central IO modules are always slower as distributed IOs…

It is necessary to understand that the update image by PROFINET / PROFIBUS is quickly because in the distributed IO case, the information pooling of IO modules is done by IM and not by the CPU itself. So this time doesn’t retard the OB execution time (cycle time) but it should take in account in the response time.

The use of distributed IO with several ET 200, however gives the possibility to make this pooling in parallel, by the several IM, and this could leave really to quickly response times. On other hand, each PROFINET telegram has headers, that waist timi, so the greather number of distributed IO, greather the overheads.

Each case should be calculated individually, however it is possible to take some general tomb rules:

General response time for a CPU + central rack IOs < CPU + 1 x periphery distributed IOs

General response time for a CPU + central rack IOs > CPU + split in several distributed IOs / central rack IOs

Generally also, alone, each factor is located in the size of micro seconds, and so, they have not significant influence in the general automation tasks. However of time critical cases, response time for each possible configuration should be calculated to assure that the best solution are take.

Communication

Communication tasks are processed as priority 15. That means:

- OBs with priority <15 are affected by communications tasks

- OB with priority >15 are not affected by communication tasks (on other hands, OB with priority >15 could retards communication tasks).