S7-1500 Starting Values Not Updating in Node-RED S7 Node

Problem Overview

Engineers integrating Siemens S7-1500 (and S7-300/1200) PLCs with Node-RED using the oriolrius/node-red-contrib-s7 package frequently encounter two distinct symptoms after modifying data blocks in TIA Portal:

1. Modified starting values declared on static DB tags do not appear in the Node-RED S7 In node payload after a project download.
2. Reading an address that does not correspond to a defined variable in the DB still returns an integer-like value (a "ghost read") rather than a quality error.

Both behaviors are rooted in the S7-1500 runtime model and the way the S7 protocol exposes process memory. The issues are not bugs in Node-RED or the S7 node; they reflect a misunderstanding of what "starting value" means on a Siemens PLC and what the S7 node is doing on the wire.

Root Cause: Starting Value vs. Actual Value

In TIA Portal V15–V19, every static tag in a global or instance data block carries three distinct attributes:

When you change the Start value in the TIA Portal project and perform a Download to device, the S7-1500 CPU (firmware V2.5 and later, including V3.x for S7-1500/S7-1500T) does not automatically overwrite the actual value of existing tags. The download is a delta load: the new initial values sit in load memory waiting for the next DB initialization event. This is documented in the Siemens Industry Online Support KB article on DB download behavior.

Consequence: Node-RED, which talks to the CPU via S7 communication (PUT/GET or optimized DB read services), reads the actual value, not the start value. The actual value remains the value the user program (or a previous online write) last placed there.

Root Cause: Ghost Reads on Undefined Addresses

The S7 protocol is a memory-mapped read interface. A read request at offset 8.0 of DB1 returns the four bytes that happen to occupy that location in the CPU's work memory at the moment the read is serviced. The S7-1500 CPU does not perform a symbol lookup or a "is this variable defined?" check; it just hands the bytes back.

On an S7-1500 with an optimized DB, the compiler is free to reorder and pack variables. If a variable was removed or never declared, the bytes that remain may be:

• Remnants of a previous symbol that was deleted (still physically in the work memory region).
• The result of the wear-leveling allocation that the S7-1500 memory manager performs internally for non-retentive data.
• Simply zero, or simply a pattern from a previously active program scan.

On an S7-300, the same effect is more pronounced because classic (non-optimized) DBs use fixed offsets that survive symbol deletion. The PLC keeps the bytes; only the symbol table entry is gone. This is also the reason users on S7-300 sometimes see a value of 2.1019476964872256e-44 when reading a REAL at an offset that contains garbage bytes — the IEEE 754 decoder happily interprets any 4 bytes as a float. See the Node-RED Discourse: S7-300 REAL abnormal read for a worked example.

S7-1500 Download Semantics That Affect Node-RED

For S7-1500 CPUs (6ES751x, 6ES752x, ET 200SP CPU, and the S7-1500T motion controller family) running firmware V2.5 or higher, the download behavior depends on the DB attribute "Retain", the download with consistency check setting, and whether the CPU is in RUN during the download.

To force a TIA Portal download that applies new start values without stopping the PLC, right-click the DB → Download to device → Software (only changed blocks), and on the "Consistent download" dialog check "Reinitialize DBs". The S7-1500 will then write the start value into the actual value of every non-retain tag, which Node-RED will pick up on its next poll cycle.

Node-RED S7 Node Configuration

The oriolrius/node-red-contrib-s7 node uses a payload schema of {variable, address, type} for legacy S7-300 reads and the typed address object for S7-1500 optimized access. A minimal read configuration looks like:

[
  {
    "variable": "test",
    "address": "DB1",
    "type": "INT",
    "offset": 0
  },
  {
    "variable": "test2",
    "address": "DB1",
    "type": "INT",
    "offset": 2
  }
]

Two common configuration mistakes produce the exact symptoms described in the source thread:

1. Duplicate address entries. Two entries both pointing at DB1, INT, offset 0 will return identical values, and the second variable name acts only as a label. Always assign non-overlapping offsets: 0, 2, 4, etc., because INT is 16 bits (2 bytes) and S7 memory is byte-addressable.
2. No symbol binding. The S7 node does not look up the variable name against the PLC symbol table; it only sends the offset to the CPU. If the offset in Node-RED does not match the offset that TIA Portal assigned to the tag, you will read whatever bytes happen to be at that physical offset.

Step-by-Step Resolution

Step 1: Verify the S7 Node Reads the Correct Symbol

In TIA Portal, open the DB in "Open in read-only mode" while online (right-click DB → "Open online"). The Monitor column shows the actual value the CPU currently holds, and the Offset column (in the "Details" view) shows the byte offset the compiler assigned. Cross-check this offset with the value configured in the S7 node. The two must match exactly.

Step 2: Reinitialize the DB After Editing Start Values

When the goal is to make a new start value visible in Node-RED, choose one of the following methods:

