Troubleshooting Siemens 840D Error 17200 in TDI Ident Tool Delete

Problem Overview

On SINUMERIK 840D / 840D sl controls with active tool management and TDI Ident Connection sl active, operators commissioning gantry mills or similar dual-gripper magazines commonly encounter alarm 17200 "Tool data cannot be deleted" when an automated unload cycle tries to remove a tool that has just been transferred from the spindle to a buffer location.

The symptom pattern is consistent and reproducible:

• The same DELT("T<no>",<duplo>) sequence works from MDI/MDA when the cycle is preceded by M30 or M02.
• The same sequence inside an active part program returns alarm 17200.
• Setting DB19.DBX196.3 = 1 (request: delete tool) from a cyclic M code produces the same alarm when invoked from inside a running NC program, but works from MDI.
• Writing the tool data to the RFID code carrier via DB126 succeeds; only the subsequent deletion fails.

The root cause is not corrupted tool data, not an RFID handshake fault, and not a magazine geometry error. It is a tool selection condition in the NCK that persists even after the tool has been physically moved out of the spindle location.

Root Cause Analysis

Tool management in the 840D NCK maintains a current tool reference that is independent of the magazine slot occupancy. The reference is set by the last programmed T<no> selection and is only cleared when:

1. A new T selection is executed (with or without M06), or
2. An M30 or M02 resets the program context, or
3. An explicit deselection is performed via the PLC/NCK interface.

When a cycle calls MVTOOL(state,9998,1,9998,4) to relocate the tool from the spindle (location type 1, location 9998, index 1) to the buffer (location type 1, location 9998, index 4), the NCK updates magazine occupancy but leaves the active tool pointer pointing at the relocated tool. From the tool list's perspective, the tool is still "in use" by the spindle, even though the spindle is now empty.

The DELT service (_N_TMDELT) and the equivalent FC8 task with TaskIdent = 5 (delete tool) both refuse to remove a tool that is referenced as the active D-number source. The NCK returns alarm 17200 with the supplemental text "tool data cannot be deleted." M30/M02 succeed because the program reset clears the active tool pointer as a side effect, which is why DELT runs without complaint immediately after the reset in MDI mode.

Affected System Configuration

Magazine Location Reference

Diagnostic Procedure

1. Trigger the failing cycle manually from MDI and observe the alarm line. Confirm the alarm number is 17200 and the supplementary text begins with "tool data cannot be deleted."
2. Open the HMI diagnostics: Commissioning > NC > Tool Management > Tool List. Inspect the state column for the tool you attempted to delete. A tool flagged with active D-number compensation or active spindle reference will not be deletable.
3. Read the PLC status from the basic program:
   DB71.DBX<tool_no_offset>.0 - tool exists
   DB71.DBX<tool_no_offset>.1 - tool disabled
   DB71.DBX<tool_no_offset>.2 - tool measured
   DB71.DBX<tool_no_offset>.3 - tool released (in active state)
   If bit 3 is set after MVTOOL has moved the tool out of the spindle, the active tool pointer has not been cleared.
4. Insert a temporary write before the failing DELT:
   STOPRE
R100 = $AC_TOOLNO (current tool number)
   R101 = $AC_DNUM (active D number)
   Compare R100 with the tool number you intend to delete. Equal values confirm the tool is still the active tool.
5. Test the cycle termination theory: replace the cycle's terminating M17 with M30 and re-run. If DELT then succeeds, the cause is confirmed as residual active tool selection.

Solution Methods

Three field-proven remedies exist. Each clears the active tool reference so that DELT, FC8 TaskIdent=5, or DB19.DBX196.3 can complete without alarm 17200.

Method 1: T0 / Dummy Deselection in Cycle (Recommended)

Program a synchronous deselection by calling an unused or dummy tool before the delete:

; --- unload cycle ---
MVTOOL(2,9998,1,9998,4)    ; move from spindle to pot
M221                        ; write RFID via DB126
; --- force deselection ---
T0 M06                       ; or T"DUMMY" M06 if a placeholder tool exists
DELT("T<tool_no>",<duplo>)
M17                          ; safe to use M17 now

If your standard M06 would invoke a full tool change macro and re-introduce a tool into the spindle, use a second M function reserved for "effective tool change" (for example M206) that the PLC interprets as a no-op except for clearing the NCK active-tool pointer. Configure the M-code in machine data $MN_M_NO_FCT_E and link it in the basic PLC to a stub that returns immediately.

Method 2: Asynchronous Transfer via FC8 TaskIdent=4

FC8 (TM_TRANS) supports asynchronous relocation of the old tool to a destination defined by the last prepare-change command. This is the cleanest PLC-side remedy when you cannot modify the NC cycle:

After the FC8 call completes (poll the Status word or the corresponding ready bit in DB71), the active tool pointer has been updated and DELT can run in the next NC block.

Method 3: Program Reset via M02 / M30 Wrapper

