Troubleshooting Siemens S7-1500 TO103 "Error in Drive Configuration Adaptation"

TO alarm 103 "Error in drive configuration adaptation" is one of the most disruptive faults encountered on SIMATIC S7-1500 and S7-1500T motion-control projects. It belongs to the configuration error number range (100-199) and, unlike operational faults, it cannot be cleared by toggling enable, power-cycling the drive, or re-downloading individual blocks. The alarm surfaces in the TIA Portal TO commissioning window, blocks axis motion, and on installations with many axes (the typical case is 8 to 24 positioning or synchronized axes) it can immobilise an entire machine after a single network disturbance.

This article provides the diagnostic procedure, the official Siemens acknowledgment method using MC_Reset with Restart = TRUE, and field-proven measures for preventing the fault from re-appearing after PROFINET interruption or runtime reconfiguration.

1. Problem Description

The fault is reported in three places simultaneously:

• TIA Portal online view: TIA Portal > Project tree > Technology objects > [TO name] > Commissioning > Status and error messages
• PLC diagnostic buffer: technology alarm with the identifier 103 and message text "Error in drive configuration adaptation"
• HMI alarm view (when the alarm is wired to an HMI tag, typically via the TO.AlarmXxxx status word)

Observable plant behaviour:

• The affected axis rejects MC_Power.Enable = TRUE or powers up and immediately drops enable.
• MC_MoveJog, MC_MoveAbsolute, MC_GearIn, and other motion commands return error IDs that map back to the configuration adaptation fault.
• All motion on the affected Technology Object is blocked until the alarm is cleared.
• When the trigger is a network interruption, multiple axes (frequently all axes sharing the same PROFINET line) raise the alarm simultaneously.

The Siemens technical documentation entry for this alarm is documented in the S7-1500 / S7-1500T Motion Control alarms and error IDs V7.0 manual and the corresponding V8.0 manual, both confirming alarm number 103 and the acknowledgment path described below.

2. Affected Platforms and Versions

The alarm has also been reported with SINAMICS S210 drives in Siemens support entry 109781853, where the underlying mechanism is identical: the TO detects a mismatch between the configured drive telegram and the drive actually online on PROFINET.

3. Root Cause

TO 103 is raised when the technology object's drive configuration adaptation step detects an inconsistency. The two underlying classes of mismatch are:

3.1 Configuration mismatch (static)

Data the technology object reads back from the drive (or expects to read back) does not match the data downloaded with the project. Typical items that are checked:

• Motor type / motor order number
• Direction of rotation (positive / negative polarity)
• Encoder type, resolution, and gear ratio
• Maximum speed, maximum acceleration, maximum jerk
• Mechanical system (load gear ratio, position tolerance, following error limits)
• Telegram selection (Standard Telegram 3, 5, 6, 9, Siemens Telegram 10x)

If any of these values diverge between the project, the drive parameter set, and the technology object data block, the TO rejects the assignment and raises 103.

3.2 Runtime mismatch (dynamic)

More commonly seen in production, this class is caused by something that changes the TO's view of the drive between two CPU stop/start cycles or during runtime:

• PROFINET interruption followed by a substituted device coming back with stale parameters
• Online modification of the mechanical settings (gear ratio, modulo value) while the axis is enabled
• Change of the position limit switch polarity or the software position limits during operation
• Drive firmware update performed without subsequent TO restart
• Replacement of a drive without re-running the drive configuration wizard
• HMI-driven writes to the TO data block that violate the configured adaptation rules

In the source incident (19 positioning axes on a single S7-1500T CPU), the trigger was a system-wide network error: all 19 objects went into 103 simultaneously because the PROFINET I/O connection was renegotiated and the drives came back online with parameter sets that the TO considered "changed". This is the canonical network-induced case.

4. Why the Standard Reset Path Does Not Work

Many operators attempt the following sequence first, and observe that the alarm persists:

1. Disable the axis (MC_Power.Enable = FALSE).
2. Call MC_Reset with Restart = FALSE (the standard "acknowledge drive error").
3. Re-enable the axis (MC_Power.Enable = TRUE).

The Siemens alarms / error IDs manual classifies alarm 103 as an alarm that "can only be acknowledged by performing a technology object restart". The alarm attribute table in both the V7.0 and V8.0 manuals indicates the acknowledgment mechanism is Remove enable, X15, which translates to the MC_Reset with Restart = TRUE command.

Downloading the technology object again (the workaround described in the original report) works only because the download implicitly triggers a reinitialisation of the TO instance DB, which clears the alarm. It is not the intended fix and is destructive to any in-process reference values; the correct API-level fix is described next.

5. Solution: MC_Reset with Restart = TRUE

The Siemens-documented recovery is to restart the technology object through the motion-control API:

1. Disable the axis by setting MC_Power.Enable = FALSE. Wait for the axis status to report Standstill or to confirm the axis is no longer enabled.
2. Call MC_Reset with Restart = TRUE while Axis = <axis handle> and Execute = TRUE.
3. Hold Execute = TRUE for at least one CPU cycle after MC_Reset.Done becomes TRUE.
4. Re-enable the axis with MC_Power.Enable = TRUE.
5. Re-issue the original motion command (for example MC_MoveAbsolute).

5.1 Structured Text implementation (SCL)

