Resolving G120 CU250S-2 PN 4 ms Isochronous IRT Update Issue

David Krause18 min read
SiemensTIA PortalTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Problem Summary

When integrating a SINAMICS G120 frequency inverter equipped with a CU250S-2 PN Control Unit (part number 6SL3246-0BA22-1FA0) into a SIMATIC S7-1500 system built around a CPU 1516-3 PN/DP on PROFINET IRT with isochronous mode enabled, engineers frequently observe that the drive's process data (PZD) refreshes at 4 ms intervals even though the PROFINET send clock, OB61 cycle, and PIP1 assignment are all configured to 1 ms. A drive-side trace started from Startdrive shows the speed setpoint at p1070 and the connected receive word from r2050 stepping at 4 ms, while the PLC project reports a bus cycle of 1 ms. This discrepancy between PLC-side bus cycle and drive-side process data update is the single most common isochronous IRT commissioning defect on the SINAMICS G120 platform.

This article documents the four typical root causes, the diagnostic parameters on the drive that distinguish between them, the precise TIA Portal configuration sequence required to bring the bus, the OB, and the drive into alignment, and a field-tested troubleshooting matrix that covers the configuration pitfalls observed in real commissioning. The principles apply to TIA Portal V15.1 through V20 paired with SINAMICS G120 firmware V4.6 through V5.2 SP3.

Diagnostic decision path: before changing any parameter, read the drive-side diagnostic group r2064 online. If r2064[0] (actual bus send clock) reports 1000 µs but the process data still steps at 4 ms, the drive is the source of the slowdown. If r2064[0] reports 4000 µs, the bus itself is at 4 ms and the PLC configuration must be fixed first.

Isochronous IRT Fundamentals

PROFINET IRT (Isochronous Real-Time) is the deterministic, hardware-synchronized variant of PROFINET. Unlike PROFINET RT, where cycle times depend on network load and switch buffering, IRT reserves dedicated bandwidth in a phase-shifted time window so that all configured IO devices read inputs and write outputs inside that reserved slot with sub-microsecond jitter. PROFINET IRT is documented in the Siemens PROFINET RT vs IRT reference material and in the TIA Portal online help for IRT configuration.

Siemens distinguishes two IRT operating modes:

  • IRT "high performance" — the bandwidth and topology are planned in advance; non-IRT devices may share the segment. Recommended for mixed PROFINET segments where PROFINET RT devices must coexist with IRT drives.
  • IRT "high flexibility" — every device on the line must be part of the sync domain and IRT-capable. Used for tight motion applications where no non-IRT device can be tolerated.

"Isochronous" mode is the further step that links the bus cycle to a Synchronous Cycle OB (OB61 to OB64) in the CPU. At the start of the OB, the controller reads all isochronous inputs in one shot via SYNC_PI; at the end of the OB, the controller writes all isochronous outputs in one shot via SYNC_PO. The bus cycle therefore becomes the deterministic update rate for the application. The PIP (PROFINET IO Process Image Partition) ties this mechanism together: a PIP owns a subset of I/O addresses, and OB61 is bound to that PIP so that SYNC_PI(PIP1) copies inputs from the bus into the process image and SYNC_PO(PIP1) flushes outputs back to the bus.

The relationship between bus cycle, OB cycle, and PIP is critical for motion. The PIP must own the isochronous IO of every device that participates in the synchronized application, and the OB61 cycle must equal the bus send clock. If OB61 is set to 1 ms while the bus is at 4 ms, the application executes with the lower of the two rates; if OB61 is set to 1 ms and the drive is internally reduced to 4:1, the OB fires faster than the drive data refreshes and the process data appears stale.

The S7-1500 family — including CPU 1516-3 PN/DP — exposes PROFINET IRT on interface 1 (X1) with an integrated 2-port switch, plus an additional PROFINET RT interface on X2. Only the IRT-capable interface can carry the sync domain.

Hardware and Firmware Prerequisites

Before bringing up isochronous IRT, confirm that every device in the sync domain supports the minimum cycle time required by the application. The minimum IRT send clock of the network is bounded by the slowest device in the line.

