Customizing ShopTurn F_HOME: Safe Y-Axis Retract on SINUMERIK

Overview: F_HOME in SINUMERIK ShopTurn

The F_HOME cycle is the standard tool-change-point approach routine that the SINUMERIK ShopTurn machining-step programming environment calls before and after every turret indexing or tool change. Its purpose is to retract the active tool to a collision-free position so the turret can rotate without striking the workpiece, the chuck, the tailstock, or any fixture. On lathes equipped with a Y-axis (typically a milling-capable turning machine such as the Siemens ShopTurn 840D sl / ONE class), the standard F_HOME shipped from Siemens does not always force a Y-axis retract to machine zero, which can result in diagonal rapids that smash a micro-boring bar or a grooving insert into the part OD.

This reference describes the file architecture behind F_HOME, the labels that the cycle exposes, the system variables that drive tool-change behavior, and a field-proven pattern for forcing G0 SUPA Y0 D0 at every event point. It also documents the simulation checksum problem in F_HEAD and the machine data switches that can be used to bypass it.

Prerequisites and File Locations

Editing F_HOME requires access to the NC file system. On a SINUMERIK 840D sl / SINUMERIK ONE, the relevant directories are:

For details on the directory layout see the SINUMERIK 840D sl ShopTurn Operator's Guide. For the SinuTrain ShopTurn CL SW 2.6 SP1 HF1 offline training kit (article 6FC5870-6YC20-1YA0) the same paths apply under the installed image; see Siemens product support entry 6FC5870-6YC20-1YA0.

Required permissions: service password (Manufacturer level) or higher; read access via the HMI's Commissioning > NC files tree.

F_HOME.SPF Architecture and Label Semantics

The Siemens-delivered F_HOME is structured as a single SPF subroutine called by ShopTurn at well-defined event points. Each event enters the cycle at a numeric label of the form _Mxxx and returns via GOTOF _MEND. The seven events the integrator must handle are summarized below.

The ShopTurn cycle F_HOME is itself called from the high-level machining steps. The Siemens setup turning programming manual documents the call points: "In order to avoid collisions with the work piece the ShopTurn cycle F_HOME for the approach of the tool changing point is called up." (see A120 Setup Turning 04/05 EN). On modern controls F_HOME is generated automatically by the ShopTurn step "Approach tool change point".

CUST_TECHCYC.SPF: The Manufacturer Override Mechanism

Although the OEM F_HOME source is not exposed, machine builders (Emco, DMG-Mori, Index, Doosan/DN Solutions, Nakamura-Tome) ship a customization layer at /NC/CYCLES/MAKER/CUST_TECHCYC.SPF. This SPF runs before the user F_HOME in the call chain. It is the preferred integration point for machine-specific retraction logic, including the G0 SUPA Y0 D0 lines Siemens or the OEM inserts by default. The same labels (_M110 … _M117) are reused inside CUST_TECHCYC.SPF, so the integrator can place conditional retraction logic in either or both files.

Gotchas documented in field deployments:

1. The _M110 (after tool change) section executes after the turret has rotated. Any motion added there risks collision with a tool that is still in the part.
2. The _M111 / _M112 sections execute before the tool change. Pre-retract must be placed here, never in _M110.
3. Neither section runs at the start of a ShopTurn program even when a T0 is in the header. Homing logic must be added to the program-start hook (see the Homing Routine section below).
4. These callbacks are ShopTurn-only. Hand-written G-code and CAM-posted programs must call F_HOME explicitly or handle tool changes themselves.

System Variables for Tool Change Logic

The system variables consumed by F_HOME and CUST_TECHCYC.SPF are part of the SINUMERIK NC variable namespace. The most useful ones for Y-axis retract logic are:

Implementing Safe Y-Axis Retract

The pattern below is the field-validated CUST_TECHCYC.SPF body for a Y-axis lathe. It is written to be portable: ISAXIS(2) guards every motion so the file can be deployed unchanged to a non-Y machine (typical Emco ConceptTurn 105 with the Y-axis option removed).

;_M110: ; After tool change cycle (with tool change)
IF($P_TOOL>0)
  _I=$P_AD[1]
ENDIF
IF(_I<>731) AND (_I<>732) ; not Par quill or Steady rest
  IF ISAXIS(2)
    G0 SUPA Y0 D0 ; retract Y to machine zero
  ENDIF
ENDIF
GOTOF _MEND

;_M111: ; Tool change in the cycle
IF ISAXIS(2)
  G0 SUPA Y0 D0
ENDIF
GOTOF _MEND

;_M112: ; Before tool change at release plane
IF(_E_ST_PRG)
  IF($P_TOOL>0)
    _I=$P_AD[1]
  ENDIF
  IF(_I<>731) AND (_I<>732)
    N1110 F_HOME ; built-in retract
  ENDIF
ENDIF
M09
GOTOF _MEND

;_M113: ; Before cutting edge change
IF(_E_ST_PRG)
  IF($P_TOOL>0)
    _I=$P_AD[1]
  ENDIF
  IF(_I<>731) AND (_I<>732)
    N1130 F_HOME
  ENDIF
ENDIF
GOTOF _MEND

;_M114: ; After tool change cycle (no tool change)
IF ISAXIS(2)
  G0 Y0 ; part-coordinate Y0
ENDIF
GOTOF _MEND