// Global tag for "error 103 detected" trigger (e.g. derived from TO.StatusWord
// or from the alarm handling OB that picks up the TechnologyAlarm)
IF #iError103Detected THEN
    // Step 1: drop enable
    #iPower.Enable := FALSE;
    #iPowerBusy   := #iPower.Busy;

    // Step 2: wait for axis to report Standstill (optional but recommended)
    IF #iAxisStatus = TO_Struct.StatusStandstill THEN
        // Step 3: issue a TO restart
        #iReset.Restart := TRUE;
        #iReset.Execute := TRUE;
    END_IF;

    IF #iReset.Done THEN
        // Step 4: clear the trigger and re-enable
        #iError103Detected := FALSE;
        #iReset.Execute    := FALSE;
        #iPower.Enable     := TRUE;
    END_IF;
END_IF;

5.2 Ladder logic implementation

// Network 1: detect TO alarm 103 from the technology object status
A   "TO_Axis_1".StatusWord.Error          // axis error flag
A   "AlarmHandler".Alarm103Active         // OR with technology alarm flag
=   #TO103

// Network 2: power-off the axis
A   #TO103
=   "MC_Power_1".Enable                   // FALSE on rising edge

// Network 3: wait for Standstill, then trigger TO restart
A   #TO103
A   "TO_Axis_1".StatusWord.Standstill
=   "MC_Reset_1".Execute
S   "MC_Reset_1".Restart                  // latched, cleared after Done

// Network 4: re-enable once restart is acknowledged
A   "MC_Reset_1".Done
R   "MC_Reset_1".Execute
R   "MC_Reset_1".Restart
S   "MC_Power_1".Enable                   // re-enable axis

5.3 Behaviour of MC_Reset with Restart

While the restart is in progress, do not toggle MC_Power.Enable or issue motion commands. Doing so re-arms the alarm path and can leave the axis in an undefined intermediate state.

6. Scaling the Fix to Multi-Axis Systems

On the 19-axis system that motivated this article, the practical implementation is a single routine that loops over an axis array rather than 19 hand-coded blocks:

// Iterate through all TOs registered in the axis array
FOR #i := 1 TO 19 DO
    // Detect alarm 103 on the current axis (read from StatusWord or Alarm handler)
    #bAlarm103 := AxisArray[#i].StatusWord.Alarm103;

    IF #bAlarm103 AND NOT AxisArray[#i].RestartInProgress THEN
        // Disable
        AxisArray[#i].MC_Power.Enable := FALSE;

        IF AxisArray[#i].StatusWord.Standstill THEN
            // Issue TO restart
            AxisArray[#i].MC_Reset.Execute := TRUE;
            AxisArray[#i].MC_Reset.Restart := TRUE;
            AxisArray[#i].RestartInProgress := TRUE;
        END_IF;
    END_IF;

    IF AxisArray[#i].MC_Reset.Done THEN
        AxisArray[#i].MC_Reset.Execute := FALSE;
        AxisArray[#i].MC_Reset.Restart := FALSE;
        AxisArray[#i].RestartInProgress := FALSE;
        AxisArray[#i].MC_Power.Enable := TRUE;
    END_IF;
END_FOR;

For installations that escalate TO restarts to the operator through HMI, expose the per-axis restart button as a separate confirmation dialog that lists which axes are about to be restarted, because a TO restart reinitialises the technology object and clears any latched homing status ("homed" flag is reset on power-down of the TO).

7. Verification

After the restart, confirm that:

1. TO_Axis_X.StatusWord.Error is FALSE on every affected axis.
2. The alarm number 103 has been removed from the PLC diagnostic buffer (online > diagnostic buffer, filter on technology alarms).
3. The commissioning window in TIA Portal no longer shows the alarm in red on the affected TO.
4. Each affected axis has been re-homed (active or passive) before resuming absolute moves.
5. A single test motion (for example MC_MoveJog in both directions at low speed) executes cleanly without the alarm reappearing.

If the alarm reappears within seconds of MC_Reset.Done = TRUE, the underlying configuration mismatch has not been resolved; jump to Section 9.

8. Preventive Measures

8.1 Lock down dynamic TO writes

If the application writes to TO data block parameters at runtime (for example, recipe-driven gear ratios or speed overrides), those writes must be followed by a controlled TO restart sequence. Uncoordinated runtime writes are the most common field cause of alarm 103.

8.2 Drive replacement procedure

Document a drive replacement procedure that, at minimum:

1. Powers down the machine section.
2. Replaces the drive.
3. Performs a full "Commissioning > Drive" wizard from TIA Portal so the new drive's parameters match the project.
4. Downloads the project and runs the TO restart on the affected axis.
5. Re-homes the axis.

8.3 PROFINET robustness

• Set the PROFINET watchdog on the drives high enough to ride through short topology reconfigurations (typical: 1000 ms for non-safety motion, longer if the segment uses IRT).
• Use ring redundancy (MRP) or PRP on the motion segment so a single cable break does not require I/O re-negotiation.
• Disable the "device substitution" mode on the drive ports unless explicitly required; substitution devices will not have the expected parameters and the TO will reject them with 103.

8.4 Avoid online edits of the mechanical configuration

Changing encoder gear ratio, position limits, or direction of rotation in TIA Portal online and downloading only the technology object is a classic trigger. Make these changes offline, then download the entire station (or at minimum the TO and the affected drive) and run a TO restart.

8.5 Audit MC_Reset calls

Search the project for every call of MC_Reset. Confirm that at least one call uses Restart := TRUE and that this call is reachable from the alarm handler that picks up technology alarm 103.

9. When the Restart Fails: Persistent Configuration Mismatch

If the MC_Reset with Restart = TRUE returns Error = TRUE or the alarm reappears within seconds, the cause is a genuine mismatch between project and drive. Walk through the following matrix:

10. Frequently Asked Questions