Component Part Number Minimum IRT Cycle Isochronous PZD Support
SINAMICS G120 + CU250S-2 PN 6SL3246-0BA22-1FA0 500 µs (firmware ≥ 4.7 SP3), 1 ms (firmware 4.6) Yes (Standard PROFIdrive telegrams 1, 2, 3, 5, 6, 7, 9, 110)
SIMATIC CPU 1516-3 PN/DP 6ES7516-3AN02-0AB0 250 µs Yes (OB61–OB64, PIP1–PIP4)
ET 200SP PN Head Module 6ES7155-6AUxx-xxxx 1 ms Yes (when configured as IRT slave)
PROFINET cable 6XV1840-2AH10 (or equivalent Cat 5e / Cat 6) n/a n/a (cabling determines jitter margin)

The CU250S-2 PN firmware version determines whether 500 µs is achievable in practice. Confirm the firmware using parameter r0018 on the drive and via Startdrive → Online → Drive Information. CPU 1516-3 PN/DP hardware details, including the integrated 2-port IRT switch on interface X1 and the secondary PROFINET RT interface on X2, are documented in the PI Product Finder entry for CPU 1516-3 PN/DP.

If the network includes an ET 200SP head module, its send clock becomes the lower bound for the entire sync domain. The minimum IRT send clock cannot drop below what the ET 200SP supports (typically 1 ms). Forcing the network lower either fails compile or causes the drive to negotiate the next higher cycle during sync. The S7-1200 G2 generation of CPUs provides a useful comparison for what a fully IRT-capable node looks like — see the TIA Portal Cloud documentation on IRT for the S7-1200 G2.

Root Cause Analysis: Why 4 ms Instead of 1 ms

When the PLC project reports 1 ms but the drive trace still shows 4 ms, the discrepancy has one of four typical sources. Each is documented below together with the drive-side parameter that proves it.

Cause 1 — Reduction ratio higher than 1:1

PROFINET IO allows each device to run at a fraction of the network send clock via the reduction ratio. If the CU250S-2 PN is configured with reduction ratio 4:1, the effective drive update is 1 ms × 4 = 4 ms even though the network itself runs at 1 ms. TIA Portal sometimes inherits a default reduction ratio from the GSDML file or from the Startdrive device description when the project is regenerated, when the device is replaced, or when the project is upgraded between TIA Portal versions.

Diagnostic: open the device properties of the CU250S-2 PN in TIA Portal → "PROFINET interface" → "Real-time settings" → "Reduction ratio". A value of 1 (1:1) is required for isochronous mode at the network send clock. Confirm online in Startdrive by reading the PROFINET diagnostic group r2064 (actual send clock, actual cycle time, jitter). When r2064[0] = 1000 µs but the trace shows 4 ms steps, the drive has accepted the bus cycle but is internally reducing.

Cause 2 — Free Telegram 999 without an isochronous slot

Telegram 999 (free configurable PZD) lets the user define a custom length, but the slot mapping for isochronous data is only guaranteed to be active for the standard PROFIdrive telegrams (1, 2, 3, 5, 6, 7, 9, 110). When the slot configuration of Telegram 999 is not explicitly aligned with the isochronous slots of the drive, the drive defaults to a non-isochronous update path that runs at the firmware default of 4 ms.

Resolution: replace Telegram 999 with the appropriate standard telegram for the application. For speed control of the G120 with one encoder, Telegram 3 is the most common choice. For speed control without encoder, Telegram 1. Re-compile, download the HW config to the CPU, power-cycle the drive if prompted, and observe the drive-side trace again.

Cause 3 — Startdrive vs GSDML configuration mismatch

When the G120 is inserted into the TIA Portal project as a "SINAMICS G120" device via Startdrive, the GSDML-derived slot configuration is replaced by the Startdrive device view. Some TIA Portal versions generate the isochronous configuration only when the device is inserted via the GSDML file directly. When Startdrive is used and the slot checkbox for "Isochronous mode" is left in its default state, the bus cycle is correct but the drive-side isochronous enable may be off, producing 4 ms data with a 1 ms bus.

Resolution: open the device view of the G120 in TIA Portal → Properties → "PROFINET interface" → "Isochronous mode" → check "Activate isochronous mode" → set the reduction ratio to 1. If Startdrive was used and the checkbox is grayed out, switch the device to a GSDML device: right-click the G120 → "Change device" → select the GSDML variant. Re-download the HW config.

Cause 4 — Mixed topology or wrong sync master assignment

The "high flexibility" IRT mode requires every device on the line to be part of the sync domain. If the ET 200SP is not assigned to the sync domain — or if the sync master / sync slave roles are mis-assigned — TIA Portal silently raises the cycle to the next stable value, which is often 2 ms or 4 ms. The same effect occurs when the topology editor (interconnect ports) does not match the physical cabling.

