Resolving S7-1500 Cycle Time Delays from HMI Tag Polling in TIA Portal V16

An S7-1500 1515T-2 PN motion controller paired with a KTP900 Basic panel and three SINAMICS V90 drives over PROFINET is a common compact motion architecture. When the operator panel is added or modified, the controller's OB1 cycle time can be affected by the polling behavior of the HMI tags, the assignment of those tags to a global DB, and the communication load setting of the CPU. The symptoms include delayed axis start commands, erratic MeasuringInput values on the technology objects, and dropped HMI updates. This reference walks through the root cause analysis, the specific TIA Portal V16 parameters that govern the behavior, and the field-proven remediation steps.

1. Affected System Configuration

The S7-1515T-2 PN is a technology CPU whose motion functionality is integrated into the firmware. It supports technology objects for TO_SpeedAxis, TO_PositioningAxis, and TO_SynchronousAxis as well as measuring inputs on the ET 200SP modules. Any OB1 cycle jitter above 2-3 ms is observable as axis start delay because the MC_Power, MC_MoveJog, and MC_MoveAbsolute blocks are processed at a fixed position in the priority class.

2. Problem Symptoms

• All three V90 axes exhibit a perceptible start delay (50-200 ms) after a motion command from the PLC program.
• MeasuringInput value (technology object 5) returns stale or zeroed values during fast probe events.
• HMI tags continue to update, but a new screen with two additional Graphic Views visibly staggers when switching pages.
• Online > Diagnostics > Cycle time in TIA Portal shows OB1 average rising from ~4 ms to ~12-18 ms when the new HMI screen is visible.

3. Root Cause Analysis

3.1 HMI Tag Acquisition Cycle

In TIA Portal V16, the HMI tag properties include a setting Acquisition cycle and Continuous (Cyclic) mode. The default acquisition cycle for a tag dragged onto a screen is 1 s. When set to 100 ms, the panel requests a tag update every 100 ms regardless of whether the screen is visible. For 30 tags at 100 ms, the panel generates roughly 300 read requests per second against the controller.

The KTP900 Basic uses a single internal HMI thread for PROFINET IO communication. The thread budget is 50% of the panel's internal scheduler. When 30 tags at 100 ms are stacked, the thread becomes the bottleneck. However, the controller side also has a fixed cost per request - each request consumes one slot in the S7-1500's communication scheduler. The cost is roughly 80-150 microseconds per tag read at the CPU, which compounds with the 1 ms OB1 main scan.

3.2 CPU Communication Load Setting

The S7-1500 has a configurable parameter under Device configuration > Properties > Communication load. The default is 50% of the OB1 cycle. The value is interpreted as a target percentage: the CPU's communication scheduler will preempt OB1 execution to service HMI/PG/OP requests up to that fraction of the cycle. With 30% configured and OB1 at 4 ms, the CPU budgets 1.2 ms for communications. When 30 tags at 100 ms arrive, the request queue exceeds the budget and OB1 is forced to wait for the next cycle window. This is the actual cause of the OB1 jitter observed.

The S7-1500's communication handling uses two priority classes:

The MC-Servo OB runs at priority 25 and is time-coupled to the PROFINET IRT cycle. If OB1 stretches, the MC-Servo OB still runs on time, but the pre-processing of the motion command in OB1 (calling MC_Power, MC_MoveVelocity) is delayed. Hence the visible start delay on the V90 axes.

3.3 HMI Tag Distribution Across Multiple DBs

The original project had HMI tags distributed across multiple data blocks - configuration DB, alarm DB, axis state DB, etc. The KTP900 Basic requests each tag by its symbolic name. When tags span multiple DBs, the panel cannot bundle the read requests into a single PDU (Protocol Data Unit). With 30 tags split across 4-5 DBs, the panel issues 30 individual read sub-requests, each carrying a fixed PROFINET IO frame overhead of ~80 bytes.

3.4 New Screen with Two Graphic Views

Each Graphic View on the KTP900 Basic polls its input tags independently and uses bitmaps with internal interpolation. Two additional Graphic Views added an additional ~80 tag reads per second when visible, on top of the existing 30 tags. This pushed the request rate past the CPU's configured communication budget.

4. Diagnostic Procedure

1. Connect TIA Portal V16 to the CPU online and open Online & Diagnostics > Diagnostics > Cycle time.
2. Record the OB1 minimum, maximum, and average cycle time with the original HMI configuration.
3. Switch the HMI to the new screen and note the change in average OB1 cycle time.
4. Open Device configuration > Properties > Communication load and confirm the current value.
5. Open the WinCC project, right-click the HMI tag group, and check the Acquisition cycle and Update mode for each tag.
6. Use the panel's own diagnostics screen (System > System Information > Communication) to inspect the panel's read request rate.

