S7-1200 Barcode Reader Integration: 6-Scanner Architecture Guide

1. Problem Definition and Engineering Constraints

Connecting six barcode readers to a single control system for raw-material entry on a production line requires careful architectural planning. The scanner data must be available simultaneously in the PLC (for control decisions), in WinCC (for operator visibility), and in a database (for traceability and ERP integration). The interface on the barcode reader side—RS-232, RS-422, RS-485, USB, Ethernet, or PROFINET—drives the entire design.

Field deployments on similar lines repeatedly show four constraints that shape the architecture:

• Maximum of three CM 1241 communication modules plus one CB 1241 signal board per S7-1200 CPU (1214C / 1215C / 1217C).
• Each serial port is a half-duplex or full-duplex point-to-point link; RS-232 cannot be multi-drop chained.
• PROFINET-capable scanners occupy a PROFINET IO slot like any other IO device and do not consume CM 1241 resources.
• Database integration must be transactional, not polled, to avoid record loss during production peaks.

2. Prerequisites

2.1 Hardware Required

• Siemens S7-1200 CPU 1214C DC/DC/DC (6ES7214-1AG40-0XB0) or 1215C DC/DC/DC (6ES7215-1AG40-0XB0) as the minimum for three CM 1241 modules.
• CM 1241 RS-232 module (6ES7241-1AH32-0XB0), one per RS-232 scanner.
• CM 1241 RS-422/485 module (6ES7241-1CH32-0XB0) for any RS-485 multi-drop scanner cluster.
• CB 1241 RS-485 signal board (6ES7241-1CH30-1XB0) for the fourth serial port on a single CPU.
• PROFINET-native scanners (for example, the Keyence SR-series code readers) for direct fieldbus integration.
• Shielded D-sub 9-pin cables rated for industrial use, with shell grounding at the PLC end only.
• PROFINET patch cabling (Cat 6 SF/UTP, industrial grade) where scanners carry PROFINET.

2.2 Software Required

• TIA Portal V17 or later; V18 is recommended for new deployments.
• S7-1200 CPU firmware V4.4 or later for full PROFINET scanner compatibility.
• PtP (Point-to-Point) instruction library, included with TIA Portal.
• WinCC Comfort/Advanced V17 or later for HMI design.
• WinCC Database Connectivity option, a custom OPC UA server, or a S7-1200 user program that pushes records to a SQL database via TCP.

2.3 Site-Survey Information Required

1. Scanner model and firmware version for each of the six positions.
2. Physical interface (RS-232, RS-422/485, USB, Ethernet, PROFINET, EtherNet/IP).
3. Default serial parameters (baud, parity, data bits, stop bits) and protocol framing (CR/LF, STX/ETX, none).
4. Trigger source (continuous, hardware trigger via DI, command trigger from PLC).
5. Maximum cable length between scanner and panel; RS-232 is rated for 15 m typical, 30 m at lower baud rates with low-capacitance cable.
6. Power source: 24 VDC at scanner or PoE for Ethernet variants.

3. Architecture Comparison

Three viable architectures exist for the six-scanner application. Selection depends on the scanner inventory already on site and on whether the PLC order is still open.

4. Architecture A: Direct Serial with CM 1241 and CB 1241

The user's original plan—six serial cards and two S7-1200 CPUs—is technically workable but rarely optimal. A single S7-1200 with three CM 1241 modules plus one CB 1241 signal board provides four serial ports; the remaining two scanners must therefore either go on a second CPU linked by PROFINET, or be migrated to PROFINET or to a gateway as in Architecture C.

4.1 Module Variants and Catalog Numbers

4.2 RS-232 Pinout (D-Sub 9 Male, PLC Side, DTE Convention)

Handshake: most barcode readers default to no flow control. Hardware RTS/CTS is required only when the scanner firmware sets Hardware handshake in its serial menu; connecting pins 7–8 straight-through at the PLC end without scanner-side handshake may cause the PLC to drop characters under burst load. Software XON/XOFF is acceptable but ties up two ASCII codes (DC1/DC3) that must not appear in the barcodes themselves.

5. Architecture B: PROFINET-Native Scanners

