Configuring $MN_LUD_EXTENDED_SCOPE on SINUMERIK 840D sl

Configuring $MN_LUD_EXTENDED_SCOPE on SINUMERIK 840D sl

Overview

Variables declared with DEF inside a SINUMERIK part program are classified as Local User Data (LUD). By default they are scoped strictly to the program level where the declaration appears, so a subprogram or a Siemens cycle such as CYCLE95 cannot see them. When a contour turning macro needs a named variable to flow from the main program into the cycle's contour subroutine, the standard solution paths are R-parameters, a User Global User Data (UGUD) definition, or toggling the machine data $MN_LUD_EXTENDED_SCOPE.

This reference documents:

• The SINUMERIK variable scope model (LUD, GUD, R-parameter, MD settable variables)
• Bit-level semantics of $MN_LUD_EXTENDED_SCOPE
• The root cause and decode of the alarm "Maschinendatum wegen fehlender Zugriffsrechte 2 nicht geändert"
• Three field-proven solution paths: permanent MD change, R-parameter substitution, and UGUD.def declaration
• Step-by-step commissioning procedures including access-level management
• Verification, troubleshooting matrix, and field risk analysis

Prerequisites

SINUMERIK Variable Scope Model

SINUMERIK distinguishes four primary user-variable scopes. Understanding the differences prevents the typical confusion between LUDs that "don't work in subprograms" and R-parameters that always do.

Program-level nesting follows the call stack. The main program is the highest level. A subroutine called from the main program is one level below. A subroutine called from that subroutine is two levels below. By default, LUDs defined at one level are invisible at any other level.

Inline Scope SVG Diagram

The $MN_LUD_EXTENDED_SCOPE Machine Data

$MN_LUD_EXTENDED_SCOPE controls whether LUD variables defined at a higher program level can be read or written by lower program levels (subprograms, Siemens cycles, user macros).

Syntax Reference

The MD identifier follows the Siemens naming convention $MN_<NAME>. Inline assignment in a part program:

$MN_LUD_EXTENDED_SCOPE=1

Common typos that produce confusing alarms:

N10 $MN_LUD_EXTENDED_SCOPE01     ; INCORRECT - stray "01", no '='
N10 LUD_EXTENDED_SCOPE=1         ; INCORRECT - missing $MN_ prefix
N10 $MN_LUD_EXTENDED_SCOPE 1     ; INCORRECT - missing '='

The correct, minimum block is a single statement on its own line, optionally preceded by a block number:

N10 $MN_LUD_EXTENDED_SCOPE=1

Activation Behavior

Root Cause: The "Fehlende Zugriffsrechte" Alarm

When the inline write

N10 $MN_LUD_EXTENDED_SCOPE=1

is executed and the controller responds with:

Maschinendatum (und evtl.weitere) wegen fehlender Zugriffsrechte 2 nicht geändert

the alarm text decomposes as follows:

Siemens Access Level Convention

Note: the numeric level is inverse — lower number = higher privilege. $MN_LUD_EXTENDED_SCOPE is protected at numeric level 2 for part-program write. The HMI in operator mode typically operates at numeric level 3 (User) or higher, so the write is rejected unless service access is unlocked.

Solution Path A: Permanent MD Change via HMI Commissioning

This is the most maintainable solution when the behavior is desired across multiple part programs.

When to Use

• Multiple programs need LUD sharing
• Machine builder has been informed and existing cycles audited
• A controlled NCK restart window is available

Procedure

1. Switch the HMI to commissioning / setup mode (Setup menu in SINUMERIK Operate).
2. Open the machine data list: Setup → Machine Data → Display MD (or General MD, depending on controller generation).
3. Filter for LUD_EXTENDED_SCOPE or navigate the tree manually.
4. Change the value from 0 to 1.
5. Confirm and save. The HMI prompts for an NCK reset; choose the reset class appropriate to your environment (configuration reset is usually sufficient).
6. Wait for the NCK to come back up. Verify the new value by reading the MD back in the list.

Solution Path B: R-Parameter Substitution

This is the most common workaround when the machine builder does not want $MN_LUD_EXTENDED_SCOPE changed.

Why R-Parameters Work

R-parameters (R0..R99 standard, R100+ on larger NCKs) are arithmetic variables visible across all program levels for the duration of the program run. They are not subject to LUD scope rules, and they do not require any access level to assign or read.

CYCLE95 R-Parameter Example

; Main program - Huelse length passed as R1
R1 = -25.0
N900 CYCLE95 ("START1:END1", 1.5, 0.1, 0.05,, 0.1, 0.1,, 3)
N910 GOTOF END1
N920 START1:
N930 G1 X41 Z0.1
N940 Z0
N950 G2 X39.42 Z-0.593 CR=0.8
N960 G1 X38.13 Z-3
N970 Z= R1                ; contour block consumes R1 directly
N980 X34
N990 END1:
M30

