Tracing SINUMERIK 840D PLC-to-NC Data Block Access

David Krause6 min read
Other TopicSiemensTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

The database number is not bound to an NC subprogram merely because that subprogram uses byte offsets. The NC access path must resolve those offsets through a declared variable, a configured PLC-to-NC exchange area, or another machine-specific interface. To make NC read DB218, identify the existing access mechanism, expose the block through that mechanism in the PLC or interface configuration, and verify the values online from both sides.

Symptom interpretation

The visible symptom is an NC subprogram that assigns PLC data to NC variables while showing only byte numbers. A byte number is an offset, not a complete PLC address. It cannot identify DB10, DB218, or any other data block by itself.

The term here means that a complete data reference needs both a storage area and an offset within that area. When an NC statement contains only the offset, the storage-area selection occurs elsewhere. Common locations are the NC variable declaration, a machine-specific interface definition, a higher-level calling program, or PLC logic that copies data into an exchange area already visible to NC.

Observed behavior Likely interpretation Deciding check
NC reads the expected value from the same byte number used in DB10 The offset probably addresses the established PLC-to-NC interface area Change a controlled test value at that interface offset and monitor the NC variable
NC reads data associated with DB218, although the block number is absent from the subprogram A declaration, mapping, or PLC copy operation hides the block selection Use PLC cross-references and NC symbol searches to locate the mapping path
Changing DB218 has no effect in NC The block is not the active source, is not exposed, or is overwritten before NC reads it Monitor the source, exchange location, and NC destination at the same time

PLC-to-NC access mechanism

PLC memory and NC memory are separate execution domains. A normal PLC data block does not become an NC data source solely because it exists or because an NC subprogram uses a matching byte offset. The controller configuration must provide a defined exchange path.

Two architectures explain the hidden database number. In a mapped architecture, an interface declaration associates NC-visible data with a PLC area; the NC code then uses an offset or symbolic variable within that declared area. In a copied-data architecture, PLC logic moves values from a working block such as DB218 into an established exchange block such as DB10; the NC program reads only the exchange location.

These architectures require different changes. Alter the interface declaration for mapped access. Alter PLC transfer logic for copied access. Adding DB218 or changing its contents without modifying the active path will not redirect the NC read.

Mapping-location diagnostics

Start from the NC destination variable and trace backward. Do not select a data block by comparing byte numbers; identical offsets can exist in every PLC data block.

  1. Find where the NC variable is declared. Record its type, array bounds if present, and any associated PLC or interface reference.
  2. Search the complete NC project for the variable name and the observed byte offset. Include initialization files, global definitions, calling programs, and machine-specific interface files rather than only the subprogram.
  3. In the PLC project, generate cross-references for DB218 and the relevant offsets. Look for read, write, move, block-copy, or interface-transfer logic.
  4. Repeat the cross-reference check for DB10. A write into DB10 followed by the expected NC value identifies a copied-data path.
  5. Inspect the hardware and software configuration for the PLC-to-NC interface. Record which project artifact defines the visible area; the location depends on the installed 840D configuration and project structure.
  6. Check whether another cyclic routine overwrites the test location. A correct transfer can appear ineffective when later logic writes a different value during the same PLC cycle.

DB218 exposure procedure

Preserve the existing interface until its ownership and update direction are known. Directly repurposing an established offset can corrupt commands, status data, or synchronization information used elsewhere in the machine.

  1. Choose an unused exchange location with the required width and data type. Confirm through cross-references that neither PLC nor NC logic already owns it.
  2. Determine whether the current project uses direct mapping or PLC copying. Follow the existing project pattern instead of creating a second, competing route.
  3. For a copied-data design, add PLC logic that transfers the required value from DB218 to the selected NC-visible exchange location. Define the transfer direction explicitly and prevent other logic from writing the destination.
  4. For a mapped design, add DB218 through the project’s existing PLC-to-NC interface mechanism. The configuration must define the source area, offset, length, and data interpretation; read these fields from the installed project rather than inferring them from the NC byte number.
  5. Match the representation at both ends. Confirm byte width, signed or unsigned interpretation, integer or floating-point format, and byte ordering before using the value in calculations.
  6. Update the NC variable declaration or access definition so that the subprogram reads the selected interface location. Keep the subprogram’s process logic separate from the hardware mapping.
  7. Compile the affected PLC and NC components, resolve all address or type conflicts, and apply the project’s normal controlled download and restart procedure.

Numbered verification checks

  1. Check 1: PLC source. Write or generate a recognizable test value in the selected DB218 field. Expect the PLC online monitor to show that value remaining stable long enough for the transfer to occur.
  2. Check 2: Exchange destination. Monitor the mapped or copied interface location. Expect it to equal the DB218 source after the responsible PLC logic executes.
  3. Check 3: NC destination. Monitor the NC variable used by the subprogram. Expect the same value after accounting for its declared data type and any intentional scaling.
  4. Check 4: Change propagation. Apply at least two distinct test values. Expect each change to appear in the order source, interface, then NC variable; this separates a live transfer from a coincidental initial value.
  5. Check 5: Ownership. Hold the source constant while observing the interface location over multiple executions. Expect no unrelated value to overwrite it.
  6. Check 6: Boundary values. Test values that exercise the required sign and field width without exceeding the configured type. Expect no truncation, sign reversal, or byte-swapped result.

Recurring implementation pitfalls

Wrong practice Failure mode Correction
Treating an NC byte offset as a complete PLC address The engineer edits the wrong data block Locate the declaration or transfer path that supplies the missing storage-area context
Making DB218 in the PLC without exposing it NC continues reading the original interface area Add the required mapping or copy logic
Writing both PLC and NC values into one field Updates race or overwrite each other Assign one writer and one or more readers to each exchange field
Matching addresses but not data types The byte pattern arrives, but the numerical value is wrong Match width, representation, sign, and scaling on both sides
Changing an occupied interface offset Unrelated machine behavior changes Prove the location is unused with PLC and NC cross-references
Testing only one value A stale or default value looks like successful communication Verify multiple transitions from source through interface to destination

Frequently asked questions

What happens if DB218 exists but NC cannot read it?

The block is not automatically NC-visible. Add it through the installed interface mechanism or copy its required fields into the established exchange area.

What happens if DB10 and DB218 use the same byte offset?

The offset alone remains ambiguous because each block has its own address space. Trace the NC declaration and PLC cross-references to identify which block supplies the active value.

What happens if the PLC value changes but the NC value does not?

Monitor the intermediate exchange location. If it does not change, repair the PLC mapping or copy logic; if it changes correctly, inspect the NC declaration, data type, and update path.

How do I verify the SINUMERIK 840D data path?

Apply two recognizable values to the chosen DB218 field and monitor the source, interface location, and NC variable together. Expect each value to propagate through all three points without overwriting, truncation, sign reversal, or byte swapping.

Back to blog