Resolution: open "Devices & Networks" → select the PROFINET interface of the CPU 1516-3 → "Real-time settings" → "Synchronization role" → set the CPU as "Sync master" and the G120 and ET 200SP as "Sync slave". Re-check "Send clock" and reduction ratio on every slave. Open the Topology view and verify that every port interconnection matches the physical wiring — from CPU X1 P1 to G120 X150 P1, from G120 X150 P2 to ET 200SP X1 P1. Best practice for IRT high performance is documented in the TIA Portal V20 help on configuring IRT with high performance.

Required TIA Portal Configuration Sequence

Apply the configuration in the order below. Skipping steps or applying them out of order reproduces the symptoms in the previous section.

  1. Insert the CPU 1516-3 PN/DP into the project. Confirm the firmware version supports OB61.
  2. Insert the G120 via GSDML (preferred for isochronous applications) or via Startdrive. If Startdrive is used and the isochronous slot is greyed out, switch the device to a GSDML device.
  3. Insert the ET 200SP PN head module if present in the network.
  4. Interconnect all three PROFINET ports on interface X1 of the CPU. The CPU 1516-3 PN/DP has an integrated 2-port switch; the line can run CPU X1 P1 → G120 X150 P1 → G120 X150 P2 → ET 200SP X1 P1 without an external switch.
  5. Open "Devices & Networks" → PROFINET view → select the CPU → assign role "Sync master". Assign "Sync slave" to the G120 and ET 200SP.
  6. For the G120: open Properties → PROFINET interface → "Real-time settings" → Send clock 1.000 ms → Reduction ratio 1 → check "Activate isochronous mode".
  7. For the ET 200SP: same send clock, same reduction ratio 1, same isochronous mode if the ET 200SP carries motion IO.
  8. Open "Devices & Networks" → Topology view. Add port interconnections: CPU X1 P1 → G120 X150 P1, G120 X150 P2 → ET 200SP X1 P1. Topology must match the physical wiring exactly.
  9. Select "IRT" mode → "high performance". Do not use the "Maximum 90% cyclic IO data" bandwidth preset when isochronous mode is active — this setting compresses the acyclic window and can desynchronize the bus at sub-millisecond cycles. Use the default "Maximum 50% cyclic IO data" preset or the "high flexibility" preset instead.
  10. Assign the G120 and ET 200SP to PIP1 in their device properties. The PIP assignment links each device to OB61.
  11. Compile the project. If TIA Portal reports "isochronous OB has no isochronous data", at least one IO device is missing the PIP1 assignment. Re-check step 10.

Background on IRT bandwidth reservation and the difference between "high performance" and "high flexibility" is given in the Siemens PROFINET RT vs IRT reference document.

Drive Parameter Configuration

Even when the PLC project is correct, the drive must be in the matching state. Verify the following SINAMICS parameters online:

Parameter Meaning Required Value
p0015 Macro drive configuration Select macro that loads isochronous PROFINET configuration (e.g., macro 7 or 15)
p0922 IF1 PROFIdrive PZD telegram selection 1, 2, 3, 5, 6, 7, 9, 110 — or 999 only if isochronous slot is explicitly mapped
p1070[0] Main setpoint (CI) Connected to the PZD receive word (e.g., r2050[0] for setpoint, r2050[1] for second word)
r0018 Firmware version ≥ 4.7 SP3 for 500 µs, ≥ 4.6 for 1 ms
r2050 PROFINET PZD receive (process data from PLC) Must change at the bus send clock
r2064[0] Actual PROFINET send clock (µs) 1000 (must equal PLC send clock)
r2064[1] Actual PROFINET cycle time (µs) 1000 (must equal the application cycle)
r2064[2] PROFINET jitter (µs) Typically < 5, alarm if > 50

If r2064[0] reports 4000 µs and r2064[1] reports 4000 µs, the bus has negotiated a 4 ms cycle — go back to the PLC-side send clock and reduction ratio. If r2064[0] reports 1000 µs but r2064[1] reports 4000 µs, the drive has accepted the 1 ms bus but is internally reducing to 4 ms — check the PIP assignment, the slot configuration, and any isochronous-mode enable parameter on the drive. If both report 1000 µs but the process data trace still shows 4 ms steps, the trace itself is at 4 ms (i.e., the trace buffer is being undersampled) and not the application.

PLC Program Implementation

OB61 must follow the rules of the synchronous cycle. A minimal compliant structure in SCL is shown below.