Step 3: Fix Duplicate or Mis-Aligned Address Entries

In the S7 In node configuration, ensure every {variable, address, type, offset} triple has a unique combination. For multi-word data types use proper strides:

INT  → 2 bytes, increment offset by 2
DINT → 4 bytes, increment offset by 4
REAL → 4 bytes, increment offset by 4
BOOL → 1 bit, format: offset = byte.bytebit (e.g. 4.0 for byte 4, bit 0)

For BOOL reads in the oriolrius S7 node, the address string format is DB1,X4.0 for a bit at byte 4, bit 0. Mismatches between bit and byte access in optimized DBs can also produce "ghost" reads of 0 or 1.

Step 4: Validate Against Symbol Table

Export the PLC symbol table from TIA Portal (PLC → "Export to text file") and compare it against the S7 node configuration in Node-RED. The exported text file lists every DB number, byte offset, bit offset, and data type. Any address in the S7 node that does not appear in this file is reading unallocated memory.

Verification Procedure

1. Place a debug node connected to the S7 In node and deploy.
2. In TIA Portal, open the target DB online and change the monitor value of a known tag (right-click → "Modify" → enter new value → Apply).
3. Within one Node-RED poll cycle (default 1000 ms for the oriolrius S7 node, configurable via the cycle parameter), the debug pane should show the new value.
4. Change the Start value of the same tag in the offline project, download with "Reinitialize DBs" checked, and verify the value flips to the start value in the Node-RED debug output.
5. Delete the S7 In node's entry for one variable, then re-add an entry pointing at an unused offset. Confirm that the value returned is undefined, 0, or noise (and not a quality error in every S7 node version — the oriolrius node historically returns a "Failure (Bad values)" debug message in such cases; documented in the node-red-contrib-s7 GitHub README).

Edge Case: REAL Type Decoding on S7-300

The S7-300 stores REAL values in IEEE 754 single-precision format (32 bits, big-endian byte order). If the S7 node is configured to read a 4-byte REAL from an offset where the underlying memory is actually an INT (2 bytes) followed by two bytes of unrelated data, the result will be an exotic float such as 2.1019476964872256e-44 — the IEEE 754 representation of 0x00000041. The fix is to align the S7 node's declared type with the TIA Portal data type exactly. A common variant of this error appears on LOGO! 8 controllers when an analog input occupies two 16-bit words but is read as a single 32-bit value; see the Node-RED Discourse: S7 node analog output problem for a field case.

Edge Case: Optimized vs. Non-Optimized DBs

On S7-1500, the default for new DBs is "Optimized block access". With optimized access enabled, byte offsets in the S7 node will not match the symbolic offsets shown in TIA Portal — the compiler reorders the layout. The S7 node typically still works because the PUT/GET or S7 communication path resolves symbolic names, but if the Node-RED side uses raw offset reads, disable optimization in the DB properties ("Attributes" tab → uncheck "Optimized block access"). For S7-300, optimization does not exist; offsets are always the literal declaration order.

Edge Case: Retain and Non-Retain Tag Behavior

When a DB is reinitialized and a tag is marked "Set in IDB" with retain, the start value is written only on cold restart, not on RUN-mode DB reinit. This is intentional: the retain mechanism is designed to survive power cycles. If Node-RED reads a retain tag whose start value was changed in TIA Portal but the PLC was not power-cycled, the previous actual value persists. To force a refresh, either power-cycle the PLC, or remove the retain attribute, download, and set it again.

Troubleshooting Matrix

Performance and Polling Considerations

On S7-1500 CPUs, the S7 communication path (PUT/GET and the S7 node's optimized read services) is rate-limited by the configured S7 connection resources. The default allows up to 16 simultaneous S7 connections. The oriolrius S7 In node typically establishes a single connection per configured address block and polls at the configured cycle interval (default 1000 ms). For 50+ tags, batch them into a contiguous read of the DB's working range — the S7 node's address object with length set to the full DB size is more efficient than 50 individual tag reads, and reduces the chance of catching the DB mid-update with mixed-cycle garbage reads. Document the polling pattern in the Node-RED flow's description so future maintainers can correlate the visible values with the PLC scan.

Security and Access Rights

The S7 node reads require the PLC's PUT/GET access to be enabled for the appropriate connection. On S7-1500, this is under PLC Properties → Protection & Security → Connection mechanisms → "Permit access with PUT/GET communication from remote partner". Without this, the S7 In node will fail to connect or return a security error. If the PLC is behind a Siemens SCALANCE firewall, port 102/TCP must be open and the firewall's deep-packet-inspection profile for S7 must allow the read functions used by the node. Production environments with safety-integrated CPUs (S7-1500F) may require the safety program to be unlocked before any read can complete — refer to the Siemens Industry Online Support portal for safety-mode read access restrictions.

FAQ