Configuring Modbus Holding Registers in Siemens LOGO! Web Editor

1. The Problem in One Sentence

LOGO! Web Editor v1.1.0 only exposes a fixed set of variable block types — AI, AQ, AM, VB, VD, VW — through its Tag Table. None of them is named "Holding Register", and LWE has no direct register-address field, so a slider or numeric display cannot be bound to a Modbus object directly. The only way to surface Modbus data on an LWE page is to (a) read the registers with the LOGO!'s built-in Modbus client, (b) write the results into Variable Memory, and (c) bind the LWE widget to the matching VM address.

The most common symptoms reported on commissioned systems are:

• An LWE widget bound to "the Modbus variable" shows a stale or zero value, or no value at all.
• Values appear at the wrong offset — for example the slave's register 1 and register 2 both displaying the same number.
• Adding one register to the configuration that does not exist on the slave erases visibility of every other valid register.

All three are configuration problems in the LOGO! Soft Comfort project, not defects in LWE. This article walks through the correct configuration and the recovery actions for each symptom.

2. How LWE Talks to the Network

LWE v1.1.0 is a server-side web visualization embedded in the LOGO! 8 base module firmware. It does not implement Modbus; it polls the LOGO! firmware's internal memory only. The Modbus client lives in the LOGO! itself and writes the fetched values into VM, which is what LWE binds to. The full data path is:

Three configuration boundaries must be set up, in this order:

1. The Modbus client connection in LOGO! Soft Comfort (Tools → Ethernet).
2. The VM mapping that publishes the fetched registers into named memory areas (Tools → Parameter VM Mapping).
3. The LWE tag table that binds those VM areas to a slider, numeric display, or indicator (LWE → Global Configuration → Tag Table).

3. Prerequisites

4. Variable Type Mapping for Modbus Objects

A Modbus holding register is 16 bits wide per the Modbus Application Protocol specification, so it pairs naturally with the LOGO!'s VW (Variable Word) memory type. The direct guidance from the commissioning thread is:

A holding register in Modbus is mostly an integer value — so in LWE you need to use VW.

Decision path for the setpoint + actual value use case:

1. If both registers are documented as 16-bit integers, bind each to a single VW and use a numeric display widget in LWE.
2. If the process value is a 32-bit float (very common for VFDs, energy meters, and temperature controllers), bind it to a VD and read two consecutive Modbus registers. The two 16-bit words must be combined in the order the slave presents them — big-endian (most significant word first) on the majority of process instruments, little-endian on many low-cost PLCs. A swapped word order is the most common cause of "almost right" floats.
3. If the value is signed, check whether the slave uses two's-complement 16-bit (range −32768 to +32767) or a sign-magnitude / sign-bit convention. The LOGO! VW interprets the raw register as a 16-bit signed integer.

5. Step-by-Step Configuration

5.1 Create the Modbus Client Connection in LOGO! Soft Comfort

1. Open the LSC project that is loaded into the target LOGO! 8.FS4.
2. Go to Tools → Ethernet → Create Modbus client connection (the menu may be labeled "Ethernet Connections" depending on the LSC service pack).
3. Configure the connection block:
   • Remote IP address: the IP of the Modbus TCP/IP slave.
   • Port: 502 (Modbus TCP/IP default).
   • Unit ID / Slave ID: the slave's Unit Identifier. Confirm with the slave's documentation; 1 is the most common default, 255 is a broadcast/ignore value that some gateways interpret as "any".
   • Protocol: Modbus TCP (not Modbus UDP, even though LOGO! firmware 1.82.x also supports UDP clients).
   • Polling interval / timeout: a 1000–2000 ms cycle is the typical starting point. Sub-100 ms cycles can starve the LWE web server and produce erratic page refreshes.
4. Save the project and transfer it to the LOGO! 8 base module.

5.2 Configure the Variable Memory (VM) Mapping

1. In the same LSC project, go to Tools → Parameter VM Mapping.
2. For every Modbus holding register that LWE must read, add a row that reads address N from the Modbus client connection and writes the result into VM address V.
3. Select the correct data width for each row:
   • One 16-bit holding register → map into a single VW in VM (e.g. VW100 for the setpoint).
   • Two 16-bit registers forming one 32-bit float → map into a single VD (e.g. VD102 for the process value).
4. Record the VM addresses you used. LWE will reference exactly these addresses in its Tag Table.

Example VM mapping for the setpoint + actual value scenario:

5.3 Declare the Tags in LOGO! Web Editor

1. Open the LWE v1.1.0 project that ships with the LSC project (LSC → Tools → LOGO! Web Editor).
2. Open Global Configuration → Tag Table.
3. Add a new tag for each VM word:
   • Name: a meaningful, project-wide identifier such as Setpoint_SP or ProcessValue_PV.
   • Type: VW (16-bit signed integer) for the 16-bit registers; VD for the 32-bit ones.
   • VM Address: the exact VM address you used in step 5.2 (e.g. 100, 102). Address values are decimal in LWE.
   • Access: Read for displays, Read/Write for the slider that writes the setpoint back to the slave.