// OB61 — Synchronous Cycle, attached to PIP1
// Cycle time = 1 ms (must equal the PROFINET send clock)

SYNC_PI(PIP := 1);   // copy isochronous inputs from PIP into the process image

// Read process data from the G120
iSetpointWord    := "G120_IN".PZD1;   // word 0 from CU250S-2 PN (mapped to r2050[0])
iActualSpeedWord := "G120_IN".PZD2;   // word 1 from CU250S-2 PN (mapped to r2050[1])

// Application logic — keep OB61 execution short and deterministic
fbSpeedControl(
    iSetpoint := iSetpointWord,
    iActual   := iActualSpeedWord,
    qOutput   => "G120_OUT".PZD1       // word 0 to drive (mapped to p1070 via r2060[0])
);

SYNC_PO(PIP := 1);   // copy outputs to PIP at end of OB

Determinism rules for OB61:

  • The execution time of OB61 must be shorter than the OB cycle (1 ms) and also shorter than the time between the bus input time (Ti) and the bus output time (To). Ti and To are visible in the device properties of the G120 in TIA Portal and are typically < 200 µs at 1 ms cycle.
  • Call SYNC_PI and SYNC_PO exactly once per OB per PIP. Multiple calls cause undefined behaviour and can produce the irregular update pattern seen in the source trace.
  • Do not call non-deterministic system functions inside OB61, including RDREC / WRREC for IRT diagnostics, DP_PRAL, or WRITEDBL. These break the deterministic time base.
  • Do not block OB61 with WAIT, file operations, or web-server calls. Move all of those into OB1 (the free cycle) or a dedicated background OB.

Verification Procedure

Once the configuration is in place, validate the result in four places: drive side, PLC online, bus monitor, and process value behaviour.

  1. Drive trace: in Startdrive → Trace → add signal r2050[0] (or p1070), r2064[0], r2064[1]. Set trace time base to 0.5 ms. The setpoint waveform must step at 1 ms intervals, not 4 ms.
  2. Drive parameter: read r2064[0..2] on the drive and confirm r2064[0] = r2064[1] = 1000 and r2064[2] < 50.
  3. PLC online: open "Devices & Networks" → Online → Diagnostics → PROFINET diagnostics. The "Quality" of the isochronous IO must be "Good" and the "Cycle time" must equal the configured 1 ms. If "Quality" is "Bad" or "Cycle time" is wrong, the PIP / OB61 binding is incorrect.
  4. Bus monitor: in TIA Portal → Online → PROFINET diagnostics → Bus monitor. Inspect the IRT cycle, the sync master ID, and the jitter per device. The jitter column should show values < 5 µs on every IRT slave.

If the trace still shows 4 ms after applying every previous section, temporarily remove every other PROFINET device except the CPU and the G120. A barebones two-node IRT topology isolates whether the 4 ms comes from the drive alone or from a neighbouring device forcing the cycle higher.

Troubleshooting Matrix

Symptom Likely Cause Diagnostic Fix
Drive trace at 4 ms; r2064[0] = 1000 µs but r2064[1] = 4000 µs Drive-internal reduction ratio 4:1 Check slot assignment and PIP binding Reassign slot to isochronous, verify PIP1 in device properties
Drive trace at 4 ms; r2064[0] = 4000 µs Bus cycle at 4 ms TIA Portal PROFINET diagnostics Set send clock to 1 ms on every sync slave
TIA Portal compile error: "isochronous OB has no isochronous data" No IO device assigned to PIP1 Device properties → PIP Assign G120 / ET 200SP to PIP1
Jitter > 50 µs Non-deterministic user code in OB61 OB61 runtime measurement Shorten OB61; remove blocking calls
Compile passes but no isochronous update at all Telegram 999 without isochronous slot Device view → slot configuration Switch to standard PROFIdrive telegram (1, 2, 3, …)
Cycle time drifts to 2 ms or 4 ms after re-routing Topology does not match physical wiring Topology view → port interconnection Re-enter topology to match cabling
"High flexibility" IRT with mixed PROFINET segment Non-IRT device on the line Bus monitor Switch to "high performance" IRT or remove the non-IRT device
Reduction ratio greyed out Startdrive device, not GSDML device Right-click device → Change device Switch to GSDML variant of the G120
OB61 runtime exceeds cycle OB61 contains heavy code OB61 run-time statistics Move non-deterministic code into OB1