;_M116: ; At tool change point
IF ISAXIS(2)
  G0 SUPA Y0 D0
ENDIF
GOTOF _MEND

Key design points:

• SUPA forces the move in machine coordinates. Combined with D0 it also clears the tool-length offset so the move is repeatable regardless of the active tool.
• Par quills (tool type 731) and steady rests (732) must be skipped — their geometry does not allow a Y0 retract.
• The split between _M110 (after) and _M111 (before) prevents the diagonal rapid that causes broken boring bars when the next operation begins inside a pre-drilled hole.

PLC vs NC Tool Change (M6 vs T[n])

On a SINUMERIK ShopTurn lathe, the actual turret indexing is driven by the machine builder's PLC program (typically the S7-300/1500 logic in the MCP / NCU-PLC), not by NC. The NC-side M6 command is a trigger that calls CUST_M6.SPF, which in turn signals the PLC. A bare T<n> in NC code can also index the turret on machines where the PLC is configured for "T-prepare + T-rotate" mode.

Because the physical tool-change keypress routes directly to the PLC, the Y0 retract will not run when the operator cycles through tools from the keyboard. The only complete fixes are either (a) editing the PLC to invoke F_HOME before issuing the turret-rotate command to the NCK, or (b) replacing the MCP-button handler with an NC procedure that issues G0 SUPA Y0 D0 ; T<n> M6. Refer to the Tool Management chapter of the SINUMERIK Operate Programming Manual for the PLC interface signals involved (e.g. DB72.* on classic 840D, DB990x on ONE).

Program Simulation: F_HEAD Checksum and Bypasses

ShopTurn refuses to execute a program that has not been simulated. The "has been simulated" flag is stored as the first integer argument in the F_HEAD preamble that ShopTurn writes to the top of every *.MPF:

F_HEAD(1455947775,12,0.3,,150,5,5,3.8,0,180.71417,282.77133,1,R150,R151,71,1,35535,,70,0,20,6,6,100,100,100,1,164.8,,8650751,16079,2,0,6,200,0,,-100,-80,6,100,100,100,10,10,0,0,0,200,50,720);*RO*

The first numeric token is a 32-bit hash of the program parameters (XRA, XRI, ZRA, tooling list, etc.). It is regenerated by the simulator on every successful run. Editing the program invalidates the hash, and the control prompts the user to re-simulate. This is a safety feature, but it is a productivity barrier for shops that program in a "macro-of-macros" style and call subprograms in many different Z-zero and mirror contexts.

Bypass Options

1. Manual hash patch. Locate a previously simulated program with the same retract-relevant parameters (XRA, XRI, ZRA) and copy its first integer token. Risky if the parameters drift, and is not auditable.
2. Disable program test via MD. Set MD51039 $MM_PROGRAM_TEST_MODE to 0. This disables the dry-run mode, but does not necessarily clear the F_HEAD hash check on ShopTurn programs — test on a simulated machine first.
3. Conditional mirroring in the part program. Use $P_ISTEST to skip the G55 mirror on the first-pass simulation run, then let the real production run mirror correctly:

; Program header
IF($P_ISTEST) GOTOF SKIP_MIRROR
MIRROR Y0 ; G55 subspindle mirroring
SKIP_MIRROR:
;(rest of operations)

This is the most defensible workaround: the simulation path stays straight, the production path is mirrored, and no F_HEAD manipulation is required.

Subspindle Mirroring Strategy (G54 main / G55 subspindle)

On a counter-spindle lathe the part is transferred to the subspindle, picked up, and machined on the G55 frame with Y mirrored. The pattern below is the recommended subroutine structure when one physical macro is invoked in both G54 and G55 contexts:

; Master program
G54 ; main spindle frame
F_HOME ; retract
CALL "ROUGH_OUT" ; macro, G54 context
CALL "TRANSFER"  ; bar-feed + G55 mirror
G55 ; subspindle frame
IF($P_ISTEST) GOTOF SKIP_MIRROR
MIRROR Y0 ; live production: Y mirrored on G55
SKIP_MIRROR:
CALL "FINISH_OUT" ; same physical macro, interpreted in G55

The control's tool-direction check (right-hand rule) is satisfied on the first-pass simulation of the master program because the transfer macro sets the mirror state inside the simulation. The individual subprograms still fail in isolation — accept that, and call them only through the master.

Verification and Field Commissioning

After deploying a modified F_HOME or CUST_TECHCYC.SPF, perform this sequence in dry-run mode before any production cut:

1. Power-cycle or NCK reset to ensure the new SPF is loaded into the active file system.
2. Run a known-good ShopTurn program in Program Test with the doors open and the turret under observation.
3. Step through T1 M6 and T2 M6 manually; confirm Y0 in the position display and that $P_SETFR is unchanged.
4. Trigger a tool change from the MCP button. If Y0 retract does not run, the PLC path is not integrated and a separate MCP patch is required (see previous section).
5. Inspect the NC/PLC trace for DB72.DBX0.6 (command "Tool change") to confirm the NC-to-PLC hand-off is clean.
6. Run a full simulation of the master program. The first integer in F_HEAD should be regenerated; record it for archival.

Acceptance criteria: zero Y-axis diagonal rapids in the trace, all M6 events show SUPA Y0 D0 in the block log, and no alarm 21612 "Channel %1 axis %2 contour deviation".

Troubleshooting Matrix

FAQ