Resolving Siemens LOGO! Modbus Server Port 502, VW Register Overlap, and Network Project Binding Issues

Siemens LOGO! logic modules from the 0BA8 generation onward expose a Modbus TCP server on the on-board Ethernet interface. The implementation behaves differently from a generic Modbus gateway: the server publishes the LOGO! variable memory map (V area) directly, and the address space is configured in the LOGO! settings → Modbus address space dialog. Engineers who migrate from a generic Modbus device often see three categories of symptom: (1) the server answers on a non-standard port rather than TCP/502, (2) words written to one address (for example VW0) appear to bleed into the next address (VW1) when polled by an external client, and (3) network project mode appears to lock the LOGO! to a single client IP. This reference documents the root causes, the configuration path that resolves them, and the verification checks that confirm a working Modbus TCP server.

1. Modbus TCP Server on Siemens LOGO! 8

The LOGO! 8 BM base module includes an Ethernet interface labeled Ethernet on the front face. From firmware version FS:04 (released in the LOGO! 8.3 hardware revision), the on-board Ethernet port supports both Modbus TCP client and Modbus TCP server roles simultaneously, with up to eight concurrent server connections in the network project editor of LOGO!Soft Comfort (LSC) V8.3 and later.

The server publishes the LOGO! variable memory area. By default the server exposes the standard Modbus holding registers starting at address 0, mapping them onto the LOGO! VW memory in ascending order. The exact start offset and the size of the addressable area are configured in LOGO! → Settings → Modbus Address Space in LSC. Function codes supported are:

According to the Modbus Organization specification, the well-known TCP port for a Modbus server is 502. A compliant client will always issue its first request to TCP/502. If a LOGO! server answers on a different port (such as 504, 505, 506…), a standard client will not find it.

2. Why the LOGO! Answers on a Non-Standard Port (504, 505, …)

When a server connection is added to the second or third connector slot of the network project, LSC assigns a free local port from a high-numbered range (typically 504 and up). This is the expected behavior: in network project mode only the first server connection that is bound to the on-board Ethernet interface is granted the standard port 502. Subsequent server connections must use a non-standard port because the LOGO! operating system cannot bind multiple servers to the same port number on the same IP address.

Three failure modes produce the “port 502 will not respond” symptom:

1. A client is already bound to connector 1. If a Modbus client is dragged to the first connector before a server is created, the slot is occupied and the server falls to the next free slot, which receives 504.
2. The server was added by right-clicking a port after a connection existed. Right-click → Add server connection on a port that already has a connection can re-bind the slot in unexpected ways. Always start with an empty network project for diagnosis.
3. The server is configured on a non-Ethernet interface. If the network project references a CMK2000 communication module or the AS-i bus, port 502 is not offered at all because the AS-i/CMK module does not implement the full Modbus TCP stack.

3. Diagram Mode vs Network Project Mode

LOGO!Soft Comfort offers two programming environments for communication projects:

Diagram mode is recommended for the first commissioning of any Modbus server problem. The reason is mechanical: in diagram mode there is exactly one server slot, and the local port is hard-coded to 502. Once a single server answers on 502 in diagram mode, the same project converted to network mode will keep port 502 for the first server slot. If a fresh network project fails on 502, the problem is project-state related (for example, a stale LSC cache or an unsupported element left over from a previous build). Delete the .lsc project, rebuild it from scratch, and add the server as the first action.

4. The VW0 / VW1 Byte-Overlap Problem

The most common data-integrity complaint when polling a LOGO! server is: “VW0 and VW1 read back the same value in the LSC data table, but on Modbus the values are slightly offset.” The root cause is the byte-overlap of the LOGO! 16-bit word addressing.

LOGO! V-memory is byte-addressable, and a word (VW) consumes two bytes. The mapping in the 0BA8 firmware is:

Each successive word overlaps the previous one by a single byte. The overlap is unusual when compared to most Modbus servers, which expose non-overlapping 16-bit words (VW0 = bytes 0/1, VW1 = bytes 2/3, …). The sequence has two practical consequences:

1. Writing VW0 then VW1 in two separate Modbus requests causes byte 1 to be overwritten twice. If the client writes 0x1234 to VW0 and then 0x5678 to VW1, the byte at VB1 takes the high byte of VW0 first and the low byte of VW1 second. The final value in VW0 will be 0x1256, not 0x1234. The “slight offset” that engineers see in the polled data is the residual of this double-write.
2. A read of VW0 immediately after writing VW1 returns the wrong value. This is the exact symptom reported in the field: the data table in LSC shows the correct program value, but a Modbus poll returns a value that has been corrupted by the overlap.

Two workarounds are field-proven. The first is to use even-indexed words only (VW0, VW2, VW4, …). Because each even-indexed word shares its high byte with the next even word’s low byte, the overlap still exists, but if the client always writes in pairs (for example, a function code 0x10 multiple-write covering VW0 and VW1 in one transaction), the Modbus gateway writes the buffer atomically and the client receives a consistent snapshot. The second, more robust workaround is to use non-overlapping words by reserving the high bytes. Address the LOGO! at VW0, VW2, VW4, … with a stride of two, and treat the in-between odd words as scratch. The Modbus client should never write to an odd-indexed word.

5. Why the Data Transfer Table Does Nothing in Server Mode

The network project editor of LSC exposes a Data Transfer Table tab on every server and client block. In client mode the table is mandatory: each row defines a remote register, a local VM address, a function code, and a trigger condition. In server mode the table is present but inert. The reason is architectural: a Modbus server does not “transfer” data, it exposes data. The mapping is implicit and is defined globally in LOGO! settings → Modbus Address Space.

Three rules follow from this:

• Server blocks do not require a data transfer table to function. An empty server block will still respond to function codes 0x03, 0x06, and 0x10 against the published address space.
• The address space in LOGO! settings → Modbus address space is the only thing that determines what the client sees. If a client requests a register outside the published range, the server replies with the standard Modbus exception 0x02 (Illegal Data Address).
• The data transfer table on a server block is preserved across firmware upgrades for backward compatibility, but a future LSC version may remove it from the server block UI. Treat it as read-only / informational in server mode.

6. IP Access Control Through the Network Project Drawing Direction

When a Modbus device is added to the network project and a connection is dragged from the device to a free port on the LOGO!, LSC records a binding: the LOGO! server will only accept Modbus requests that originate from the device’s IP address. This is enforced by the LOGO! operating system and cannot be overridden by an external firewall rule on the LOGO! itself.

Conversely, when the connection is created by right-clicking the LOGO! port and choosing Add server connection, the resulting server block is open to requests from any IP address that can reach the Ethernet interface. The difference is intentional and undocumented in older LSC help files: the “drag from device” gesture generates a peer-bound server with an embedded IP allow-list; the “right-click add server” gesture generates an open server.

Engineers who see “the LOGO! stops responding after I added a Modbus device by drag-and-drop” are usually seeing this filter activate silently. The fix is to delete the dragged connection and recreate the server with the right-click method, or to set the device’s IP in the LSC project to the static IP of the real Modbus client before downloading the project.

7. Drag Direction Defines Server vs Client Role

The direction of the drag gesture in the network project determines which side is the server and which is the client. This is the same convention used for S7 PUT/GET connections in LSC.

• Drag from external device → LOGO! port: the LOGO! becomes the server. The external device is the client. The LOGO! accepts requests.
• Drag from LOGO! port → external device: the LOGO! becomes the client. The external device must be the server. The LOGO! initiates polls at the cycle interval defined in the data transfer table.

The direction is also the only signal LSC uses to decide whether to draw a server block or a client block in the network diagram. There is no “role” property on a generic connection. If the LOGO! ends up as a client when you need it to be a server (or vice versa), delete the connection, click the source end first this time, and re-drag.

8. Step-by-Step: Build a Working Modbus TCP Server on LOGO! 8

1. Open LSC, create a new project. Pick File → New → Network Project. Do not start from a converted diagram project for the first build.
2. Set the LOGO! IP address. In LOGO! → Settings → Ethernet, assign a static IP, subnet, and gateway. The default out-of-the-box is 192.168.0.10 / 255.255.255.0.
3. Configure the Modbus address space. In LOGO! → Settings → Modbus Address Space, enable the server, set the start register, and reserve at least 32 words of VM. The default is offset 0, length 32.
4. Right-click the LOGO! Ethernet port and choose Add server connection. Verify the dialog shows Local port 502. If it shows 504, the port is already taken by another server in the project; remove that server and re-add.
5. Drag a connection from the LOGO! server block to a network analog input or output block on the LOGO! function diagram. The server is now wired into the program.
6. Wire a value into the network analog input/output block on a non-overlapping even VW address (for example VW0, VW2, VW4). Avoid VW1, VW3, … unless paired with the previous even word in a single multi-write transaction.
7. Download the project to the LOGO! and go online. The data table in LSC should show the live value of VW0 (and the unused VW1, if the address space is sized accordingly).
8. From a separate PC on the same subnet, run mbpoll -m tcp -a 0 -r 1 -c 4 192.168.0.10. This polls the LOGO! server on TCP/502, reads four holding registers starting at offset 0. Expect four 16-bit words returned in big-endian (network byte order). The first word should match the LSC data table exactly.

9. Verification and Commissioning Checks

After download, run the following sequence. Any failure isolates one of the issues above.

10. Troubleshooting Matrix

11. Firmware and Compatibility Notes

The 0BA8 hardware revision introduced Modbus TCP client and server. The 0BA8.FS04 firmware revision (released alongside LOGO! 8.3 hardware, part numbers ending in 0BA8.FS04) is the first version in which both client and server can be active in network project mode on the same LOGO!. Earlier FS:01 / FS:02 / FS:03 firmware may require the LOGO! 8.2 base module and supports either client or server, not both concurrently. If the symptoms appear after a firmware upgrade, verify the part number on the side label of the BM module against the firmware version in LOGO! → Online → Diagnostics.

LOGO!Soft Comfort V8.3 (and V8.4 as of this writing) is required to program the 0BA8.FS04 module. Older LSC versions (V8.0, V8.1, V8.2) will open the project but will refuse to write to the new firmware or will silently drop the server block on download.

12. Security and Hardening Checklist

Modbus TCP on the LOGO! has no built-in authentication. Treat the server as a read/write interface to the live I/O and apply the same controls you would apply to any other unmanaged industrial protocol:

• Network segmentation. Place the LOGO! on a dedicated VLAN or subnet that does not carry office or external traffic.
• MAC / IP allow-list on the switch port. Most managed industrial switches support port security. Limit the LOGO! port to the MAC of the authorized client and the authorized Modbus server (if any).
• Use the right-click “Add server” method instead of drag-from-device only when multiple clients are required. The drag-from-device method gives you an implicit allow-list of one IP, which is more secure for a single trusted client.
• Disable unused Ethernet services. The on-board Ethernet port also runs the S7 PUT/GET server and the webserver. Disable both if the LOGO! is exposed only to a Modbus client.
• Log every write transaction. LOGO! 8 does not log writes, but a Modbus gateway or a smart client (for example, Modbus Tools on Windows or mbpoll on Linux) can capture the full transaction history to a CSV for audit.