802Dsl Custom Screen: GUD Variables and PLC Float Transfer

Overview

The Siemens SINUMERIK 802D sl custom-screen runtime executes XML-defined screens on the operator panel. The XML instruction set includes <let>, <op>, <print>, <function>, <function_body>, and <control> tags. The HMI parser supports references to NCK setting data, NCK machine data, channel parameters, R parameters, GUD variables, and PLC data blocks, plus the NCK-PLC exchange area conventionally starting at VB49000000.

This reference covers three recurring engineering tasks that appear across 802D sl commissioning projects:

1. Defining Global User Data (GUD) variables and sizing the machine-data arrays that control the GUD count.
2. Mirroring GUD values into the PLC data block DB20 so that ladder logic can read or write them.
3. Transferring floating-point values between the custom HMI and the PLC using the double-word (DBD) access path and the VB49000000 exchange area.

The reference also documents the <function>/<function_body> tag pair used to create subroutines, the let/op/print base instruction set, and the file-system workaround for the documented STRING-GUD critical-error condition on firmware versions prior to 06.06.04.

Prerequisites

• SINUMERIK 802D sl control with the HMI Programming Package (ConfigDesign or HMI-Advanced sl configuration tool) installed on the engineering workstation.
• PLC firmware compatible with the GUD mirror block DB20 (toolbox PLC 06.06.xx or later recommended).
• NCU access level "Service" (or manufacturer) to edit machine data and GUD definition files in /_N_DEF_DIR/.
• Read/write permission on the HMI project directory, typically /user/sinumerik/hmi/, to deploy the custom screen XML.
• STEP 7 / S7-200 MicroWIN tool for PLC-side verification of DB20 offsets and the VB49000000 exchange area.
• For STRING GUD write: 802D sl firmware 06.06.04 or later, or a working file-system cover-cycle alternative.

Custom-Screen XML Tag Reference

Each custom screen is a single XML file placed in the HMI project tree. The tags form a small instruction set executed in interpreter order; the parser evaluates <let> declarations first, then walks the screen in document order, executing <op>, <function>, <print>, and rendering <control> blocks.

Local types supported inside <let> include INT, FLOAT, DOUBLE, STRING, and BOOL. The FLOAT type is implemented in 802D sl firmware 06.06.xx and later; older reference manuals only list INT and DOUBLE for script-local floats, but FLOAT works on shipping firmware.

GUD Definition Files and Syntax

Global User Data are defined in plain-text *.DEF files stored on the NCU file system under /_N_DEF_DIR/. The most common location is SGUD.DEF (Siemens-defined default GUD), which is loaded automatically at NCK startup. Customer-specific definitions can also be created in MGUD.DEF, UGUD.DEF, or in GUD4.DEF through GUD9.DEF.

Definition line syntax follows the pattern:

DEF <area> <type> [<access-read>] [<access-write>] <name>[<array-dim>] ; comment

Example SGUD.DEF block:

; Siemens GUD defaults
DEF NCK INT  APR 7 APW 0 _GC_PARR[32]    ; global integer parameters
DEF CHAN REAL APR 1 APW 1 _CH_RPAR[16]  ; per-channel real parameters
DEF NCK STRING APR 1 APW 1 _WP_NAME     ; workpiece program name
DEF NCK INT  APR 1 APW 1 _SPINDLE_SPEED ; spindle speed reference

Important constraint on STRING-type GUD: writing a STRING GUD from a custom-screen XML control on 802D sl firmware prior to 06.06.04 raises a critical HMI error and restarts the HMI. The same control binding to an INT or DOUBLE GUD operates normally. The workaround section below provides a file-system-based method that is independent of the STRING GUD handler.

Machine Data for GUD Array Sizing

The maximum number of user-defined variables per data type is controlled by machine data. The field report cites the legacy 802D numbering N14504/N14506/N14508, which correspond to the modern 802D sl MDs 14510/14512/14514. The standard Siemens identifier is $MN_USER_DATA_INT/HEX/FLOAT (older docs use $MN_MAXNUM_USER_DATA_*). Verify the actual MD number on the installed firmware using the HMI startup screen's machine data browser before commissioning.