The cycle CYCLE95 calls the contour subroutine START1:END1; the contour reads R1 directly, bypassing any LUD scoping issue.

Reserved Parameter Strategy

Some legacy Siemens cycles overwrite R-parameters internally. Adopt a reservation policy:

Solution Path C: UGUD.def Named Global Variables

This path is preferred when the variable must be a named global (e.g., Huelsenlaenge) and the integrator does not want to enable $MN_LUD_EXTENDED_SCOPE.

UGUD.def Structure

The file UGUD.DEF (User Global User Data) lives in the NCK definitions directory and is loaded at NCK startup. Add a declaration line:

; UGUD.DEF
DEF NCK REAL Huelsenlaenge

After the next NCK startup, Huelsenlaenge is available in any program at any level. Its lifetime is the NCK session — it survives program end, lost at NCK reset unless backed by a persistent declaration.

Persistent Variation

For values that should survive NCK reset, use the SAVE attribute (software-version dependent):

DEF NCK REAL SAVE Huelsenlaenge

Confirm SAVE availability for your NCU software version before relying on it.

Editing and Activation

1. Access the system def files (typically /NCK/Definitions/UGUD.DEF) via the Setup → Define Data menu, or via file transfer.
2. Edit the file and save.
3. Trigger an NCK PowerOn. The new symbol table becomes active on next NCK startup.
4. Some controllers require explicit re-initialization via Setup → Define Data → Activate.

Writing $MN_LUD_EXTENDED_SCOPE from a Part Program

For runtime adjustment (e.g., in a startup macro or conditional program), use the inline assignment. The syntax is straightforward, but several preconditions must be met.

Inline Write Block

; Place as the first executable block of the program
N10 $MN_LUD_EXTENDED_SCOPE=1

Preconditions

• Current access level must be ≤ 2 (Service). Confirm in the HMI status bar.
• Key switch set to position 3, or service password entered.
• The MD must be classified as settable from the part program (the LUD-related MDs are settable inline in current SINUMERIK versions).

Full Procedure

1. Set the access key switch to position 3 (or input the service password via Setup → Password).
2. Confirm the access level indicator shows "Service" or numerically ≤ 2.
3. Insert the assignment as the first executable block.
4. Run or dry-run the program.
5. If accepted without alarm, expect a subsequent alarm or message indicating PowerOn required.
6. PowerOn the NCK.
7. Re-read the MD to confirm the new persistent value.

Limitations of the Inline Write

Risk Analysis and Field Notes

Enabling $MN_LUD_EXTENDED_SCOPE = 1 changes the meaning of identically named variables that were previously considered distinct. If shop-standardized names (e.g., WERT, Huelsenlaenge, MESS_AUF) appear at multiple levels of legacy cycles, the change can produce name collisions that surface only at first invocation.

Verification

After enabling extended scope, run a controlled verification sequence before relying on the behavior in production.

Test 1: Read-Through

; Main program
DEF REAL TEST_VAL = 42.0
N100 L_TEST_UP
N110 M30

; Subroutine (L_TEST_UP.SPF)
N10 R10 = TEST_VAL      ; reads LUD from main program
N20 M17

Expected: no alarm; R10 equals 42.0 after the subroutine returns.

Test 2: Collision Alarm

; Subroutine (L_TEST_UP.SPF)
N10 DEF REAL TEST_VAL = 99.0   ; expected to alarm
N20 M17

Expected: alarm indicating name redefinition under extended scope.

Test 3: CYCLE95 Variant

Mirror the structure of the failing production program: define a named LUD, assign it, call CYCLE95, verify the contour subroutine can read it (with the contour subroutine either reading the LUD directly or reading an R-parameter the main program assigns from the LUD).

Troubleshooting Matrix

Related Machine Data

These are typically set during initial commissioning and rarely changed in the field. Review them before enabling extended scope, because the LUD name space usage grows if many programs adopt shared LUD names.

Field Commissioning Checklist

1. Export the current machine data via Setup → Series Comm. → Backup for restore.
2. Generate the cross-reference of DEF statements in shop programs and OEM cycle directory.
3. Identify duplicate identifiers at different program levels; flag collisions.
4. Schedule a maintenance window for NCK PowerOn.
5. Set key switch to position 3; confirm "Service" indicator.
6. Modify the MD via Setup menu; save.
7. Trigger NCK reset / PowerOn.
8. Re-read the MD to confirm persistence.
9. Run the verification test sequence above on a non-production program.
10. Run a controlled production dry run before resuming normal production.
11. Document the change in the machine logbook with date, software version, and operator.

Cross-Reference: Variable Concept Background

The concept of a named, scoped storage location that programs read and write is fundamental to all high-level programming languages, including the part-programming language used on SINUMERIK controllers. The mechanics of declaration, scope, lifetime, and visibility apply identically to LUD, GUD, and R-parameter semantics on the NCK side. A general treatment of variables in high-level programming languages is available at the Wikipedia variable article.

FAQ