SINUMERIK 840D: Alternative to STOPRE for Continuous Path Motion

On a SINUMERIK 840D induction-hardening cell, the part program uses trigonometric and arithmetic calculations on R parameters to update the Z (depth) and B (rotary) axes every step. The programmer wants the tool path to remain continuous, but a STOPRE instruction inserted to make those R parameters valid visibly breaks the smooth motion. This reference explains what STOPRE actually does inside the 840D NCK preprocessing lookahead, why G64/G602 cannot mask the dwell it causes, and two production-proven replacements: the SYNRW GUD attribute and synchronized actions reading BTSS variables. Code, parameter tables, commissioning checks, and a fault-cause matrix are included.

1. Problem Description: STOPRE Forces a Dwell Between Blocks

The induction-hardening part program follows the classic profile of a multi-step contour on a turning or milling variant of the 840D:

• Blocks N605 through N625 compute R10, R11, R12 from part geometry, encoder feedback, and induction-coil coupling coefficients.
• The Z axis is commanded with G01 G90 Z=R10 in successive blocks.
• R10 is rewritten in every step by the trigonometric block.
• Continuous-path mode is enabled with G64 G602.

The motion runs correctly when the program includes STOPRE before the read of R10, but the axis is seen to brake and re-accelerate between segments. The block transition is no longer continuous. The programmer is asking: how do I keep the path continuous and still have my R-parameter-driven axis positions arrive on time?

2. Why STOPRE Behaves This Way: NCK Preprocessing Lookahead

To understand the cure you must understand what STOPRE actually does. The 840D NCK (Numerical Control Kernel) is a pipelined processor: while the interpolator is executing block N, the preprocessor is already decoding, calculating and reformatting blocks N+1 through N+K into a form the interpolator can consume. K is the size of the lookahead buffer (configurable via machine data; typical values are 60-150 blocks on 840D sl).

This two-stage architecture is the reason the controller can plan velocity across corners (look-ahead velocity limiting), handle contour transitions with G642 or G645 tolerance windows, and pre-allocate acceleration reserves. It is also the reason a parameter that is read by the interpolator in block N must already exist in the preprocessor's memory before block N can be decoded.

STOPRE (program command Stop preprocessing) instructs the NCK to:

1. Stop the preprocessor at the current block boundary.
2. Wait until the interpolator has executed the previously decoded blocks (i.e. the lookahead buffer is drained).
3. Allow the next block to be decoded only after the interpolator has actually reached the STOPRE location.
4. Resume the preprocessor once the block following STOPRE has been decoded.

That waiting is precisely the dwell the programmer is seeing. Even in G64 continuous-path mode, the lookahead buffer is empty at the STOPRE line, so the interpolator has no future block to plan velocity against. The velocity drops to zero (or to a low flush velocity on systems configured with MD32300 $MA_MAX_AX_ACCEL jerk limiting), and re-acceleration cannot start until the preprocessor refills the buffer.

3. Why G64 G602 Alone Does Not Solve the Problem

G64 is the continuous-path mode in which the NCK looks ahead, finds corner tolerances and applies optimum velocity at the join. G602 selects the corner behaviour at exact stop. Together they let the controller plan a velocity profile across many blocks - provided those blocks are already in the lookahead buffer.

Three configuration options govern what happens at a block join in 840D sl:

The mistake many programs make is to insert STOPRE to force a fresh read of R10 in G64 and expect the join to be smooth. It will not be. The STOPRE must be removed, and a different mechanism used to make R10 current.

4. Canonical Solution: SYNRW GUD Variable Attribute

The Siemens 840D programming manual (Programming Manual Job Planning, section 3.3 - Global User Data / GUD) defines a GUD variable attribute called SYNRW (synchronize on read and write). When a variable is declared with SYNRW, the NCK automatically inserts the equivalent of STOPRE at every read or write of that variable in the part program. The preprocessor therefore waits only at the syntactic moment the variable is touched, and the rest of the lookahead buffer survives.

Definition syntax (placed in a GUD definition file, normally in the NCK active file system):

or, more typically for a hardening machine, an array of real numbers sized to the calculation scratchpad:

You can extend the attribute to integer and boolean types:

DEF NCK INT SYNRW MY_I[50]
DEF NCK BOOL SYNRW MY_FLAG[16]

The mechanism works because the preprocessor is forced to defer decoding of any block that reads or writes MY_R[i] until the interpolator reaches that block. The rest of the lookahead (blocks that do not touch MY_R) continues to be pre-decoded in advance. The join between two G01 Z=R10 blocks now has a populated buffer, so G64 can plan a smooth velocity across the join.

4.1 How to Migrate an Existing R-Parameter Program to SYNRW GUD

1. Inventory every R parameter that the interpolator must read in continuous-path mode (typically R0-R99 plus any R500+ you use for subprograms).
2. Create a new GUD definition file _N_DEF_DIR/_N_MY_R_DEF with a single line per array: DEF NCK REAL SYNRW MY_R[200].
3. Replace R10 with MY_R[10] in the calculation blocks (N605-N625 in the source program) and the motion blocks.
4. Remove every STOPRE from the motion section. Keep STOPRE in any safety block that must be synchronous (e.g. spindle-orient-driven tool change).
5. Reload the GUD definitions and reinitialise NCK (or just reload via HMI: Start-up > GUD).
6. Dry-run the program in DRYRUN with the override at 1% and observe the path graphic for velocity dips at every MY_R read.

5. Second Solution: Synchronized Actions on BTSS Variables

For high-speed applications where the calculation must be done outside the part program (for example, when the PLC is providing the data, or when the calculation needs encoder feedback updated within one IPO cycle), the right tool is a synchronized action (also called synchro-action or technology cycle). The synchronized action runs at IPO rate (typically 2-4 ms on 840D sl) and can read a PLC-published BTSS variable and write it into a non-SYNRW NCK variable, or directly into a synchronized-action-local $AC_ system variable, without flushing the main-program lookahead.

The structure is:

Then the part program reads $AC_PARAM[10] (which is automatically current at IPO rate) instead of R10:

Advantages over SYNRW GUD:

• The synchronized action can run at full IPO rate, decoupling the calculation from the part-program preprocessor entirely.
• The motion section is left untouched; only the source of the position value changes.
• You can incorporate encoder feedback, temperature compensation or PLC-published coefficients without ever needing STOPRE.

Disadvantages:

• Synchronized actions are an advanced programming construct and must be designed in pairs (initialisation and steady-state) to avoid IDS=... WHENEVER being masked by modal conditions.
• Debug visibility is lower; the Diagnosis > Synchro Actions HMI page must be used to trace execution.
• Synchronized actions cannot perform arbitrary block-by-block math; they are expressions evaluated at IPO rate.

6. Choosing the Right Approach for an Induction Hardening Cell

For the part-program in question - the trigonometric calculation lives in the part program and is meant to be re-evaluated at every step - the SYNRW GUD pattern is the correct, lowest-risk fix. Synchronized actions are appropriate for the case where the encoder or PLC provides the position coefficient every IPO and the part program is just a feed-command consumer.

7. Sample Implementation on SINUMERIK 840D sl

The following example shows a hardened version of the source program (blocks N605-N625 + the motion section) using MY_R with the SYNRW attribute and a synchronized action publishing the encoder-corrected target to $AC_PARAM[10]. The motion section reads $AC_PARAM[10] so the part program never needs STOPRE.

; GUD file: _N_DEF_DIR/_N_HARDEN_DEF
; Published in startup so the attribute is active before the part program runs
DEF NCK REAL SYNRW MY_R[200]    ; scratch R-parameters with implicit synchronisation

; Synchronized action published in the same source as the part program header
; Reads encoder-coupling coefficient from PLC BTSS and applies it to MY_R[10]
IDS = 100 WHENEVER $AC_TIMER[1] >= 0 DO $AC_PARAM[10] = MY_R[10] * $AC_PARAM[2] + $AC_PARAM[3]

; Part program body
N600 G64 G602
N605 MY_R[1]  = MY_R[20] * COS(MY_R[21])
N610 MY_R[2]  = MY_R[20] * SIN(MY_R[21])
N615 MY_R[3]  = MY_R[22] / MY_R[23]
N620 MY_R[10] = MY_R[1] + MY_R[2] * MY_R[3]
N625 MY_R[11] = MY_R[10] - MY_R[24]
N630 G01 G90 Z=$AC_PARAM[10] F=MY_R[30]
N635 G01 G90 B=MY_R[11] F=MY_R[31]
N640 MY_R[20] = MY_R[20] + 1.0
N645 MY_R[21] = MY_R[21] + 0.05
N650 GOTO N605