Example MD adjustment to reserve 16 REAL GUDs and 32 INT GUDs:

MD14510 USER_DATA_INT       = 32
MD14512 USER_DATA_HEX       = 0
MD14514 USER_DATA_FLOAT     = 16

; After write:
PI: _N_OSTART

; Persist:
PI: _N_SAVE_MD

; Verify:
DIAGNOSIS > GUD   ; should show _GC_PARR[0..31], _CH_RPAR[0..15]

Diagnostic verification: open MENU SELECT > DIAGNOSIS > GUD on the operator panel. The screen lists every defined GUD, its current value, and the symbolic offset it occupies inside DB20. The order in the diagnostic screen matches the order of definition in the *.DEF file.

Mapping GUD to PLC Data Block DB20

Once GUDs are defined and the count MDs are sized, the current values are mirrored into PLC data block DB20. The NCK computes the offset layout inside DB20 at startup. The HMI GUD diagnosis screen reports the symbolic offset; STEP 7 symbolic notation can be used to address them once the DB20 symbolic file is imported.

Offset rules of thumb:

• INT and HEX GUDs occupy 4 bytes each (DBD width) in the DB20 mirror, even though their nominal width is 2 bytes. This is a known 802D sl quirk that simplifies alignment for the double-word access path.
• REAL and DOUBLE GUDs occupy 8 bytes (two DBDs) each, with the value aligned to the lower 4 bytes.
• STRING GUDs occupy 32 bytes each (16 characters + 16-byte header).

For example, if _GC_PARR[1] is the first INT GUD, the value is typically accessible at DB20.DBB0 (byte), DB20.DBW0 (word), or DB20.DBD0 (double word). For REAL (4-byte float) GUDs, always use the DBD offset.

Reading the float GUD in STEP 7 STL:

; STL snippet
L     DB20.DBD    0       ; load REAL from offset 0
T     MD     100         ; transfer to flag area
; or directly:
L     DB20.DBD    0
T     DB100.DBD   0       ; mirror to user DB

Writing from the PLC back into the GUD is done by writing to the same DB20 offset:

L     MD     110
T     DB20.DBD    12      ; write to GUD at offset 12

Accessing GUD Variables from a Custom Screen

Inside an 802D sl custom screen, GUD variables are addressed using the path syntax:

gud/<variable_name>

The path is case-sensitive. The leading underscore is part of the identifier and must be included. Example assignments and bindings:

<!-- Read GUD INT into a local variable -->
<op> my_int = "gud/_GC_PARR[1]" </op>

<!-- Read GUD REAL into a local variable -->
<op> my_real = "gud/_CH_RPAR[5]" </op>

<!-- Bind a control directly to a GUD INT -->
<control name="field_int" xpos="20" ypos="40" width="100"
         refvar="gud/_GC_PARR[1]" />

For REAL display, the control must declare the DISPLAY_FORMAT attribute to force float formatting; without it, the HMI may render the value in scientific notation or as a raw hex word, depending on the active HMI locale and the user-key setting.

<control name="label1" xpos="32" ypos="23" height="36" width="80"
         fieldtype="readonly" refvar="gud/_CH_RPAR[5]"
         DISPLAY_FORMAT="FLOAT" hotlink="true" />

PLC Float Transfer to a Custom Screen

Floating-point values stored in the PLC cannot be addressed using a "float" type in the custom-screen path syntax. The correct access is the double-word (DBD) form. For example, the REAL stored at DB1000.DBD0 is referenced as:

plc/db1000.dbd0

Assigning to a local FLOAT variable in the XML script:

<let name="db_displ" type="FLOAT">1.0</let>
...
<op> db_displ = "plc/db1000.dbd0" </op>
<print text="db_displ %f"> db_displ </print>