PROFINET-capable scanners expose barcode data, decoded symbol type, and read quality as cyclic IO. The PLC reads them like any other PROFINET device. The Keyence SR-700 and SR-1000 series, for example, support PROFINET IO with a GSDML file that integrates directly into the TIA Portal device catalog; readers can be linked to share operating status and trigger results across the network.

Key advantages for the six-scanner use case:

• One CPU, one PROFINET network, six scanners, no CM 1241 modules required.
• Per-scanner read diagnostics (decoded count, decode time, match-string) available as cyclic IO.
• Scanner web server exposes read images and statistics without extra software.
• Replacement of a faulty scanner is a PROFINET device swap; the new unit inherits the IO configuration.

5.1 Typical Cyclic Data Layout (vendor-specific; verify against the supplied GSDML)

6. Architecture C: Serial-to-PROFINET Gateway

When the existing scanners are RS-232 only and the cable lengths from the scanners to the panel exceed 30 m, a multi-port serial-to-PROFINET gateway consolidates the six serial links onto a single PROFINET device. Gateways of this type (for example, the Prosoft PLX31 series) translate ASCII data from each serial port into PROFINET IO input bytes, exposing each barcode string as a 64- or 128-byte input area that the PLC can read directly.

For projects that mix Modbus RTU scanners and ASCII scanners, the same gateway can also act as a Modbus-to-PROFINET bridge; the Prosoft application note on barcode-to-controller integration describes the typical mapping in detail.

6.1 Gateway Port Budget

7. TIA Portal Configuration for Serial Architecture A

7.1 Hardware Configuration

1. Open the project and double-click Devices & networks.
2. From the catalog, drag three CM 1241 (RS-232) modules into slots 101, 102, and 103 of the S7-1200 CPU.
3. Insert a CB 1241 RS-485 signal board into the CPU slot if a fourth serial port is required.
4. For each port, set Port configuration: baud 9600 (or as required by the scanner), 8 data bits, no parity, 1 stop bit, no flow control.
5. Enable Receive line initial state = HIGH if the scanner idles in the mark state (most do).
6. Set End-of-receive criteria = On receiving the character configured as end delimiter, delimiter = 0x0D (CR) or 0x0A (LF) per scanner default.

7.2 PtP Instruction Blocks

The PtP library provides three core blocks. For six scanners, instantiate six of each.

• Receive_P2P — copies the buffered characters into a per-scanner data block.
• Send_P2P — sends a trigger or configuration string to the scanner.
• Receive_Reset — clears the receive buffer after the application has consumed the string.

7.3 SCL Code Skeleton (per Scanner)

// FB_ScannerPort — one instance per CM 1241 port
// Trigger pulse: rising edge of bTrigger starts a read
// Received string lands in sBarcode[1..64] of instance DB

