Sinumerik 840D SL UGUD Variable Update Delay: STOPRE and SYN Fix

Problem: UGUD Variable Change Is Not Seen for Many Blocks

On a Sinumerik 840D SL, a user-defined global variable declared in UGUD.DEF is read correctly when the part program first runs. The problem appears when the operator modifies that variable from the HMI (Sinumerik Operate) while the part program is executing: the new value is not picked up by the next block. In the reported case, the control kept using the old value for approximately 14 look-ahead blocks before the modified GUD took effect. The same symptom is observed with R variables and with any GUD used inside motion blocks (G1, G0, G2, G3) or as a feedrate/spindle value.

This is not a bug. It is the documented behavior of the part-program preprocessor and it is solved with two complementary mechanisms: the STOPRE command and the synchronization qualifiers SYNW, SYNR, SYNWR.

Root Cause: Block Look-Ahead and Preprocessing

The 840D SL NCK preprocesses part-program blocks ahead of the interpolator to compute velocity profiles, look-ahead contouring, jerk limiting, and block transition behavior. The number of preprocessed blocks is bounded by machine data and is typically large enough that the interpreter is tens of blocks ahead of the IPO. The preprocessor captures variable values at the moment it reads the block. If the operator changes a GUD after the interpreter has already read the block, that block is executed with the old value.

The relevant machine data controlling the IPO look-ahead size includes:

• MD28070 $MC_NUM_BLOCKS_PREP_STOP – maximum number of blocks that the interpreter may preprocess ahead of the IPO.
• MD11450 $MN_SEARCH_RUN_MODE – search-run behavior, which uses the same preprocessing buffer.
• MD20150 $MC_GCODE_RESET_VALUES – G-code reset defaults that determine how block preprocessing re-initializes modal state.

Reducing MD28070 reduces the maximum look-ahead but also reduces contouring performance. The proper fix is to tell the control when a synchronization point is required, not to shrink the buffer.

Solution 1: STOPRE Command (Stop Preprocessing)

STOPRE instructs the NCK to stop preprocessing, wait until the currently preprocessed blocks have been executed by the IPO, and then continue. After STOPRE, the next read of a GUD, R parameter, or system variable returns the current value, including any change made from the HMI.

Use STOPRE immediately before the block that consumes the variable you intend to modify from the operator panel:

N10 STOPRE
N20 TVar = 1000
N30 G1 X200 F=TVar
N40 ...
N50 STOPRE       ; ensures next read of TVar picks up HMI change
N60 G1 X400 F=TVar

For inline use with modal motion, insert STOPRE in its own block. It is treated as a non-modal preprocessor-stop and does not affect modal state.

Solution 2: SYN Qualifiers in the Variable Definition

The synchronization attribute of a GUD is set at declaration time in UGUD.DEF, GUD.DEF, SGUD.DEF, or MGUD.DEF. The qualifiers SYNW, SYNR, and SYNWR cause the preprocessor to emit an implicit STOPRE at the synchronization point, so the developer does not have to insert STOPRE manually at every call site.

For the operator-panel case in the source, the correct declaration is:

This stops preprocessing on every read of TVar, so the part program always uses the most recent value written by the HMI.

How UGUD.DEF Is Structured

The four GUD definition files are loaded in a fixed scope order:

1. SGUD.DEF – Siemens system GUDs (read-only, do not modify).
2. MGUD.DEF – machine manufacturer GUDs (defined by the OEM).
3. UGUD.DEF – end-user GUDs (the file the end customer edits).
4. GUD.DEF – reserved for additional user definitions.

Scope specifiers used in DEF:

Combined with the SYN qualifier and the data type (REAL, INT, BOOL, STRING, FRAME, AXIS), the full declaration syntax is:

Example for a feedrate override written by the HMI and read by the part program:

Example for a tool-offset scratch value written by the part program and shown on the HMI:

REDEF: Modifying an Existing Variable

REDEF changes the access attributes of an already-declared GUD without rewriting the original definition. It is typically used in MGUD.DEF to expose an SGUD variable to the HMI or to add a synchronization attribute.

The keywords mean:

• APR nn – access level for read (PI service / HMI). 0 = no password, 7 = highest (Siemens service).
• APW nn – access level for write.
• SB – system-global (NCK scope).
• SD – system-global with default value.
• SR – static, retain across reset.

The combination of DEF (declaration) and REDEF (attribute override) lets the end user in UGUD.DEF set the synchronization and type, while the OEM in MGUD.DEF tightens access rights. This is the intended division of responsibility.

Step-by-Step: Implementing Immediate Variable Updates from the HMI