When modifying the cycle is not possible, run DELT in a separate MDI-equivalent context by issuing a nested subprogram that terminates with M30 instead of M17:

; in main cycle
MVTOOL(2,9998,1,9998,4)
M221
CALL _DELT_WRAP
; back in main cycle, but state is preserved only if wrapper
; does not perform actual reset

This approach is fragile. The NCK will reset modal settings, G codes, and tool offsets on M30, which typically corrupts the calling program's context. Prefer Method 1 or Method 2.

PLC-NCK Interface Reference

Delete Tool Request Path

FC8 (TM_TRANS) TaskIdent Catalog

Cycle Programming Patterns

Safe Unload-and-Delete Pattern (840D sl)

DEF INT _TOOL_NO, _DUPLO
DEF INT _ACTIVE_T, _ACTIVE_D

; --- read current tool ---
_STOPRE
_ACTIVE_T = $AC_TOOLNO
_ACTIVE_D = $AC_DNUM

; --- move to buffer ---
MVTOOL(2, 9998, 1, 9998, 4)

; --- write RFID via M221 (PLC sets DB126 and pulses ready) ---
M221

; --- explicit deselection: command T0 and clear offsets ---
T0
M206                            ; custom "effective no-op change"
D0

; --- delete from tool list ---
DELT("T" <<_TOOL_NO>>, _DUPLO)

M17

Variant: PLC-Driven Asynchronous Reload

For very large magazines where cycle execution time matters, the PLC can drive the deletion entirely asynchronously:

1. Cycle sets a marker in the user interface DB (e.g. DB900.DBX10.0 = 1) and continues without DELT.
2. PLC FC8 call with TaskIdent=4 runs in the background, moving old tool to a defined location.
3. PLC polls DB71 for completion, then issues TaskIdent=5 to delete.
4. PLC clears the marker and updates HMI tool list display.

This pattern decouples cycle execution from tool-list housekeeping and avoids tying the part program to ALC handshake timing.

Verification Steps

1. Run the corrected cycle from MDI with the original part program loaded in the background. Confirm DELT returns without alarm 17200.
2. Run the cycle from inside a part program that performs a previous tool change to a real tool. Verify the unload tool is removed from the tool list while the previously active tool remains correct.
3. Check HMI tool list: the unloaded tool entry should disappear; D-numbers of remaining tools should be intact.
4. Read $AC_TOOLNO and $AC_DNUM immediately after the cycle: both should reflect the new state (typically T0 / D0).
5. Trigger a code-carrier read on a known tool to verify DB126 integrity was preserved.
6. Stress test: run the cycle 50 consecutive times. Watch for memory or magazine-inconsistency alarms (14000-14999 series) that could indicate a hidden race between FC8 and the cycle.

Edge Cases and Field Notes

• Multi-spindle configurations: The active-tool pointer is per-channel. If your cycle runs in a non-active channel of a multi-channel system, ensure the delete is targeted at that channel's tool list, not the global one.
• Adaptive control with $AC_ADAPT: If adaptive feed tables are enabled and reference the tool's geometry, DELT will still be blocked until those tables are flushed. Issue STOPRE before DELT to settle the interpolator.
• Persistent tool data ("P" status): Tools marked as persistent in the tool list (bit in DB71) cannot be deleted by standard DELT regardless of selection state. Clear the persistent bit in PLC before issuing delete.
• Code-carrier verification: The Function Manual MCIS TDI Ident Connection sl mandates that 840D sl tool management must be installed and configured before TDI Ident Connection sl setup is allowed. If you bypassed the wizard and set up code carriers manually, DB126 may not be properly linked, which can mask the selection issue behind write faults.
• M02 vs M30 in part programs: Some post-processors emit M30, others M02. The deselection effect is identical at the NCK level; both clear $AC_TOOLNO and $AC_DNUM. However, M30 also signals to the PLC that the program has finished and can be used to reset job counters in the HMI.
• Re-entry protection: If the unload cycle is called twice in quick succession (e.g. operator double-press), the second call will see the tool already in the pot but still selected. Insert a guard at the start of the cycle:
  IF $AC_TOOLNO == 0 GOTOF _END

Troubleshooting Matrix

Commissioning Checklist

• Confirm tool management is licensed and enabled in $MN_MM_TO_MANAGEMENT, $MN_MM_NUM_TO_MAG, $MN_MM_NUM_LOCS.
• Confirm TDI Ident Connection sl option is active and DB126 is generated by the setup wizard.
• Map location types: spindle = 9998/1, buffer pot = 9998/4 (or per active configuration).
• Define M206 as "effective no-op tool change" in $MN_M_NO_FCT_E and wire it in the basic PLC.
• Place D0 reset before DELT in any cycle that touches the spindle.
• Insert STOPRE before any DELT to flush the look-ahead.
• Add re-entry guard using $AC_TOOLNO == 0.
• Log $AC_TOOLNO and $AC_DNUM at cycle start and end for traceability.
• Run a stress test of 50+ cycles to confirm race-free behaviour with FC8 background tasks.