IF #bTrigger AND NOT #bTriggerOld THEN
    "Send_P2P_DB"(REQ := TRUE,
                  PORT := #hwID,           // hardware ID of the CM 1241
                  BUFFER := 'TRG\r',       // ASCII trigger command
                  LENGTH := 4,
                  DONE => #sendDone,
                  ERROR => #sendError,
                  STATUS => #sendStatus);
END_IF;
#bTriggerOld := #bTrigger;

// Receive runs every cycle; only consumes when complete
"Receive_P2P_DB"(EN_R := TRUE,
                 PORT := #hwID,
                 BUFFER := #sBarcode,
                 LENGTH := 64,
                 NDR => #ndr,
                 ERROR => #rcvError,
                 STATUS => #rcvStatus);

IF #ndr THEN
    // String consumed — log it, route to WinCC, push to DB
    #bNewString := TRUE;
    "Receive_Reset_DB"(REQ := TRUE, PORT := #hwID, DONE => #rstDone);
END_IF;

7.4 Distinguishing Scanner Sources in the PLC

Each scanner is tied to its own CM 1241 port and its own receive instance data block. Identification is therefore implicit: the instance DB number or the hardware ID is the scanner number. A recommended practice is to populate a Source word in the per-scanner DB that mirrors the slot number of the CM 1241 module (101, 102, 103, …) so the HMI and database receive a single field identifying the source.

8. Routing Data to WinCC

Each per-scanner instance DB is exposed to WinCC as an HMI tag array. The recommended tag structure is:

On the HMI screen, build one Barcode List View with six rows, each bound to the matching tag set. The NewData bit drives a flashing icon and resets on operator acknowledgement via an HMI button that writes back to the corresponding bit in the same DB.

For raw-material entry, an additional HMI popup should request operator confirmation of Material and Quantity when NewData goes high; the combination of barcode + operator-entered quantity is what flows onward to the database.

9. Database Logging

Three viable paths exist for moving barcode records to a database. Selection is driven by the existing IT landscape and the acceptable record-loss window.

9.1 Recommended Table Schema

CREATE TABLE dbo.barcode_log (
    log_id        BIGINT IDENTITY(1,1) PRIMARY KEY,
    log_time      DATETIME2(3)  NOT NULL  DEFAULT SYSUTCDATETIME(),
    scanner_id    SMALLINT      NOT NULL,
    barcode       NVARCHAR(64)  NOT NULL,
    material      NVARCHAR(32)  NULL,
    quantity      DECIMAL(18,3) NULL,
    operator      NVARCHAR(32)  NULL,
    shift_id      SMALLINT      NULL,
    plc_timestamp DATETIME2(3)  NULL
);
CREATE INDEX ix_barcode_log_time ON dbo.barcode_log (log_time);

9.2 OPC UA Path (Preferred for Lossless Logging)

1. Enable the OPC UA server on the S7-1200 (CPU firmware V4.4 or later, security level configured).
2. Expose each scanner's instance DB as an OPC UA node set with read access.
3. On a PC node, run a small service (for example, a .NET console host or a Node-RED flow) that subscribes to the NewData nodes and writes the new records to SQL via a parameterized stored procedure.
4. Maintain an in-memory buffer keyed on scanner_id so that a database write failure is retried on the next poll rather than dropped.

10. Verification and Commissioning Checklist

Run this checklist per scanner before declaring the line production-ready.

1. LED on CM 1241 (or scanner PROFINET port) shows Active (steady green) and Link on the Ethernet side where applicable.
2. From the TIA Portal Online & Diagnostics view, the CM 1241 port shows Port status = OK and the diagnostic buffer is free of receive-overrun warnings.
3. A loopback test on each cable: connect pins 2–3 of the D-sub at the scanner end and verify that a sent ASCII string is echoed back into the receive DB.
4. Trigger 50 production-coded barcodes; verify that all 50 appear in the instance DB, the HMI list view, and the SQL barcode_log table with identical strings.
5. Cycle power on the S7-1200; verify that the last received barcode from each scanner is preserved in the instance DB (set Retain on the data block or on the string fields that must survive restart).
6. Force a CM 1241 module out of the rack in TIA Portal; verify that WinCC raises a connection-loss alarm within the configured polling time and that the database log records the gap.
7. Load-test: trigger all six scanners at a 1 Hz rate for 10 minutes; verify that no records are lost and that the CPU scan time remains below 80 percent of the OB1 watchdog.

11. Troubleshooting Matrix

11.1 Common CM 1241 Status Codes

12. Field-Notes and Practical Caveats

• Two-CPU plans rarely pay off. Running two S7-1200s with PROFINET in between doubles the HMI tag count and the engineering effort. Use Architecture B or Architecture C unless the second PLC is already on the bill of materials for a separate reason.
• Retain on the receive DB is mandatory for any scanner whose last read must survive a power cycle; otherwise the operator sees an empty HMI field on restart and a phantom material entry in the database log.
• Shielded D-sub shells must be grounded at the PLC end only. Grounding both ends of a long parallel run creates a ground loop that injects common-mode noise and corrupts characters at bursts above 5 Hz.
• PROFINET scanner firmware updates change the GSDML revision. Re-import the GSDML on every firmware update and re-assign device names; the CPU will refuse to go online with a stale GSDML.
• For raw-material traceability, store the PLC timestamp alongside the database timestamp. The PLC timestamp is what the audit trail must defend; the database timestamp is for forensic cross-checking.
• Avoid XON/XOFF for barcode data. The XON (0x11) and XOFF (0x13) bytes are valid in some Code 128 symbologies and will trigger spurious flow control if enabled.