Sizing SIMOTION D445-2 System Load: Virtual vs Real Axes

Sizing SIMOTION D445-2 System Load: Virtual vs Real Axes

When commissioning a SIMOTION D445-2 motion controller, the system load and remaining cycle-time reserve are functions of the technology objects (TOs) configured, the program execution time, the servo / IPO / position-controller clock selection, and the I/O / drive communication load. In the early project phase, the SINAMICS drives and CX32-2 controller extensions are not yet on the bench, so the engineer must decide how to model axis load on the controller so that the predicted headroom is meaningful once the real hardware is wired.

This reference documents the three axis categories that SIMOTION exposes, how each contributes to controller load, the correct way to drive a D445-2 in a pre-hardware environment, the limits of the SIZER tool, and a verification procedure that produces a defensible cycle-time budget before any drive is commissioned. The recommendations align with the SIMOTION D4x5 commissioning manual and the SIZER for SIMOTION methodology.

1. Problem Statement: Sizing D445-2 Before Hardware Arrives

The D445-2 is the second-highest performance class in the SIMOTION D4x5-2 line, sharing a single common processor core with the SINAMICS S120 drive line. The controller exposes a PROFIBUS Integrated master and a PROFINET interface, and up to six SINAMICS CX32-2 controller extensions can be added per line. Because the D445-2 executes motion control, the closed-loop position controller, and the SINAMICS drive coupling on the same processor, the cycle-time budget is more constrained than a stand-alone PLC of equivalent class.

The challenge is that, with the controller on the bench and no SINAMICS hardware connected, the engineer needs to predict the residual cycle-time margin after the drives and CX32-2 modules are added. Three questions dominate this task:

1. Does the controller run the same load with simulated axes as it does with real axes?
2. How much of the load is generated by the technology objects themselves versus the drive / encoder communication?
3. How accurate is the SIZER prediction once the controller is connected to a live system?

The source community has confirmed that all three axis categories differ in their contribution to controller load, and that SIZER predictions are systematically optimistic for the cycle time. The remainder of this document quantifies those differences and gives a verification procedure.

2. SIMOTION D4x5-2 Platform and CX32-2 Architecture

The D445-2 is a slot PLC for SIMOTION D, mounted on the left side of a SINAMICS S120 line-up. A single D445-2 module integrates:

• The SIMOTION runtime (motion, PLC, and technology functions).
• The SINAMICS closed-loop control (CU320-2 class) for up to six drives on the integrated PROFIBUS.
• Two PROFINET interfaces, one of which supports IRT and is the recommended port for isochronous drive communication.
• One PROFIBUS Integrated master (DP) for additional drives and CX32-2 modules.

The CX32-2 is a SINAMICS controller extension that adds another CU320-2-class controller with up to six additional drives. It is inserted onto the PROFIBUS Integrated master of the D4x5-2 and behaves to the application like a remote SINAMICS line-up. The commissioning manual for the D4x5-2 explicitly documents this drag-and-drop procedure: SIMOTION D4x5 Commissioning Manual (PDF).

2.1 Drive Count and Bus Bandwidth Envelope

The D4x5-2 plus one or more CX32-2 modules is the standard topology for high-axis-count machines. The relevant bus-bandwidth envelope for sizing is:

The cycle-time impact of a CX32-2 is not zero. Even with no drives actively moving, the CX32-2 participates in the PROFIBUS isochronous cycle and contributes a per-tick protocol overhead. This matters when you compare a bench test (no CX32-2) with the production system (CX32-2 installed).

3. Axis Categories in SIMOTION: Real, Virtual, and Simulated

SIMOTION exposes three categories of TO_Axis. The category is selected when the axis is created in SCOUT / TIA Portal under the "Axis type" property. The category determines whether the runtime allocates encoder, drive, and following-error resources for the axis, and that allocation is what drives the system load.

3.1 Why the Three Categories Behave Differently

