S7-1200 SCL: Constructing ANY Pointers for Communication Blocks

Overview: Why Dynamic ANY Pointers Are Needed in S7-1200

Communication function blocks on the S7-1200 family (MB_CLIENT, MB_SERVER, PUT, GET, TSEND, TRCV, USEND, URCV, the legacy Modbus RTU library, and the PtP library) accept the source or destination address of the payload through an ANY pointer input. A static literal such as P#DB300.DBX0.0 WORD 2 is straightforward: the pointer is fixed at compile time and the FB always writes the two words to DB300 bytes 0-3.

The moment the destination DB number, the byte offset, or the repetition count must be computed at runtime (for example: a recipe selects DB 305, or a recipe index of 5 means "skip 5*4 bytes ahead"), the engineer has to build the ANY pointer in code. Doing this in SCL on an S7-1200 is not the same as doing it in STL on an S7-300. TIA Portal hides the byte layout of the ANY from the programmer, and the most common symptom is a correct-looking monitor value of P#0.0 VOID 0 even though ten bytes of data were moved into a holding DB. This article gives the exact byte layout, the AT-view technique that works, and the runtime verification steps.

The 16-Byte ANY Pointer Layout (S7-1200 / S7-1500)

The S7-1200 inherits the S7-1500 ANY format. It is exactly 16 bytes long, although the first 10 bytes are the only ones the legacy communication FBs actually consume. Bytes 10-15 are reserved for VARIANT extensions and must be zero unless the field is forwarded to a block expecting a VARIANT.

The byte/bit offset encoding is the single most common source of bugs. The 24-bit field is laid out as: high-to-low: byte_offset[20:0] (21 bits) | bit_offset[2:0] (3 bits). A pointer at DBX14.3 encodes as 16#00000073 in little-endian: 14*8 + 3 = 115 = 0x73. For DBX0.0 the field is 16#00000000.

Data Type and Memory Area Code Reference

Prerequisites and Tool Versions

1. CPU firmware V4.2 or higher (S7-1200). SCL AT view over a byte array is supported in TIA Portal V13+.
2. DB DB500_AnyBuild with optimized block access OFF. Optimized DBs hide the absolute byte offset; the AT view technique requires the underlying byte ordering to be predictable. (If optimized access is required, the same AT technique still works because the 16 bytes are contiguous, but wDB must be set explicitly because TIA Portal no longer auto-fills it from the DB number.)
3. Two data types in a global PLC data type (UDT) library: tAnyView for the 16-byte header and tAnyViewLegacy for the 10-byte form (optional, only for S7-300/400 compatibility).
4. Inputs you want to vary: an INT index, a WORD for the element count, and a WORD for the DB number.

Method 1 — AT View Over a Static DB (DB500 Approach)

Step 1 — Declare the holder DB and the AT view

// Global PLC data type "tAnyView" (DUT)
TYPE tAnyView :
STRUCT
    bSyntaxID      : BYTE;    // 16#10
    bInternalUse   : BYTE;    // 16#00
    wDataType      : WORD;    // 16#0004 = WORD
    wCount         : WORD;    // 2
    wDB            : WORD;    // 300
    bArea          : BYTE;    // 16#84 = DB
    dwOffset       : DWORD;   // byte[9..11] + bit in low 3 bits of high byte
    abReserved     : ARRAY[0..5] OF BYTE;  // 16#00
END_STRUCT;
END_TYPE

Step 2 — Build the holder in DB500

DATA_BLOCK "DB500_AnyBuild"
{ S7_Optimized_Access := 'FALSE' }
STRUCT
    abAny : ARRAY[0..15] OF BYTE;   // raw 16 bytes
END_STRUCT;
BEGIN
END_DATA_BLOCK

Step 3 — Fill the bytes at runtime