4. Drop a numeric widget, gauge, or slider on the LWE page and bind it to the tag by name.
5. Generate the web project and download it to the LOGO! 8 base module.

6. Address Numbering: 0-Based vs 1-Based

Modbus is consistently 0-based in its Protocol Data Unit (PDU): register address 0 in FC 3 reads the first holding register on the wire. Many HMIs and SCADA packages expose a 1-based view to users, which is exactly where the off-by-one confusion in the source thread comes from. The direct quote from the commissioning thread:

With the LOGO! the register addresses start with 1, not with 0. If they start at 0, you have to go to LOGO! then use HR4 instead of HR3 and then HR2 instead of HR1.

A second confirmation from the same thread: I'm reading address 1 instead, on LOGO! it gets the same data on address 2. That is a 0-based slave being addressed as if it were 1-based — register 1 on the slave (PDU address 0) is appearing at LOGO! HR2.

Decision path when the slave's documentation is ambiguous about the base address:

1. If the slave documents its registers as "Register 1" / "Addr 1" and a third-party Modbus master reading register 1 returns the expected value, treat the slave as 0-based and enter HR2 in the LOGO!.
2. If the slave documents its registers as "Register 0" / "Offset 0", enter HR1 in the LOGO!.
3. When in doubt, force a known value (e.g. write 12345 to register 0 with modpoll) and probe HR1, then HR2, then HR3 in the LOGO! VM mapping until the value appears. This is the empirical "find the offset" workflow that resolves the ambiguity in seconds.

7. Connection Tuning: Unit ID, Polling, and Timeouts

Three connection parameters control whether a single read succeeds or silently fails. Tuning them is the single biggest factor in field reliability.

For a deeper protocol primer — function codes, exception codes, and gateway behavior — the ProSoft Modbus and Modbus TCP/IP FAQ is a useful consolidated reference.

8. Handling Missing Registers and Modbus Exceptions

The reported behavior — adding a non-existent register to the VM mapping and losing visibility of every other valid register — is a known characteristic of the LOGO! 8.FS4 Modbus client. The client groups the requested registers into a single FC 3 transaction; if the slave returns a Modbus exception, the LOGO! discards the entire transaction rather than committing the partial values it did receive.

Mitigations, in order of preference:

1. Group valid addresses contiguously. Build one FC 3 request that covers the live registers in a single contiguous block, and a separate FC 3 request for the optional / diagnostic registers, so a missing address only fails its own block.
2. Pre-validate the slave's register map. Use a generic Modbus master (modpoll, mbpoll, any SCADA's Modbus driver tester) to scan the address space before commissioning. Record the actual valid range and use only that range in the LSC VM mapping.
3. Insert a Modbus gateway with a validity map. A gateway such as the Advantech EKI-1200 series can be configured to pre-screen requests and present the LOGO! with a clean, exception-free register space.
4. Bound the polling rate. Keep the LWE polling interval ≥ 1 s. The LOGO! 8.FS4 web server and the Modbus client share the same Ethernet stack and the same CPU; a runaway poll rate can starve one or both.

8.1 Modbus Exception Codes You Will See in Wireshark

When a read fails on the wire, the slave replies with an exception function code (FC | 0x80) and a sub-code. Knowing the sub-code saves a Wireshark session.

9. Diagnostics, Exception Codes, and Round-Trip Writes

There is no per-tag Modbus health LED inside the LWE page itself. The available debug surfaces, from cheapest to most authoritative:

• LOGO! display / TDE: the base module's on-screen status shows the Ethernet connection state, the assigned IP, and a connection error code if the Modbus client cannot reach the slave.
• LOGO! Soft Comfort online mode: the online view of the VM area lets you watch the fetched values in real time, independent of LWE. If the VM area is updating correctly and LWE shows stale data, the bug is in the LWE tag binding, not the Modbus link.
• Slave-side counters: a Modbus slave with diagnostics (most modern VFDs, energy meters, and PLCs) will show incremented "valid request" / "exception" counters — use these to confirm the LOGO! is actually talking to it.
• Network capture: Wireshark on the slave's switch port with the Modbus/TCP dissector enabled is the most authoritative tool. Confirm unit ID, function code, address range, response time, and exception responses from a single capture.

9.1 Putting a Value Back: Writing a Setpoint from the Slider

A slider in LWE v1.1.0 can be configured as Read/Write. The write side ends up at the same VM address declared in the Tag Table, but to actually reach the slave the VM area must be re-published to the Modbus client — done in LSC by adding the VM address to the Modbus client connection's write list (FC 6 for a single register, FC 16 for multiple). The complete round-trip is:

Without the FC 6 / FC 16 write registration in the LSC project, the slider's value sits in VM but never reaches the slave, and the operator sees a "dead" control. Always confirm the slave register is actually being written by reading it back with a third-party tool, and check the slave's "valid write" counter if it exposes one.

10. Verification Checklist and Troubleshooting Matrix

11. Frequently Asked Questions