The position controller is the dominant consumer of cycle time in a motion controller. With a real axis, the controller reads the encoder telegram, executes the position-control algorithm, and emits a setpoint telegram, all on the same isochronous tick. With a virtual axis, the read and write are routed to an internal encoder model on the same processor, so the bus load is removed but the algorithm still runs. With a simulated axis, the position controller is largely bypassed; the setpoint is generated but the closed loop is not closed in the conventional sense.

For this reason, the answer to the original question is unambiguous: yes, there is a meaningful difference between simulated, virtual, and real axes in SIMOTION load. A bench test using only simulated axes will report a system load that is significantly lower than the production load with real drives.

4. Cycle Time Architecture: Servo, IPO, and Position Controller Clocks

SIMOTION partitions motion execution into a hierarchy of cycle clocks. The D445-2 defaults are documented in the commissioning manual and can be reconfigured under the execution system. Understanding the clock hierarchy is the first step in interpreting a system load measurement.

The three clocks, in order of increasing period, are:

1. Servo (Servo_fast / Servo). The fastest clock. Executes the position controller and reads / writes the PROFIdrive telegrams. Default on D4x5-2 is typically 1.0 ms. Every drive and every CX32-2 attached is served on this clock.
2. IPO (Interpolator). Computes the next setpoint. Default is typically 2x to 4x the servo clock. The setpoints are then handed to the servo for the next tick.
3. IPO_2 / user task. Where MCC (Motion Control Chart) charts, the PLC program, and any background tasks execute. The user selects this period.

The system-load measurement reported by SCOUT or by the runtime is essentially the residual headroom on the slowest of these clocks (typically IPO or IPO_2, whichever the user chose to monitor). If the slowest clock is fully loaded, the servo clock will begin to slip, and motion faults will follow.

4.1 The Ratio Between Clocks

Increasing the servo clock from 1.0 ms to 0.5 ms roughly doubles the per-axis CPU load for real and virtual axes. A bench test that uses simulated axes at 1.0 ms will, on the production system at 1.0 ms, often saturate the IPO. Re-validate the system load after every clock-ratio change.

5. SIZER for SIMOTION: Methodology and Known Optimism

SIZER is the Siemens engineering tool for selecting and sizing SIMOTION hardware. The SIZER for SIMOTION module accepts a project description: the number of axes by category (real, virtual, simulated), the technology objects used (TO_Positioning, TO_Gear, TO_Cam, TO_Controller, TO_SynchronousOperation), the cycle clock selection, the expected number of MCC commands, and the program complexity, and it returns a recommended SIMOTION module, a recommended CX32-2 count, and a predicted cycle-time utilization.

5.1 SIZER Methodology

1. Load the project description, including axis count, technology objects, and cycle times.
2. Select candidate controllers from the SIMOTION catalog. For high-axis-count projects the choice is between the D445-2, the D455-2, and a multi-controller topology.
3. SIZER returns a load estimate and a recommended hardware configuration.
4. The engineer iterates until the load estimate is acceptable.

5.2 Known Optimism of SIZER Cycle-Time Predictions

The source community has documented that SIZER is "a little bit optimistic" when predicting cycle times. The optimism comes from three sources:

1. Simulated-axis model. SIZER's reference CPU load is calibrated against a mix of axis categories, but it cannot know the exact split the project will end up with. Projects that drift toward more real axes than originally planned will exceed the SIZER prediction.
2. No bus jitter. SIZER assumes a clean isochronous bus. In the field, PROFIBUS and PROFINET jitter can be 5 - 10 percent of the bus cycle, and SIZER does not budget for it.
3. No I/O jitter. SIZER does not model the load from PROFINET I/O devices or distributed I/O on the same network. Real systems share bandwidth with these devices.

6. Configuring and Exercising Technology Objects Without Hardware

The bench procedure below produces a system-load number that can be extrapolated to the production system. It is the procedure the source community converged on for pre-hardware sizing.

