Configuring Baumer VeriSens PROFINET Result Data on S7-1200

Configuring Baumer VeriEns PROFINET Result Data on a Siemens S7-1200 in TIA Portal

Baumer VeriSens vision sensors (XC, XF, CS, and ID series) expose their inspection results to a Siemens S7-1200 controller through PROFINET using a compact binary telegram. Because the camera ships with a GSD file but no pre-built TIA Portal function blocks, the integrator must build the entire result-data path by hand: install the GSD, configure the input slot addresses, design a UDT that matches the camera's telegram layout, and copy the PROFINET input area into a data block with MOVE_BLK / BLKMOV. This article walks through that process for a 35-byte input slot (I68 to I102), explains how to interpret the two-byte length field that precedes the result payload, and shows how to convert a 10-character QR code string such as PAC1234567 into a usable PLC variable.

1. Integration Architecture

The VeriSens camera acts as a PROFINET IO Device. The S7-1200 (any CPU with PROFINET support, e.g. CPU 1214C DC/DC/DC, firmware ≥ 4.2) acts as the IO Controller. Each inspection cycle triggered by the PLC produces one result telegram delivered as a contiguous byte block in the PROFINET input image. Telegram size is set in the VeriSens web UI under PROFINET → Result Data Length; valid values are multiples of 2: 4, 8, 16, 32, 64, 128, or 250 bytes.

2. Prerequisites

• CPU firmware: S7-1200 with firmware 4.2 or higher for reliable large I/O slot handling. Earlier 4.0/4.1 firmwares limit input slot sizes.
• TIA Portal version: V16 or higher. V17 is recommended for full MOVE_BLK variant support and the new BLKMMOV_ANY block.
• VeriSens firmware: XC-200/XF-800 with firmware 3.x or later. Older XC-100 firmware uses a different byte order.
• GSD file: Download the matching GSDML from Baumer VeriSens downloads. The file name follows the pattern GSDML-V2.31-Baumer-VeriSens-xxxxxxx.xml.
• Web configuration of the camera: PROFINET device name, IP address, station name, and the Result Data Length parameter must already be set via the VeriSens web UI. The web UI is reachable at the camera's IP address on port 80.
• Static IP subnet for both PLC and camera; PROFINET does not tolerate DHCP.

3. VeriSens PROFINET Telegram Layout

The result telegram delivered by VeriSens is a fixed-header + variable-payload structure. The exact byte offsets depend on the slot configuration you select when adding the VeriSens GSD module in TIA Portal. The two most common layouts are:

For a 35-byte input slot starting at IB68, the offsets map as follows:

* The configured slot is 35 bytes wide (I68 to I102 inclusive), giving 4 header bytes plus 31 payload bytes. The VeriSens itself reports a maximum useful payload of 31 bytes for a 32-byte result length setting because two bytes of the input slot are absorbed by the length field.

4. Installing the GSD and Configuring the Input Slot

1. In TIA Portal open Options → Manage general station description files (GSD).
2. Browse to the downloaded GSDML file and install. The VeriSens device will appear under Other field devices → PROFINET IO → Sensors → Baumer.
3. Drag the VeriSens onto the PROFINET subnet and assign the IO Controller (your S7-1200).
4. Set the device name to match the name configured in the VeriSens web UI. PROFINET DCP will only commission the camera if the names match exactly (case-sensitive).
5. In the device properties, expand Module list and select the slot that matches your result data length. For 32 bytes of result payload, choose the 32 Byte Result Data module. TIA will then auto-assign a 35-byte input slot.
6. Open Device view → Properties → I/O addresses and either accept the auto-assigned addresses or set them manually. For this article the start address is fixed at 68 so the input range is I68 – I102.

5. Defining a UDT for the Result Telegram

A User Defined Data Type (UDT) lets you address the telegram fields symbolically rather than by raw byte offset. Create a new UDT under PLC data types in the project tree:

TYPE "UDT_VeriSensTelegram"
VERSION : 0.1
   STRUCT
      JobResultID  : WORD;       // IW at base + 0, bytes 0..1
      ResultLength : WORD;       // IW at base + 2, bytes 2..3
      Payload      : ARRAY[0..30] OF BYTE;  // IB at base + 4 .. +34
   END_STRUCT;
END_TYPE

This UDT totals 35 bytes, which exactly matches the slot width. Now create a global DB (e.g. DB_VeriSens) with one tag of the new type:

DATA_BLOCK "DB_VeriSens"
VERSION : 0.1
   STRUCT
      Telegram : "UDT_VeriSensTelegram";
      QRCode   : STRING[20];     // output string after conversion
      Valid    : BOOL;           // 1-cycle flag: new result available
      Overflow : BOOL;           // 1 if ResultLength > 31
   END_STRUCT;
BEGIN
END_DATA_BLOCK

Symbolic access is now possible throughout the program:

• "DB_VeriSens".Telegram.JobResultID → equivalent to IW68
• "DB_VeriSens".Telegram.ResultLength → equivalent to IW70
• "DB_VeriSens".Telegram.Payload[0] → equivalent to IB72
• "DB_VeriSens".Telegram.Payload[30] → equivalent to IB102

6. Copying the Input Image with MOVE_BLK / BLKMOV

The S7-1200 PROFINET input image is updated each bus cycle (typically 1 ms with a 1 ms update time configured in TIA Portal). To make the telegram available symbolically and decouple it from the IO update timing, copy it into the data block using MOVE_BLK (SCL) or BLKMOV (LAD/FBD):

