Why won't an S7-1200 String read in SCADA at DB138.DBX0.0?

An S7-1200 String declared in DB138 appears in TIA Portal as P#DB138.DBX0.0. The SCADA accepts only DB138.DBX0.0, and the text typed on the SCADA screen for a recipe never shows up in the PLC. Three things cause this, and all three must be right before the string transfers:

• The DB must use absolute offsets.
• The CPU must allow remote S7 read/write access.
• The SCADA tag must match the Siemens string byte layout, including its two header bytes.

Configure them in the order below. Confirm each check before you move to the next.

S7 String Byte Layout in DB138

A Siemens S7 String is a byte structure, not a bare character array.

• Byte n holds the maximum length.
• Byte n+1 holds the current length, meaning the number of valid characters.
• Bytes n+2 onward hold the characters.

A String declared without a length defaults to 254 characters, so it occupies 256 bytes. A String[20] occupies 22 bytes.

P#DB138.DBX0.0 is pointer notation. The P# prefix marks the start of a memory area, not a scalar tag address. Removing P# gives DB138.DBX0.0, which points at the same first byte. That byte is the maximum-length header, not the first character. A SCADA tag at DB138.DBX0.0 configured as plain characters therefore reads the header values as text: usually a non-printable byte followed by the length byte.

For the rest of this procedure, assume one String[20] named for the recipe at the start of DB138:

DB138.DBB0        max length      (20 for String[20], 254 for default String)
DB138.DBB1        current length  (0..20)
DB138.DBB2..DBB21 characters      (ASCII, one byte each)
DB138.DBB22       next DB member starts here

Check: after the next section, the DB editor Offset column shows 0.0 for the string and 22.0 for the member that follows. A String[20] that ends anywhere else means the declaration differs from what the SCADA will be configured to expect.

Standard (Non-Optimized) Access on DB138

Optimized block access lets the CPU arrange DB members internally for speed. An optimized DB has no fixed byte offsets and can only be reached symbolically. Third-party SCADA drivers that use the S7 protocol address data by absolute DB number and byte offset, so the DB must be a standard (non-optimized) block.

1. In the project tree, right-click DB138 and open Properties, then Attributes.
2. Clear Optimized block access.
3. Compile the DB. Recompile any blocks that call it.
4. Download to the CPU. The DB layout changed, so TIA Portal reinitializes DB138. Back up any recipe values stored there before you download.

Check: the DB editor now shows an Offset column. The string member shows 0.0. If the Offset column is missing, the attribute change did not compile, or you edited a different instance of the DB.

PUT/GET Permission on the S7-1200 CPU

PUT/GET is the S7 communication service a remote client uses to read and write CPU memory by absolute address. Current S7-1200 CPUs ship with PUT/GET access disabled. With it disabled, a third-party SCADA either fails to connect or connects and returns errors on every DB read.

1. Open Device configuration and select the CPU.
2. In Properties, open Protection. Newer TIA Portal versions call this Protection & Security, with the option under Connection mechanisms.
3. Enable Permit access with PUT/GET communication from remote partner.
4. Compile the hardware configuration and download it to the CPU.

Enabling PUT/GET opens every non-optimized DB to anyone on the network who can reach the CPU. Restrict access at the network level. Do not treat the checkbox as a security control.

Check: configure a test tag in the SCADA as an unsigned byte at DB138.DBB0. With a String[20], it reads 20. With a default String, it reads 254. Any other value means the SCADA is reading a different DB, a different offset, or a stale layout.

Mapping the SCADA Tag to the String Header

SCADA drivers handle Siemens strings in one of two ways. Read the string data types in your driver's address syntax help, then choose the matching row.

A generic string tag placed at DB138.DBX0.0 is the most common misconfiguration. It displays the header bytes as garbage and shifts every character by two positions.

Check: in a TIA Portal watch table, write 'ABC' to the string in the PLC. The SCADA shows ABC with no leading symbols and no trailing characters.

Writing Recipe Strings from the SCADA Screen

This direction causes the reported symptom. The PLC evaluates a String using only the current-length byte. A header-unaware driver writes characters into bytes 2 onward but leaves byte 1 unchanged. The characters then sit in memory, while the PLC string reads as empty or truncated to the old length.

1. With a native S7 STRING type, write the whole string tag at DB138.DBB0. Confirm in the driver documentation that writes preserve byte 0.
2. With a generic string type, also create an unsigned byte tag at DB138.DBB1. Have the SCADA script write the entered text length to it in the same operation as the characters.
3. Never map a writable tag over DB138.DBB0 with a generic type. Writing 0 or a character code into the max-length byte corrupts the string for every PLC instruction that uses it.
4. Keep entered text at or below the declared length. For a String[20], text longer than 20 characters overruns into DB138.DBB22 and the next member.

Check: enter TEST01 on the SCADA screen. In the watch table, DB138.DBB1 reads 6 and the string monitors as 'TEST01'.

End-to-End String Round Trip

1. Read CPU Protection settings. Expected: PUT/GET access enabled and downloaded.
2. Open DB138 Attributes. Expected: Optimized block access cleared, and the Offset column shows the string at 0.0.
3. Read SCADA byte tag DB138.DBB0. Expected: declared max length (20 in this example).
4. Write 'PLC' from the watch table. Expected: SCADA shows PLC and DB138.DBB1 reads 3.
5. Write 'RECIPE7' from the SCADA screen. Expected: watch table shows 'RECIPE7', DB138.DBB1 = 7, and DB138.DBB0 still reads the declared max length.
6. Write a shorter value, 'R2', from the SCADA. Expected: PLC string reads 'R2' with no leftover characters from RECIPE7, and DB138.DBB1 = 2.

FAQ