6.1 Project Setup

1. Create a SCOUT (or TIA Portal with SIMOTION) project and select the D445-2 as the target.
2. Add the planned technology objects, one per axis and one per auxiliary function. Recommended TOs to add even on the bench:
   • TO_Axis for every real, virtual, and simulated axis.
   • TO_Positioning for every positioning axis.
   • TO_Gear for every gearing relationship.
   • TO_Cam for every camming relationship.
   • TO_Controller for pressure / force / tension control.
3. Set the axis type for each TO_Axis to Virtual for the worst-case planning, or to Real for the axes that will connect to CX32-2 modules in the production system. Real axes without a drive will report a configuration error and must be temporarily set to Simulated for the bench run, then switched back to Real at commissioning.

6.2 Cycle Clock Selection

Set the cycle clocks to the values the production system will use. The default values are documented in the D4x5 commissioning manual. Do not run the bench at 4.0 ms servo and assume the production system at 1.0 ms servo will be linear in load; it is not, because the bus load is the dominant term.

6.3 Driving the TOs from MCC or ST

To make the bench run a realistic load, the technology objects must be active. A static configuration that simply exists in the project but is not executed contributes almost no load. The minimum MCC chart or ST program to add is:

// Drive a virtual positioning axis in a loop to exercise the TO
// Replace MyAxis with the actual TO_Axis name
VAR
    bRun : BOOL := TRUE;
    fPos : LREAL := 0.0;
END_VAR

IF bRun THEN
    fPos := fPos + 0.001;          // 1 mm per iteration
    IF fPos > 1000.0 THEN
        fPos := 0.0;
    END_IF;
    MyAxis.Position := fPos;        // forces the IPO to interpolate
    MyAxis.Velocity := 100.0;       // mm/s nominal
END_IF;

For a gearing relationship, follow the master reference with a ratio update on every IPO tick. For a cam, run the master at a non-zero velocity and let the slave interpolate. The point is to make the IPO and servo do real work, not to leave them idle.

6.4 Capturing the Load

SIMOTION exposes system-load values through the runtime's diagnostic pages. The two values to capture are:

1. Servo utilization. The percentage of the servo clock consumed by the position controllers. This is the metric that must stay below approximately 80 - 90 percent in steady state.
2. IPO utilization. The percentage of the IPO clock consumed by interpolation and user tasks. This is the metric that drives the overall machine responsiveness.

Read these values from SCOUT under Target system > Diagnostics > System utilization, or by reading the corresponding system variables from a connected HMI. Run the chart for at least 60 s to capture the worst-case slice; short samples will under-report.

7. Empirical System Load Measurement on the Controller

Once the bench setup is running, the engineer should add measurements in three configurations to bracket the production load:

7.1 Configuration A: All Simulated Axes

All TO_Axis set to Simulated. The MCC / ST program is active. This configuration gives the lower bound of system load. It is the case the source community explicitly warns against using as the production number.

7.2 Configuration B: All Virtual Axes

All TO_Axis set to Virtual. The MCC / ST program is active. The position controller is exercised, but the bus load is removed. The configuration sits between simulated and real in load.

7.3 Configuration C: Real Axes with a Stubbed Drive

For an axis that is going to connect to a CX32-2 in the production system, it is possible on the bench to set the TO_Axis to Real and connect to a stub PROFIdrive device that returns a fixed setpoint telegram. This is the most accurate pre-hardware measurement available, and it includes the bus load term. The SIZER prediction should be compared against this configuration, not against A or B.

7.4 The Decision Path When Hardware is Unavailable

If a stubbed drive is not available, the decision path is:

1. Run Configuration B (virtual). Record the IPO and servo utilization.
2. Apply the bus-load correction. The bus-load term can be estimated as the number of real axes times approximately 50 - 100 microseconds per tick on a D4x5-2 with a 1.0 ms servo clock, divided by the IPO clock period. (This is a planning estimate, not a measurement. Replace with a measured value when a stubbed drive is available.)
3. Reserve an additional 10 - 20 percent for jitter and unforeseen TOs, per the SIZER optimism correction in section 5.2.
4. Submit the result to SIZER, then compare and reconcile.