// Inside an FC or FB written in SCL
"DB500_AnyBuild".abAny[0]  := 16#10;            // syntax ID
"DB500_AnyBuild".abAny[1]  := 16#00;            // internal use
"DB500_AnyBuild".abAny[2]  := 16#04;            // WORD low byte
"DB500_AnyBuild".abAny[3]  := 16#00;            // WORD high byte
"DB500_AnyBuild".abAny[4]  := 2;                // count low byte
"DB500_AnyBuild".abAny[5]  := 0;                // count high byte
"DB500_AnyBuild".abAny[6]  := 300 MOD 256;      // DB low byte
"DB500_AnyBuild".abAny[7]  := 300 / 256;        // DB high byte
"DB500_AnyBuild".abAny[8]  := 16#84;            // DB area
"DB500_AnyBuild".abAny[9]  := 0;                // offset low byte
"DB500_AnyBuild".abAny[10] := 0;                // offset mid byte
"DB500_AnyBuild".abAny[11] := 0;                // offset high byte (bit offset 0)
"DB500_AnyBuild".abAny[12] := 0;
"DB500_AnyBuild".abAny[13] := 0;
"DB500_AnyBuild".abAny[14] := 0;
"DB500_AnyBuild".abAny[15] := 0;

Step 4 — Pass it to the FB

Connect "DB500_AnyBuild".abAny to the ANY input of the FB. The compiler treats a 16-byte array as a valid ANY at the parameter boundary. Do not pass the DB number as an input parameter; the FB reads the destination from the 16 bytes themselves.

Method 2 — Temp ANY in FC, Static ANY in FB (Recommended)

The recommended approach is to keep the ANY inside the block instance, then write each byte of the static ANY before the FB is called. This is the approach Siemens uses in its scalable Modbus sample for S7-1500, which the discussion linked. For S7-1200 it works identically when the project is created with the appropriate CPU.

FB-based implementation

FUNCTION_BLOCK "fbModbusScaler"
VAR
    abAny : ARRAY[0..15] OF BYTE;          // holder inside instance DB
    sAny  AT abAny : tAnyView;             // structured overlay
    iIndex : INT;                          // runtime input
    wDbNum : WORD;                         // runtime DB selector
END_VAR
BEGIN
    // Build the ANY header once per cycle
    sAny.bSyntaxID    := 16#10;
    sAny.bInternalUse := 16#00;
    sAny.wDataType    := 16#0004;          // WORD
    sAny.wCount       := 2;                // 2 words = 4 bytes
    sAny.wDB          := wDbNum;
    sAny.bArea        := 16#84;

    // dwOffset encodes byte_offset * 8 + bit_offset (low 3 bits)
    // For byte-only offsets, bit_offset = 0
    sAny.dwOffset     := DWORD#0;
    sAny.abReserved[0] := 16#00;
    sAny.abReserved[1] := 16#00;
    sAny.abReserved[2] := 16#00;
    sAny.abReserved[3] := 16#00;
    sAny.abReserved[4] := 16#00;
    sAny.abReserved[5] := 16#00;
END_FUNCTION_BLOCK

Then wire abAny (the byte array) to the ANY input of the communication FB. TIA Portal will accept it because both are 16 bytes long and the editor will display it as the pointer value the engineer constructed.

Why the Online View Shows P#0.0 VOID 0

When the user fills ten bytes in an instance DB and watches the value in TIA Portal's online monitor, TIA Portal reads the syntax ID, the type, the count, the DB number and the area, then displays the symbolic equivalent. If the syntax ID is not 16#10 or the data type is 16#00 (VOID), the editor falls back to P#0.0 VOID 0. The pointer itself is still in memory; the editor simply cannot interpret it.

Two common reasons this happens in practice:

1. Byte order of WORD fields. The PLC stores WORD values little-endian. The value 16#0004 for the type field WORD must be laid down as abAny[2] = 16#04 and abAny[3] = 16#00. Writing 16#0004 into a WORD variable and then a byte-by-byte move in the wrong order produces abAny[2] = 16#00, abAny[3] = 16#04, which the editor then reads as 16#0400 = 1024, an invalid type code.
2. The bSyntaxID is not exactly 16#10. Some sample code uses 10 (decimal), which is also 16#0A, the data type for SINT. The editor then assumes the rest of the field is a SINT array and renders it as such, hiding the real bytes.

Dynamic Offset Calculation from an INT Index

The original question asked how to convert an input of 5 (INT) into a pointer that points either at P#DB300.DBX0.0 WORD 7 or at P#DB305.DBX0.0 WORD 2. Two scaling strategies are common in real applications:

Strategy A — Index selects the DB number

The DB number is recomputed from a base plus the index, the offset and count stay constant. Useful when each device / slave / record lives in its own DB.

sAny.wDB := WORD#300 + WORD#(iIndex);
sAny.dwOffset := DWORD#0;          // start at byte 0, bit 0
sAny.wCount := 2;                  // unchanged

Strategy B — Index selects the byte offset (record inside a single DB)

All records live in one large DB; the index multiplies the record size. For a record of 2 words (4 bytes), index 5 means offset 20 bytes. For 7 words (14 bytes) per record, index 5 means offset 70 bytes.

VAR CONSTANT
    cRecordSizeBytes : INT := 14;  // 7 words = 14 bytes
END_VAR

sAny.wDB := 300;                   // base DB
sAny.dwOffset := DWORD#(INT#0 + iIndex * cRecordSizeBytes);
sAny.wCount := 2;                  // still 2 words of payload

Bit offset for BOOLEAN targets

If the payload is a BOOL rather than a WORD, the bit offset must be encoded into the low 3 bits of dwOffset:

// Index a single BOOL by iIndex 0..7, byte offset 0, DB 300
sAny.wDataType := 16#01;          // BOOL
sAny.wCount    := 1;
sAny.wDB       := 300;
sAny.bArea     := 16#84;
sAny.dwOffset  := SHL_DWORD(DWORD#0, 3)   // bit offset goes in low 3 bits
                OR SHL_DWORD(DWORD#(iIndex AND 16#07), 0);
// Note: iIndex up to 7 stays in the same byte; higher indices need
// a different layout: byte_offset = iIndex / 8, bit_offset = iIndex MOD 8

Wiring the Constructed ANY to MB_CLIENT / MB_SERVER

The Modbus RTU FBs in the S7-1200 Modbus RTU library take the source/destination as the input DATA_PTR of type VARIANT. A VARIANT in S7-1500/1200 is internally a 16-byte ANY with the extensions populated. As long as bytes 0-11 are filled correctly and the area code is 16#84, the FB will accept the pointer and write the payload to the chosen DB and offset.

Steps for an MB_CLIENT that reads 4 holding registers and stores them at a dynamic offset:

1. Build the ANY as in Method 2 above with wDataType = 16#05 (INT) and wCount = 4.
2. Connect abAny to MB_CLIENT.DATA_PTR.
3. Trigger MB_CLIENT with a single-shot REQ edge. Polling rate should be ≥ 50 ms on a serial CM 1241 to avoid RS-485 bus contention.
4. Read MB_CLIENT.DONE, MB_CLIENT.ERROR, and MB_CLIENT.STATUS (Word) to confirm.

The Siemens Modbus library also provides a scalable Modbus example for S7-1500 which uses the same construction. The example program Modbus_RTU_Scalable works on S7-1200 with the MB_CLIENT and MB_SERVER blocks after changing the CPU device in the project; no other modifications are required for the pointer construction itself.

Common Pitfalls, Error Codes, and Troubleshooting

Verification and Online Testing Procedure

1. Open the holder DB or instance DB in TIA Portal and switch to Monitor/Modify > Monitor all.
2. Force the index iIndex to a known value (e.g. 5) and the DB number to a DB that has been preloaded with a recognizable pattern (e.g. DB300 bytes 0-3 = 16#1111).
3. Confirm the online view of the holder now shows the constructed pointer, e.g. P#DB300.DBX20.0 WORD 2 if the record size is 4 bytes and the index is 5.
4. Trigger the communication FB. After DONE goes high, inspect the target DB at the calculated offset. The payload should have been written there, not into the holder.
5. Repeat with index = 0, 1, 2, ... N-1 to confirm the offset formula.
6. For an MB_CLIENT that reads, also confirm the slave's response was actually correct by reading the same register with a different tool (Modbus Poll, a HMI tag with polling).
7. Reset the input iIndex to -1 (sentinel) when out of range and zero the bytes of the ANY; the FB will then return STATUS = 16#80B1 "Invalid pointer".

FAQ