Resolving Siemens S7-1500T 16#800F Technology Object Locked Error

Resolving Siemens S7-1500T 16#800F Technology Object Locked Error

The error code 16#800F is a Motion Control fault raised by every S7-1500 and S7-1500T technology object that supports the Motion Control instruction set. The fault is generated when a motion job is dispatched to a technology object (TO) that is currently in a state in which the TO refuses to accept new commands. The visible symptom is a drive stopping for no apparent reason, and a 16#800F error returned from the issuing MC instruction. On SIMATIC ET 200SP CPU 1515SP PC T and SINAMICS S210 PN systems running tension-control applications that use the LAxisCtrl_SpeedAxis library block, this fault can appear 5–6 times per day if the application logic does not correctly manage the technology-object enable and the implicit stop commands.

1. Affected Hardware, Firmware, and Library Versions

The fault has been documented in all current TIA Portal versions from V15 up to V21. The official list is published in several equivalent forms:

• SIMATIC S7-1500 / S7-1500T Motion Control V4.0 in TIA Portal V15
• TIA Portal V20 documentation – Error IDs 16#0000 – 16#800F
• TIA Portal V21 documentation – Error IDs 16#0000 – 16#800F
• SIMATIC AX manual – Error IDs 16#0000 – 16#800F

The reference installation that surfaced the problem in the field is:

Although the firmware versions are S7-1500T-specific, the error string itself is identical for plain S7-1500 Motion Control. The 16#800F table is published unchanged across TIA Portal V15, V17, V18, V20, and V21, which means the same diagnostic procedure applies to all current projects.

2. Root Cause: Why the Technology Object Is Locked

Every motion job that is dispatched to a TO is processed by a state machine inside the Motion Control runtime. The job is rejected with 16#800F if the TO is currently in a state that disallows the job. The Siemens Motion Control documentation identifies exactly two conditions that produce the locked state for the MC_MoveVelocity instruction:

1. The technology object has no enable. The bit <TO>.StatusWord.X0 (Enable) = FALSE because MC_Power.Enable = FALSE or because the enable was withdrawn by an internal error-clear sequence.
2. A motion-stop job is currently active. The bit <TO>.StatusWord2.X0 (StopCommand) = TRUE because an MC_Stop with Execute = TRUE is in progress, or because the runtime has internally generated an equivalent stop.

The Siemens response to the original service request states it explicitly:

"The job cannot be executed because the technology object is locked. Enable the technology object with MC_Power.Enable = TRUE. Restart the job. A MC_Stop job is active with Execute = TRUE. Reset the job with the parameter Execute = FALSE."

Translated into engineering terms, the TO is "locked" for one of these reasons:

3. Reading the Technology Object Status Words

Before issuing any motion instruction, the application must read the TO status. The two relevant status words and their bits are documented in the S7-1500/S7-1500T Motion Control Function Manual and the Diagnostics Manual Diagnostics (S7-1500, S7-1500T) – Siemens Support entry 109781849:

Programmatically, check the TO state in the OB1 cycle or – better – in the application cycle that issues the next MC_MoveVelocity:

// Read TO state
bEnable := TO_SpeedAxis.StatusWord.X0;
bStopActive := TO_SpeedAxis.StatusWord2.X0;

// Guard: only issue new motion when enabled and no stop is pending
IF bEnable AND NOT bStopActive THEN
    // MC_MoveVelocity.Execute may now be raised
END_IF;

If the application triggers MC_MoveVelocity while either guard is FALSE, the runtime rejects the job with 16#800F and the drive coasts to zero (or decelerates with the configured emergency-stop ramp).

4. Diagnostic Procedure for a Recurring 16#800F

The field case described in the source is a foil-solver axis with velocity changes 5–6 times a day. Use the following procedure to identify whether the lock is caused by an external MC_Stop or by an internal library fault.

4.1 Capture the TO Snapshot