Displaying in a control with a label bound directly to the PLC DBD address:

<control name="label1" xpos="32" ypos="23" height="36" width="80"
         fieldtype="readonly" refvar="plc/db1000.dbd0"
         DISPLAY_FORMAT="FLOAT" hotlink="true" />

Notes on float handling:

• The local variable type FLOAT in <let> is not officially documented in older 802Dsl reference manuals but is implemented in firmware 06.06.xx and later. Use DOUBLE for wider compatibility if a precision loss is acceptable.
• Always use DISPLAY_FORMAT="FLOAT" on controls bound to a DBD; otherwise the value is rendered as integer.
• If the float is read but appears wrong (e.g., value is doubled, halved, or zero), verify the byte order. 802D sl uses little-endian (Intel) byte order, which matches STEP 7 default. If the source is a third-party PLC emulator, the byte order may need to be byte-swapped in the script before use.
• For negative values, ensure the source REAL in the PLC is stored as IEEE-754 single precision (32-bit). 802D sl does not automatically convert fixed-point or BCD representations to IEEE-754 float.

Function and Function_Body Tags

The <function> and <function_body> tags implement subroutines in the custom-screen XML instruction set. A function body defines a named block of instructions, and a function call executes it.

Defining a function body

<function_body name="my_function">
    op   result = "nck/channel/parameter/r[1]" * 3
    print text="result %f" result
</function_body>

Calling a function

<function name="my_function" />

Common use cases:

• Encapsulating repetitive math on GUD or PLC values.
• Wrapping doc.writetofile or doc.readfromfile calls to log data to the NC file system.
• Implementing a "Reset" or "Initialize" routine that resets several GUDs to default values.
• Building a state-machine step that advances based on a PLC handshake bit.

Predefined functions delivered with the HMI include string operations (string.length, string.sub), math operations (math.abs, math.sqrt), file I/O (doc.writetofile, doc.readfromfile), and time/date utilities (time.now, date.format). These can be invoked directly without a function_body.

Let, Op, and Print Instruction Set

The base instruction set used inside a custom screen is composed of three primary tags plus the <function>/<function_body> pair.

Format specifiers follow C printf conventions: %d for int, %f for float/double, %s for string, %x for hex. A variable declared with <let> is scoped to the screen (and any embedded function bodies). It is not persistent across screen transitions; to persist, write to a GUD or to a PLC DB.

String GUD Workaround Using the NC File System

On 802D sl firmware prior to 06.06.04, attempting to write a STRING-typed GUD from a custom-screen XML control raises a "critical error" and restarts the HMI. The same control binding to an INT or DOUBLE GUD operates normally. The recommended workaround is to write the desired string (typically a part-program file name) to a known MPF file using the doc.writetofile predefined function, then have a cover cycle read that file and CALL the program by name.

Example XML fragment to write a dynamic file:

<!-- line feed constant -->
<let name="LF" type="string">\n</let>

<!-- m30 program terminator -->
<let name="M30" type="string">M30</let>

<let name="cover_cycle_content" type="string"></let>
<let name="pname" type="string"></let>
...
<op> cover_cycle_content = pname + LF + M30 + LF </op>

<function name="doc.writetofile">
    _T"\mpf\wp_call.mpf", cover_cycle_content
</function>
...
<control name="cprog_name" xpos="440" ypos="190" width="100"
         type="string" refvar="pname"/>

The cover cycle program wp_call.mpf then reads the file name and calls it:

; wp_call.mpf
DEF STRING[32] WP_NAME
WP_NAME = "selected.mpf"   ; or read from a GUD / PLC byte stream
CALL "selected.mpf"
M30

This approach avoids the STRING GUD critical error and works on all 802D sl firmware versions because the file system API is independent of the GUD string handler. The cost is one extra NC file write per selection; the file is on the NCK compact flash and survives power cycle.

Exchange Area VB49000000 (NCK-PLC HMI Data)