Field-Proven Tips

  • Free Telegram 999 is convenient for non-time-critical IO. For isochronous motion, always use a standard PROFIdrive telegram (1, 2, 3, 5, 6, 7, 9, or 110). Telegram 3 is the most common choice for the G120 with one speed setpoint and one encoder actual value.
  • Bandwidth setting: the "Maximum 90% cyclic IO data" preset maximizes acyclic throughput but compresses the cyclic window, which can break isochronous mode at sub-millisecond cycles. Leave the setting at the TIA Portal default unless a specific acyclic load requires the change.
  • Topology editor: even when using IRT "high performance", create the topology explicitly. The implicit topology that TIA Portal can auto-generate is not always correct for the second port of the CPU or for cascaded switches.
  • Firmware consistency: keep the CPU firmware, the G120 firmware, and TIA Portal version aligned. A V20 project opened in V15.1 will silently drop isochronous settings that V15.1 does not understand.
  • Sync master: only one device in the sync domain can be sync master. The CPU 1516-3 PN/DP must be the sync master. If the G120 or the ET 200SP is set as sync master, the cycle will be wrong.
  • Cycle budget: at 1 ms cycle with 8 IN / 8 OUT words, the cyclic payload is 16 words × 16 bits × 1000 Hz = 256 kbit/s of user data per direction. This is well within the IRT reserved bandwidth and leaves the acyclic window intact for alarms and diagnostics.

Summary

A SINAMICS G120 with CU250S-2 PN supports isochronous IRT on PROFINET, but achieving a 1 ms update requires alignment across three layers: the PLC project (TIA Portal send clock, OB61, PIP1, IRT mode, sync master), the device configuration (standard PROFIdrive telegram, isochronous slot, slot reduction ratio), and the drive firmware (≥ 4.6 for 1 ms, ≥ 4.7 SP3 for 500 µs). When the drive trace reports 4 ms even though the PLC reports 1 ms, walk through reduction ratio, telegram choice, Startdrive-vs-GSDML selection, and topology / sync master configuration in that order — the resolution is almost always in one of those four.

Bus / OB61 / Drive Update Timing (1 ms per division) PROFINET Bus OB61 Drive (wrong: 4 ms) Drive (right: 1 ms) → Time (each tick = 1 ms) Wrong: drive skips 3 out of every 4 OB61 cycles (effective 4 ms update) Right: drive updates every OB61 cycle (1 ms update)

Does the CU250S-2 PN (6SL3246-0BA22-1FA0) support isochronous IRT?

Yes. The CU250S-2 PN supports isochronous IRT for PZD telegrams with a minimum cycle of 1 ms on firmware 4.6 and 500 µs on firmware 4.7 SP3 and newer. Isochronous capability must be activated in the device properties in TIA Portal (Startdrive or GSDML device) and confirmed online via the PROFINET diagnostic group r2064.

Why does my G120 drive update every 4 ms even though the PROFINET send clock is 1 ms?

The four typical reasons are: (1) reduction ratio on the G120 is 4:1 instead of 1:1; (2) Telegram 999 is used without an isochronous slot mapping; (3) Startdrive overrides the GSDML isochronous configuration; (4) another device in the sync domain (e.g., an ET 200SP) forces the cycle higher. Read r2064[0] and r2064[1] to determine whether the bus or the drive is at 4 ms.

Should I use Startdrive or a GSDML file to insert the G120 into TIA Portal?

For non-isochronous applications Startdrive is the preferred workflow because of its deeper parameter access. For isochronous applications, inserting the device via GSDML (or switching to a GSDML device if Startdrive was used) gives the cleanest isochronous configuration and avoids the slot mapping issue that causes 4 ms fallback with Telegram 999.

Which Telegram should I use for isochronous speed control of the G120?

Telegram 3 (one setpoint, one actual value with encoder) or Telegram 1 (one setpoint, one actual value without encoder) are the most common choices. Both support isochronous mode. Telegram 999 can be used when the slot configuration is explicitly mapped to isochronous slots, but it adds configuration risk and is rarely worth the effort on a standard G120.

How can I verify that isochronous mode is actually active at runtime?

Read drive parameters in the PROFINET diagnostic group r2064 (actual send clock, actual cycle time, jitter). In TIA Portal open Online → PROFINET diagnostics and confirm "Quality" is "Good" and "Cycle time" equals the configured value. Add r2064[0] to a Startdrive trace and confirm the waveform steps at the configured interval.

Back to blog