1. Open the TIA Portal project and go online with the CPU 1515SP PC T.
2. Open Project tree > Technology objects > TO_SpeedAxis > Commissioning > Diagnostics.
3. Watch StatusWord, StatusWord2, ErrorWord, and ErrorDetailNumber in real time. Add a watch table with the four tags and a 100 ms trigger to capture a history.
4. Open the alarm window (Online > Diagnostics > Alarms). The Motion Control runtime raises a corresponding alarm "Technology object locked" each time the fault is generated. Note the time stamp.

4.2 Correlate with the LAxisCtrl Library

The LAxisCtrl_SpeedAxis block is a Siemens Application Example function block for dancer/tension control. The block is not a single MC instruction; it wraps several MC instructions (MC_Power, MC_MoveVelocity, MC_Stop, MC_Halt, MC_Reset) and dispatches them based on operating modes. The block publishes an internal fault output that surfaces LAxisCtrl-specific error numbers from the following table (excerpt from the LAxisCtrl documentation, Table 2-14):

The presence of 16#8604 (or 16#8605) on the LAxisCtrl output, combined with 16#800F on the MC instruction return code, indicates that the library itself called MC_Halt (or MC_MoveVelocity) at the moment the TO was not enabled or another stop was already active. The root cause is therefore not the MC runtime but the application sequence that fires the library block.

4.3 Read ErrorDetailNumber

The TO publishes a 16-bit ErrorDetailNumber. The value is 0 when the runtime has not generated a deeper code. If ErrorDetailNumber is non-zero, the user manual in the project (right-click TO > Help on ErrorDetailNumber) provides a numerical description. Typical values seen on TO_SpeedAxis in this context are:

In the field case the engineer reports ErrorDetailNumber = 0, which is a strong signal that the runtime has no internal fault and the lock is being produced by the application or the library.

5. Common Locking Triggers in Web-Tension Applications

A web-tension or dancer control loop updates the velocity setpoint every cycle and passes the value to MC_MoveVelocity with VelocityChangeOnTheFly = TRUE. The configuration in the source uses LAxisCtrl_SpeedAxis for this purpose. The following conditions regularly cause 16#800F in such applications:

5.1 Implicit MC_Stop from the Library on Internal Fault

The library issues MC_Stop internally when an internal fault is detected, and the Stop instruction remains in the Busy state until the deceleration ramp has elapsed. Any new MC_MoveVelocity call arriving during that window receives 16#800F because StatusWord2.X0 is still TRUE.

5.2 Drive-Side Fault Cleared by PROFINET Re-Sync

The S210 PN can briefly clear the enable during PROFINET re-synchronization after a controller-supervisor warning (for example, a jitter spike or a port flap). MC_Power.Enable stays TRUE on the PLC, but the actual hardware enable on the drive is lost. The next MC_MoveVelocity is rejected because the TO has dropped its StatusWord.X0. The fix is to issue MC_Reset and to re-issue MC_Power from the application.

5.3 MC_Halt from a Higher-Level State Machine

The line PLC may be running a master axis with a MC_Halt at line-stop. Because the foil-solver axis is a follower, the library translates the master halt into a follower MC_Halt. During the deceleration window, the library also tries to push a velocity update, and the MC_MoveVelocity call returns 16#800F because StatusWord2.X0 = TRUE.

5.4 Rapid MC_Power Toggle on Process Alarms

If the application toggles MC_Power.Enable from a process alarm (for example, an emergency-stop signal) and then clears it within the same cycle, the TO is briefly locked while it transitions back to the Standstill state. The library's MC_MoveVelocity call lands during this window.

5.5 Library Block Called Twice in the Same Cycle

The LAxisCtrl_SpeedAxis FB must be called exactly once per cycle. If it is called in OB1 and again in a cyclic interrupt (for example, OB35) without exclusive instance handling, the second call may dispatch MC_Stop while the first call has not yet finished dispatching MC_MoveVelocity. The runtime serializes motion jobs and the second job is rejected with 16#800F.

6. Resolution: Step-by-Step Procedure