Expected reading on a healthy 1515T-2 PN with 30 tags at 1 s: OB1 average under 2 ms. With 30 tags at 100 ms and 30% communication load: OB1 average 8-15 ms, max 20+ ms.

5. Solution: Communication Load Re-Tuning

The first fix that restored operation was raising the CPU communication load from 30% to 50% in the device configuration. This is the maximum recommended value for a motion CPU. Siemens' S7-1500 System Manual specifies that communication load should not exceed 50% in motion applications because the MC-Servo OB and IRT cycle must remain deterministic. The trade-off is: higher communication load means more CPU time dedicated to HMI/PG requests at the cost of OB1 throughput.

To change the communication load in TIA Portal V16:

1. Open the project and select the CPU in the device view.
2. Open Properties > Communication load.
3. Set Cycle load due to communication to 50%.
4. Compile and download to the CPU (HALT or RUN-P, depending on firmware).

6. Solution: HMI Tag Acquisition Tuning

Communication load alone is not the proper fix. The proper fix is to reduce the number and frequency of HMI tag requests. Three measures apply:

6.1 Switch from Cyclic Continuous to On-Visible Acquisition

For tags that are only relevant on a specific screen, change the tag properties in WinCC:

1. Open the HMI tags editor.
2. For tags used only on the new screen, change Acquisition cycle from 100 ms to 1 s and select Update if visible (default for new tags).
3. For tags that need fast updates (current axis velocity, current position), keep 100 ms but only if the screen is visible. WinCC will automatically stop polling tags not on the active screen if the tag is set to Update if visible.

6.2 Bundle Tags in a Single HMI Data Block

The recommended pattern is to create a dedicated DB that contains only tags the HMI needs to read. In the PLC, copy the relevant values from the production DBs into the HMI DB at the end of OB1 (or in a cyclic interrupt OB at 10 ms). The HMI then polls a contiguous range from a single DB, allowing the CPU to respond to all tag reads in one PDU.

Example structure in TIA Portal V16:

// HMI_Data DB (DB200) - dedicated to HMI consumption
DATA_BLOCK "HMI_Data"
{ S7_Optimize_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
   STRUCT
      Axis1_ActualVelocity : REAL;   // RPM, mirrored from TO_Axis_1
      Axis1_ActualPosition : LREAL;  // mm, mirrored from TO_Axis_1
      Axis1_StatusWord      : WORD;   // S7 V90 status bits
      Axis2_ActualVelocity : REAL;
      Axis2_ActualPosition : LREAL;
      Axis2_StatusWord      : WORD;
      Axis3_ActualVelocity : REAL;
      Axis3_ActualPosition : LREAL;
      Axis3_StatusWord      : WORD;
      ProbeValue1          : LREAL;  // Measuring input, motion TO
      ProbeValue2          : LREAL;
      CurrentOpMode        : INT;    // 0=Auto, 1=Manual, 2=Setup
      FaultCode            : DWORD;  // aggregated fault from V90s
      CycleCounter         : DINT;   // increments every OB1
   END_STRUCT
END_DATA_BLOCK

In OB1, after the motion control blocks, copy the values:

"HMI_Data".Axis1_ActualVelocity := "Axis_1".MotionStatus.ActualVelocity;
"HMI_Data".Axis1_ActualPosition := "Axis_1".MotionStatus.ActualPosition;
"HMI_Data".Axis1_StatusWord      := "Axis_1".MotionStatus.StatusWord;
// ... repeat for Axis2, Axis3
"HMI_Data".ProbeValue1 := "MeasuringInput_1".MeasuredValue;
"HMI_Data".CycleCounter := "HMI_Data".CycleCounter + 1;

The HMI only accesses DB200. The WinCC connection is configured with a single DB area, and the panel can request all 30 tags in a single S7 read PDU (max 480 bytes for a 1515T-2 PN, max 800 bytes for S7-1500 in general, depending on CPU firmware).

6.3 Use a Pointer-Based Symbolic Update

For systems where the HMI tag list changes frequently, use a pointer in the HMI configuration that points to a UDT (User-Defined Data Type). The HMI subscribes to the UDT, and the PLC populates the UDT instance. This is the cleanest pattern for HMI-CPU coupling in motion applications.

7. Solution: Configure HMI Tags to Update Only When Visible

The WinCC Basic V16 panel runtime offers an Update if visible checkbox per tag. For Basic panels, this is the equivalent of Comfort/Advanced's Update on screen change. The HMI runtime will stop sending read requests for that tag when the screen containing the tag is not active. This is the single highest-impact optimization for an HMI-driven CPU slowdown.

Procedure:

1. Open the HMI tags editor in TIA Portal V16.
2. Select all tags that are only used on a single screen.
3. In the Properties pane, expand Update and check Update if visible.
4. Compile the HMI project and download to the panel.

8. V90 PROFINET Considerations

The SINAMICS V90 PN in this configuration uses standard telegram 1 (or 2/3 for position control) and PROFIsafe is not active. The V90 is configured in the device configuration of the S7-1500 and the IRT slots are placed in the topology editor.

Key timing constraints:

Verify in the online diagnostics that the V90 PROFINET interface reports Sync locked and the IRT cycle time is stable. If the V90 is in Sync lost, the controller will fall back to free-run mode and the probe timestamps become invalid - the same symptom the user reported. This must be ruled out before assuming HMI polling is the cause.

9. IM 155-6 PN HF Considerations

The ET 200SP high-feature interface module 6ES7155-6AU00-0CN0 supports IRT and isochronous mode. If the measuring input is wired to a digital input module on the ET 200SP station (e.g., DI 8x24VDC HF 6ES7131-6BF00-0DA0), the input latch is time-coupled to the IRT cycle. Ensure the slot is configured as isochronous in the device configuration and that the slot's Ti and To times match the topology editor. A mismatch causes the same MeasuringInput issue described in the problem statement.

10. Verification Procedure

1. After applying all fixes, go online and observe the OB1 average cycle time. It should be under 2 ms with the original HMI configuration.
2. Switch to the new screen with the two Graphic Views and confirm the cycle time does not exceed 4 ms.
3. Trigger a probe event on the measuring input and verify the MeasuredValue updates within 1 IRT cycle (~1 ms).
4. Run the three V90 axes simultaneously and verify no axis start delay is observed.
5. Open Online & Diagnostics > Diagnostics buffer on the CPU and verify no PROFINET sync violation entries are present.
6. Open System diagnostics > Communication on the HMI and verify the read request rate is under 100 requests per second.

Pass criteria: OB1 average < 2 ms, OB1 max < 5 ms, no PROFINET sync violations, probe values update in real time, axis start delay not perceptible.

11. Preventive Best Practices

• Default HMI tag acquisition to 1 s. Use 100 ms only for tags that genuinely need 10 Hz update and that the operator perceives as a stop-motion difference.
• Always use Update if visible on Basic panels unless the tag is on every screen.
• Always centralize HMI tags in a single DB. The pattern is: production DBs → HMI DB → WinCC tags. Never let WinCC access the same DB the program is writing to at high frequency.
• Set communication load to 50% for motion applications as a baseline. Lower values are acceptable for non-motion CPUs but will manifest as cycle jitter on motion jobs.
• Keep OB1 cycle time < 50% of the MC-Servo cycle. The MC-Servo OB runs at the PROFINET send cycle (1 ms). If OB1 is > 0.5 ms, jitter becomes visible.
• Use symbolic access only. Absolute addressing (e.g., DB100.DBX0.0) bypasses the symbol table and prevents WinCC from optimizing the read request bundling.
• Limit Graphic Views to one per screen. Each Graphic View re-samples its inputs at the panel's internal rate. Multiple views on the same screen multiply the request rate.
• For systems with > 50 HMI tags at 100 ms, use a Comfort panel or WinCC Runtime Advanced on a PC. The Basic panel's internal scheduler is the bottleneck once you cross ~40 tags at 100 ms.

12. TIA Portal V16 Parameter Reference

13. Troubleshooting Matrix

14. Common Configuration Mistakes

• Setting HMI tag Acquisition cycle to 100 ms as a project default. The default in WinCC is 1 s; reducing to 100 ms should be a per-tag decision.
• Using Cyclic continuous on tags that are on a single popup screen. The popup will not close the tag's polling, only changing the active screen does (and popups do not block the underlying screen's tags on Basic panels).
• Forgetting to recompile the HMI after changing the DB structure. The panel may retain the old tag list and request non-existent addresses, generating diagnostic buffer entries "Access error".
• Mixing absolute and symbolic addressing. WinCC bundles symbolic reads; absolute reads are individual.
• Not enabling Optimized block access on the HMI DB. Optimized access removes the absolute address and forces symbolic, which improves bundling.

15. Why 50% Communication Load Works for This Configuration

The user's final fix - raising communication load to 50% - is valid because the project has 30 tags at 100 ms (300 requests/s). At 30% communication load with a 4 ms OB1, the CPU has 1.2 ms of communication budget per cycle. 30 tags at 100 ms means each tag is requested every 25 cycles (100 ms / 4 ms). The instantaneous burst at 100 ms is 30 requests, which requires ~3-5 ms of communication time. This exceeds the 1.2 ms budget and OB1 is stalled. At 50% communication load (2 ms per 4 ms cycle), the 3-5 ms burst is still too long, but the scheduler spreads the requests across multiple cycles and the OB1 jitter is reduced to a few hundred microseconds - imperceptible to the motion system.

The proper engineering practice is to combine both: reduce HMI tag rate AND set communication load appropriately. The 50% setting alone is a band-aid, not a solution, because the HMI DB pattern is not yet optimized.