8. Correction Factors When SIZER Overestimates Headroom

The correction factor methodology below reconciles the SIZER prediction with the bench measurement. Apply it once, in this order:

1. Simulated-to-real correction. If the bench used simulated axes but the production system has real axes, multiply the measured load by the ratio in the table in section 3. Validate the ratio by switching one axis to virtual on the bench and observing the change.
2. Bus-load correction. If the bench had no CX32-2 and the production system will have CX32-2 modules, add the per-CX32-2 isochronous bus load. A reasonable planning estimate is 30 - 60 microseconds per tick per CX32-2, scaled by the number of drives on that CX32-2.
3. Jitter correction. Add 5 - 10 percent of the servo clock period to the predicted headroom, in line with the bus jitter observed in the field. SIZER does not budget for this.
4. Software version correction. Different firmware versions of the SIMOTION runtime have different code paths for the position controller. Pin the firmware version in SIZER and on the bench, and verify the SIZER estimate was generated against the same version.

9. CX32-2 Specific Load Considerations

The CX32-2 is the only controller extension that the SIMOTION D4x5-2 commissioning manual addresses by drag-and-drop onto the PROFIBUS Integrated master. Its presence has three effects on the D4x5-2 system load:

1. Isochronous bus overhead. Every CX32-2 participates in the PROFIdrive isochronous cycle, even with no drives connected. One tick of overhead per CX32-2 must be added to the bus-load correction.
2. Setpoint routing. Setpoints computed on the D4x5-2 are routed to the CX32-2 over PROFIBUS Integrated. The routing itself consumes a small amount of cycle time, dominated by the number of setpoints per tick.
3. Encoder feedback routing. Encoder feedback from drives on a CX32-2 is read by the D4x5-2 over the same PROFIBUS Integrated. The closed loop is closed on the D4x5-2, not on the CX32-2.

The commissioning manual linked above is the authoritative reference for the wiring, configuration, and diagnostic flow of the CX32-2. If the project will use a CX32-2, run the bench test with at least one stubbed drive on a stubbed CX32-2, even if it is just a single drive for a few minutes, to capture the bus-overhead term.

10. Field Commissioning Procedure for D445-2 with CX32-2

The procedure below is the minimum-viable path to a signed-off cycle-time budget on a D4x5-2 with at least one CX32-2. Run it in this order.

1. Load the SCOUT project and connect to the D445-2.
2. Confirm the firmware version of the SIMOTION runtime and the SINAMICS control unit match the versions in the project. Mismatched firmware is a common cause of unexpected bus load.
3. With all axes off, capture the baseline system load. The baseline should be less than 5 percent on the IPO and the servo.
4. Enable one axis at a time, in the order of the production system. After each axis is enabled, capture the system load and the time to steady state.
5. Enable the gearing and camming relationships one at a time. Each TO that touches the IPO adds a measurable load step.
6. Run the worst-case MCC program (peak velocity, peak acceleration, peak cam master velocity) for at least 5 minutes. Capture the maximum observed load on the IPO and the servo.
7. If the maximum observed load exceeds 80 percent on the servo or 75 percent on the IPO, stop and reduce the cycle time budget by one of:
   • Increasing the IPO clock period (4.0 ms instead of 2.0 ms).
   • Moving a portion of the user code from IPO_2 to a slower Background task.
   • Splitting the project across two D4x5-2 controllers with a CX32-2 on each.
8. Record the maximum steady-state load, the firmware version, the cycle clock configuration, and the active TO count. File this as the cycle-time baseline in the project folder.

11. Troubleshooting Matrix for Load and Cycle Issues

12. Frequently Asked Questions