The NCK-PLC exchange area is a memory region visible to both NCK and PLC, conventionally starting at VB49000000 in 802D sl projects. This area is bidirectional and survives power cycle (when the relevant MD is configured for retentive behavior). It is the recommended channel for transferring data between a custom HMI screen and the PLC when:

• The data does not need to be visible inside the part program (use GUD/setting data instead).
• The PLC is the data owner and the HMI is presenting it.
• Bit-level handshake signals are required alongside a multi-byte payload.
• High-frequency updates are needed and the NCK GUD write path is too slow.

Standard layout convention (verify against the actual 802D sl toolbox project before committing):

Reading a float from the exchange area in a custom screen:

<op> my_float = "plc/vb49000000.dbd0" </op>

Writing a float into the exchange area:

<op> "plc/vb49000000.dbd0" = my_float </op>

Handshake convention — HMI sets bit, PLC acks:

; Custom screen side
<op> "plc/vb49000032.0" = 1 </op>
; ... wait for ack ...
<op> my_ack = "plc/vb49000033.0" </op>
; PLC side (STL)
U     E     32.0       ; HMI request bit
S     A     100.0      ; set internal acknowledge
U     A     100.0
R     E     32.0       ; clear HMI request once read

On the PLC side, the exchange area is typically declared in the symbol table as a P-bus data block (or addressed as V-memory on the 802D sl toolbox PLC). Verify the byte order, which is little-endian on 802D sl and matches STEP 7 / MicroWIN conventions.

Commissioning Procedure

1. Plan the GUD array sizes: count the INT, REAL/DOUBLE, and HEX/BOOL variables you need. Add 20% headroom for future extensions.
2. Edit the appropriate *.DEF file (start with SGUD.DEF) and add the DEF lines with correct access levels (APR/APW) and a comment.
3. Set MD14510/14512/14514 to the planned counts. Trigger PI _N_OSTART and verify no startup alarm is logged. Save with PI _N_SAVE_MD.
4. Open DIAGNOSIS > GUD on the HMI and confirm every defined variable appears with its symbolic offset inside DB20.
5. From STEP 7, add a watch table on DB20 at the reported offsets. Cycle NCK power and verify the values are mirrored correctly.
6. Create the custom-screen XML. Use DISPLAY_FORMAT="FLOAT" on any control bound to a REAL or DBD. Validate the XML externally before deployment.
7. Test the round trip: change the value in a control, confirm it appears in DB20, modify from PLC, confirm it appears on the HMI.
8. For string transfer, prefer the file-system cover-cycle pattern. If the firmware supports STRING GUD writes (06.06.04+), still test the critical-error path under fault conditions before relying on it in production.
9. For high-frequency or PLC-owned data, use the VB49000000 exchange area with a handshake bit pair.
10. Document every GUD, its units, and its range in the project commissioning log. Train operators on access levels so that write-protected variables cannot be modified from the HMI.

Troubleshooting Matrix

Best Practices

• Always declare DISPLAY_FORMAT="FLOAT" on controls bound to REAL or DBD addresses.
• Reserve the GUD-count MDs at commissioning; changing them in production causes memory re-layout.
• Use a cover cycle (file-system approach) for any dynamic string transfer; do not depend on STRING GUD write support.
• Encapsulate repetitive logic in function_body blocks; the screen XML is much easier to maintain and to unit test in isolation.
• For high-frequency data, prefer the exchange area VB49000000 over GUD, because GUD write goes through NCK processing and can be slow at 100 ms+ cycle times.
• Use symbolic comments in the *.DEF file to document each variable's intent, units, and valid range.
• Validate any custom-screen XML externally before deploying to the HMI to catch unbalanced tags.
• Configure access levels (APR/APW) so that operator-level users can read but not modify critical GUDs.
• Keep a GUD cross-reference table: column = GUD name, column = DB20 offset, column = STEP 7 symbolic name. Update it whenever the .DEF file changes.
• Use hotlink="true" only on controls that genuinely need real-time update; it costs CPU on every NCK tick.