Notice the deliberate use of $AC_PARAM[10] for the interpolator-visible position. The synchronized action pulls MY_R[10] through the per-IPO multiplier/offset in $AC_PARAM[2] and $AC_PARAM[3], giving the operator a real-time tuning knob (via BTSS write from the HMI) without ever interrupting the part program.

8. Verification and Commissioning Checks

1. Path graphic inspection. Run the program in DRYRUN at 1% rapid override. Open the HMI path graphic and zoom in on every block join. There should be no visible velocity dip between N630 and N635, or between successive iterations of N630 if you have rewritten the motion as a subprogram with REPEAT.
2. Block search / single block. Run in SBL1 or SBL2 single-block mode. Block search with calculation must still find the correct search target. If the search target is a block that reads MY_R[10], the SERUPRO mechanism (search run by program test) re-evaluates the calculation. This is one of the few situations where STOPRE is implicitly issued by the NCK. It is not user code and does not normally disturb continuous-path operation.
3. Triggered trace. Use the HMI Diagnosis > Trace function to record $AA_VACTM[Z] (actual axis velocity), $AC_PARAM[10] and the NCK signal /Nck/Function/Stopre (if exposed via BTSS) for the duration of one tooth-step. The trace should show a smooth velocity profile without a velocity step at the block boundary.
4. Acoustic / vibration check. Run the production program on the actual machine at 100% override. Listen for the characteristic "chirp" at every block transition; it must be gone. The gear-train vibration spectrum on an accelerometer at the spindle housing should show the gear-mesh fundamental and a clean tooth-passing harmonic, without the sub-harmonic that a stop-start profile would introduce.
5. Cycle time. Compare the part-program execution time before and after the change. Replacing STOPRE with SYNRW typically reduces the cycle time because the preprocessor no longer drains and refills the buffer at the transition.

9. Troubleshooting Matrix

10. Safety and Process Considerations

Removing STOPRE changes the temporal relationship between the NCK preprocessor and the interpolator. In an induction-hardening cell the process is sensitive to feed-rate stability and to the time-energy integral delivered to the surface. Before declaring the change production-ready:

• Verify the heating profile with a thermocouple or pyrometer instrumented part at the worst-case feed rate. The continuous-path variant should produce a uniform hardness pattern; the stop-start variant will show banding.
• Confirm the E-Stop path. STOPRE was not a safety function in the source program; replacing it with a SYNRW variable does not change the E-Stop response. The standard NCK E-Stop (via PLC interface DB10 DBX56.1 and the safety integrated drives) remains in force.
• Check the operator message for cycle time. The HMI will show a slightly different cycle time; the part count per shift needs to be re-benchmarked.
• Document the change in the part-program header. Future maintainers reading the program must know that MY_R variables are SYNRW; if they ever declare a non-SYNRW variable with the same name in a different scope (e.g. a local LUD with the same identifier) the preprocessor will silently use the non-synchronised copy and the dwell will reappear.

11. Summary

There is no drop-in replacement that produces no synchronisation cost at all - the NCK must see the new value of any variable the interpolator is about to use. The question is how much of the lookahead buffer you drain while doing it. STOPRE drains the entire buffer. The SYNRW GUD attribute drains only the single block that touches the variable. A synchronized action drains nothing in the part program and instead pushes the value through $AC_PARAM or $AC_ system variables on the IPO clock.

For a block-by-block re-evaluation of R parameters driving G01 motion in G64, declare the scratch array as DEF NCK REAL SYNRW MY_R[N], swap the R-parameter references in the calculation and motion blocks, and remove the STOPRE. Verify with the path graphic, an axis-velocity trace and an acoustic check. If the data source is an encoder or a PLC, push it through a synchronized action into $AC_PARAM and read $AC_PARAM from the part program. Both patterns are documented in the official Siemens programming manual and have been used in production cells for two decades.

FAQ