SCL example (OB1 or a dedicated OB):

// Full 35-byte telegram copy
MOVE_BLK(
    IN    := P#I68.0,
    COUNT := 35,
    OUT   => P#"DB_VeriSens".Telegram);

// Validate length
"DB_VeriSens".Overflow := ("DB_VeriSens".Telegram.ResultLength > 31);

LADDER example (single network):

      BLKMOV
        EN    := TRUE
        SRCBLK: P#I68.0 BYTE 35
        RET_VAL: MW200
        DSTBLK: P#DB10.DBX0.0 BYTE 35

7. Converting the Variable-Length QR Code Payload to STRING

A QR code containing PAC1234567 is 10 ASCII bytes, delivered as raw bytes in the payload array. Once you have the result length, conversion to STRING is a simple loop. Add the following SCL code in a cyclic OB (e.g. OB1 or OB35):

// Reset output string
"DB_VeriSens".QRCode := '';

// Guard: only run if length is sensible
IF ("DB_VeriSens".Telegram.ResultLength > 0)
   AND ("DB_VeriSens".Telegram.ResultLength <= 31)
   AND (NOT "DB_VeriSens".Overflow) THEN

    FOR #i := 0 TO INT_TO_UINT("DB_VeriSens".Telegram.ResultLength) - 1 DO
        "DB_VeriSens".QRCode := "DB_VeriSens".QRCode
                                + CHAR_TO_STRING("DB_VeriSens".Telegram.Payload[#i]);
    END_FOR;

    "DB_VeriSens".Valid := TRUE;
ELSE
    "DB_VeriSens".QRCode := '';
    "DB_VeriSens".Valid   := FALSE;
END_IF;

After one cycle, "DB_VeriSens".QRCode will contain the string 'PAC1234567' (length 10). The Valid flag is the rising-edge trigger for downstream consumers.

7.1 Why not just use DWORD for the result?

A common mistake is to assume a 10-character ASCII string fits in a DWORD. It does not – a DWORD is 4 bytes (max 4 ASCII characters). A 10-character string requires at least 10 contiguous bytes of payload and a STRING tag sized for the maximum expected length. Reserve a buffer of 32 bytes plus the STRING[32] header (2 bytes for max/current length) to match the maximum result data length setting of the camera.

8. Verifying the Telegram Capture Online

1. Download the project to the S7-1200 and go online.
2. Open Watch table and add "DB_VeriSens".Telegram.JobResultID, "DB_VeriSens".Telegram.ResultLength, and the first four payload bytes.
3. Trigger an inspection from the VeriSens web UI (or by toggling the trigger bit in the PROFINET output slot).
4. Observe the values:
   • JobResultID should match the inspection job number configured in the VeriSens Application Suite.
   • ResultLength should be non-zero and a multiple of 2 (4, 6, 8, 10, …) for ASCII payloads.
   • The payload bytes should match the characters of the QR code in ASCII (e.g. 50 41 43 31 32 33 34 35 36 37 for PAC1234567).
5. Add a trace on ResultLength over a few minutes to confirm it is stable for your application. If it varies per cycle, switch to a maximum-size UDT (e.g. Payload : ARRAY[0..248] OF BYTE;) and always read up to the live length.

9. Common Configuration Errors and Fixes

10. Field-Proven Caveats

• Endianness of the length field: VeriSens uses big-endian byte order in the length field. Reading IB70 and IB71 directly gives bytes in the wrong order for an INT. Always use WORD_TO_INT on the joined WORD, or rely on the compiler to combine the two bytes via the WORD declaration.
• Update time mismatch: If the VeriSens is configured with a 4 ms reduction ratio but the S7-1200 PROFINET update is 1 ms, the input image may contain stale data for three of every four cycles. Match the VeriSens send cycle to the PROFINET update time to avoid double-reading the same result.
• Watchdog / life-sign: Configure a watchdog time of at least 3 × the PROFINET update time. With a 1 ms update time, a 3 ms watchdog is the safe minimum; many integrators use 6 ms to allow for jitter on busy CPUs.
• Multiple inspection jobs: If the VeriSens runs more than one inspection job, the result telegram is delivered sequentially – one job per cycle. Use the JobResultID field to demultiplex the data into per-job data blocks.
• String null terminator: VeriSens does not append a null terminator. Convert by length, not by scanning for 0x00.
• Buffer overflow guard: Always check ResultLength <= ARRAY_SIZE before the conversion loop to prevent writing past the buffer if the camera is reconfigured to a larger result size after the PLC program was built.

11. Variations for Other VeriSens Models

Most VeriSens variants (XC-100, XC-200, XF-100, XF-200, XF-800, CS-100, ID-200) use the same result telegram structure with minor differences in the header field count. The CS-100 and ID-200 add an additional 4-byte timestamp field at the front; the rest of the layout is identical. If you migrate from an XC-100 (firmware 2.x) to an XC-200 (firmware 3.x), the new firmware uses the same slot but renumbers the header fields, so the UDT must be updated.

For multi-port cameras (XF-800 with two PROFINET ports), the input slot is duplicated on each port with the same data. Read either port – but only configure one in TIA Portal to avoid double-triggering downstream logic.

12. Putting It All Together

The full pipeline from camera to PLC string variable is:

Once the STRING tag is populated and the Valid flag is set, downstream code can compare the QR code string against a master whitelist, log it to a CSV, or trigger a reject actuator. Because the entire pipeline uses symbolic addressing, renaming a field later only requires updating the UDT and re-downloading the project – no PLC program search-and-replace.