1. Open the active UGUD.DEF in the file system (path /_N_DEF_DIR/_N_UGUD_DEF) using Sinumerik Operate or the commissioning tools.
2. Add or modify the variable declaration with the appropriate SYN qualifier. For HMI-driven changes read by the part program: DEF CHAN SYNR REAL TVar.
3. Save the file and execute a warm restart (NCK Reset via pi services or HMI) so the new attributes are loaded.
4. Remove any redundant STOPRE statements in the part program if the SYN qualifier already covers the access. Keep STOPRE for ad-hoc cases where the qualifier was forgotten.
5. From the HMI, navigate to Parameters > User Data, change the value, and confirm.
6. Run the part program in single-block and AUTO modes. Confirm that the new value is read on the next block after the change.

Operator Panel Considerations

When the value is changed from the HMI, the new value is written into the same NCK variable memory that the interpreter reads. The interpreter still has blocks preprocessed, and the SYN/STOPRE mechanism is what guarantees that the next read returns the new value. The HMI side also uses a separate display buffer that is refreshed by the HMI software; the operator must not assume the new value is active in the part program until the next block after the synchronization point runs.

For a feedrate written from the operator panel while a G1 move is in progress, the practical rule is:

• If the feedrate source is a GUD/R variable read in the block (F=TVar), the SYN/STOPRE rule applies and a synchronization point is required.
• If the feedrate is controlled by the rapid-traverse/feed-rate override switch, the override is applied at the IPO level and takes effect within one IPO cycle (typically 2-4 ms), without needing STOPRE.

Verification and Commissioning Checks

To confirm the fix is correct, run the following checks:

1. Insert a write of TVar to a known value (e.g., TVar = 1500) inside the part program, then a STOPRE, then a block that reads it (e.g., R100 = TVar). Inspect R100 in the HMI; it must be 1500.
2. From the HMI, change TVar to 1200 while the program is paused at a block that uses it. Single-block advance one block. The next read of TVar must show 1200.
3. Test the same flow without STOPRE or the SYN qualifier. Confirm the original symptom (multiple blocks of stale value) reappears. This proves the synchronization is the cause and the fix.
4. Measure contour accuracy with STOPRE removed and a continuous motion of 50+ blocks. Reducing MD28070 as an alternative will degrade path velocity and is not recommended.

Troubleshooting Matrix

Performance Notes and Block Buffer Behavior

The IPO block buffer on a typical 840D SL (NCU 720.x / 730.x) holds 50-150 preprocessed blocks depending on block size and active technology. Each STOPRE forces the buffer to drain to zero. Used on every block, STOPRE destroys the look-ahead and limits path velocity. The SYN qualifiers are the right tool: they insert an implicit STOPRE only at the specific access, not at every block. For variables that are read in many blocks, use SYNR; for variables written in many blocks that must be visible externally, use SYNW. For variables shared bidirectionally with synchronized actions or the PLC, use SYNWR.

Synchronized actions (motion-synchronous actions, WHEN ... DO) have their own synchronization model and do not require the same qualifiers because they execute at the IPO level. However, variables written in synchronized actions and read in the part program still need SYNR on the part-program side to ensure the read sees the synchronized-action write.

Edge Cases

• Latched writes from synchronized actions: If TVar is written by WHEN ... DO $AC_MARKER[1]=TVar and the part program reads TVar, declare TVar as SYNWR to avoid stale reads.
• Subprograms with local PROC-scope variables: DEF PROC variables are local to a program and are not affected by the operator panel, so the synchronization question does not arise. STOPRE at the end of the subprogram does not change their lifetime.
• Frame variables and axis variables: Frames (FRAME type) and AXIS references have the same preprocessing behavior; SYNR applies to them as well.
• Tool-offset access: Tool-length and radius writes from the HMI are already synchronized at a lower level; do not add STOPRE before every tool change unless an explicit need exists.
• Preprocessing during block search: Block search uses the same preprocessing buffer. MD11450 $MN_SEARCH_RUN_MODE bit 5 (SERUPRO) provides a controlled search-with-computation mode that respects STOPRE.

Summary of the Recommended Fix

For the case in the source – a GUD read in F= of a motion block and modified from the operator panel – the minimal, correct change is one line in UGUD.DEF:

If the variable is also written by the part program and read by the HMI, upgrade to SYNWR. If the variable is only ever read, SYNR is sufficient. The implicit STOPRE triggered by the qualifier makes the next read of the variable pick up the operator-panel change immediately, and the part program no longer needs explicit STOPRE commands scattered through the G-code.

FAQ