1. Confirm the source of the lock. Capture StatusWord.X0, StatusWord2.X0, the LAxisCtrl error output, and the S210 drive alarm buffer at the exact OB1 cycle in which the fault occurs. The capture is most reliable when implemented as a circular trace on a 100 ms interrupt with at least 4 s of history.
2. Guard the MC_MoveVelocity trigger. In the application logic that calls LAxisCtrl_SpeedAxis (or directly MC_MoveVelocity), add a precondition:

   IF TO_SpeedAxis.StatusWord.X0
      AND NOT TO_SpeedAxis.StatusWord2.X0
      AND TO_SpeedAxis.ErrorWord = 0
   THEN
       LAxisCtrl_SpeedAxis(bExecute := TRUE);
   END_IF;

3. Reset and re-enable after a 16#800F. The Siemens documentation explicitly prescribes: "Enable the technology object with MC_Power.Enable = TRUE. Restart the job." The cleanest implementation is:

   // Latch the error
   bErrorLatched := bErrorLatched
                 OR (MC_MoveVelocity.Error AND MC_MoveVelocity.ErrorID = 16#800F);
   
   // Auto-reset on falling edge of the trigger
   IF bErrorLatched AND TO_SpeedAxis.ErrorWord = 0 THEN
       MC_Reset.Execute := TRUE;
   ELSE
       MC_Reset.Execute := FALSE;
   END_IF;
   
   // Re-enable if the runtime dropped it
   IF MC_Reset.Done AND NOT TO_SpeedAxis.StatusWord.X0 THEN
       MC_Power.Enable := TRUE;
   END_IF;
   
   // Re-issue the velocity job
   IF bErrorLatched AND MC_Reset.Done AND TO_SpeedAxis.StatusWord.X0 THEN
       MC_MoveVelocity.Execute := TRUE;
       bErrorLatched := FALSE;
   END_IF;

4. Cancel a stuck MC_Stop. If a stray MC_Stop keeps the TO locked, the documentation specifies: "Reset the job with the parameter Execute = FALSE." Drive MC_Stop.Execute := FALSE in the same cycle that detects StatusWord2.X0 = TRUE for more than, for example, 200 ms without a drive-side alarm.
5. Remove double-invocations of the library. If the FB is used in two OBs, move it to a single OB (OB1 or a cyclic interrupt such as OB35) and remove the duplicate call.
6. Validate the drive-to-PLC round-trip. Open the S210 web server (https://<S210-IP>/) and check Diagnostics > Telegram Diagnostics. PROFINET cycle jitter greater than 50 % of the configured send clock is a common cause of intermittent enable dropouts on the S210 FW 5.2.
7. Re-test the web-tension loop. Run the line for at least 24 h with the trace recording enabled. The number of 16#800F events should fall to zero.

7. Verification: How to Confirm the Fault Is Gone

Three checks confirm that the 16#800F is resolved.

7.1 Status-Word Check

Insert a continuous monitor block that asserts StatusWord.X0 = TRUE and StatusWord2.X0 = FALSE immediately before every MC_MoveVelocity.Execute. If the assertion is ever FALSE, the system raises a marker that names which precondition was violated. The marker is the field-proven way to differentiate between the five triggers listed in Section 5.

7.2 Library Error Counter

Add a counter that increments on LAxisCtrl.fb_LAxisCtrl.error = TRUE. With the resolution applied, the counter remains at zero for at least 5 production days.

7.3 Drive-Side Alarm Buffer

Read the S210 parameter r0945[0..63] (fault buffer) and r2122[0..63] (alarm buffer) through the standard telegram or the web server. The presence of F30002, F30003, F31117, or F08501 indicates that the drive itself has dropped the enable and that the PLC-side reset sequence is masking the underlying problem. In that case the root cause is on the S210 side, not on the application.

8. Preventive Design Recommendations

To prevent 16#800F from re-appearing after the first fix, apply the following design rules to any TIA Portal V18+ project that uses LAxisCtrl_SpeedAxis on a S7-1500T with an S210 PN drive.

9. Frequently Asked Questions