Tracing Shared Interlock Signals Between Siemens S7 PLCs

Overview: The Cross-PLC Interlock Tracing Problem

When two Siemens SIMATIC S7 controllers exchange handshaking bits—one PLC writes an "M" or DB bit that another PLC reads as a permissive—the originating tag is rarely visible from the consumer program. A standard cross-reference launched from the read tag will show only the local read, never the remote write, because the remote tag resides in a different project, on a different CPU, and travels through one of several transport mechanisms: Profibus DP, Profinet IO, S7 communication, Open User Communication (OUC), or a physical wiring layer (wired I/O).

This reference documents a systematic procedure for mapping an observed tag in the consumer PLC back to its source in the producer PLC. The procedure covers the four most common Siemens transports—S7 connections, I-device IO data, Open User Communication, and DP/PN slot routing—and shows how to use TIA Portal cross-reference, the symbol table, the connection diagnostics, and the program information to complete the trace.

Communication Architectures: What Carries the Interlock Bit

Before tracing a tag, classify the transport that links the two CPUs. The transport determines which TIA Portal view exposes the producer.

For the case described in the originating question—an M bit written in Machine A and read in Machine B without obvious linkage, over Profibus or Profinet—the most likely transports are Profibus DP master/slave data exchange (where the read tag is mapped through a DP slave's input area) or an S7 connection using PUT/GET. Profinet I-device communication and Profibus direct data exchange (DX) are also valid candidates on shop-floor Siemens installations.

Prerequisites

1. Access to both TIA Portal projects (consumer PLC and producer PLC) for the controllers involved. A read-only project is sufficient for inspection, but the offline project must be in sync with the online program.
2. TIA Portal V15.1 or later. Earlier versions (V13 SP1 / V14) expose the same views with minor label differences. STEP 7 V5.5 / V5.6 can be used if the controllers are S7-300/400 with classic projects.
3. Online connection (Ethernet or MPI/Profibus) to at least the consumer PLC. Online access to the producer PLC is recommended but not mandatory for static analysis.
4. Project read access to the producer's connection table or hardware configuration. If the producer is in a separate TIA Portal multi-project, the multi-project must be opened with all sub-projects loaded.
5. The exact tag name or absolute address observed in the consumer (e.g., "Machine_Ready" or MW100 / DB101.DBX0.0).

Step 1: Confirm What the Consumer Tag Actually Is

Open the consumer project in TIA Portal and locate the tag in the symbol table or directly in the program editor. Right-click the tag and select "Go to usage" (CTRL+ALT+Q) or "Cross-reference information." Capture the following data:

• Symbolic name (if any) and the absolute address, e.g., %MW100, %DB101.DBX0.0, or %I0.0.
• Data type (BOOL, INT, REAL, etc.).
• All read/write locations within the consumer project (Network N of OB1, FC12, FB55 instance DB, etc.).

The address's memory area is the first critical clue:

Step 2: Trace via S7 Communication (PUT / GET / BSEND / BRCV)

If the consumer tag is a bit/byte/word/doubleword in the M area or in a DB, the most common Siemens transport is the S7 connection family. The CPU-to-CPU S7 connection is configured in the "Devices & Networks" editor and consumed by these blocks:

Procedure: Locate the consumer-side receive block

1. In the TIA Portal project tree, expand the consumer CPU and right-click Program blocks > System blocks > Communication. Sort by name and look for PUT, GET, URCV, BRCV, AG_RCV, AG_LRCV.
2. If you cannot find the standard blocks, the project may use the newer TSEND_C / TRCV_C compact blocks (S7-1200/1500) or a user-defined FB that wraps them.
3. Open the instance DB of each candidate block. The instance DB exposes the connection parameters and the local data buffer pointer.

The instance DB of a PUT/GET block contains fields that identify the partner CPU and the remote memory area. In a typical TIA Portal instance DB, the relevant fields are:

// PUT block instance DB (excerpt, TIA Portal V16+)
// "id" is the local connection ID; "pir_t" / "pir_a" = pointer types
id                := 1                 // local connection ID
req               := FALSE             // rising edge triggers job
done              := FALSE             // job complete
error             := FALSE             // job finished with error
status            := 0                 // STATUS / RET_VAL output
addr_1            := P#DB1.DBX0.0 BYTE 160   // local source
addr_2            := P#M100.0 BYTE 160       // local source (alt)
addr_3            := P#M260.0 BYTE 160       // local source (alt)
addr_4            := P#M420.0 BYTE 160       // local source (alt)
remote_tsap_id_len := 2
remote_tsap_id[1] := B#16#10          // remote TSAP byte 1
remote_tsap_id[2] := B#16#01          // remote TSAP byte 2 = slot 1
remote_address    := 192.168.0.20     // partner IP (S7-1500)
write_remote      := TRUE              // PUT writes; GET reads
sd_1              := P#M100.0 BYTE 160 // for GET: remote area copied here

The fields sd_1 through sd_4 (PUT/GET) and rd_1 through rd_4 (GET) reveal the local pointer that receives the data. If sd_1 := P#M100.0 BYTE 160, then M100.0 through M119.7 are populated by the partner CPU. The M-bit the consumer reads (e.g., "Machine_Ready" = M102.0) sits inside that range. From here, you know the producer is the partner CPU identified by remote_address (IP) and remote_tsap_id (Profibus slot/rack or Profinet TSAP).

Procedure: Confirm the connection in the connection table

1. Open Devices & Networks → select the consumer CPU → click the Connections tab at the bottom.
2. Find the S7 connection whose local ID matches the block's id field. The partner endpoint shows the producer CPU's IP / Profibus address.
3. Right-click the connection and select Connection diagnostics → Online status. This brings up the S7 connection status, including bytes sent/received, error count, and partner status.

Step 3: Trace via Open User Communication (TSEND_C / TRCV_C / T_SEND / T_RCV)

Open User Communication (OUC) is identified by blocks of the T family: TSEND_C, TRCV_C, TCON, TDISCON, T_SEND, T_RCV. The compact blocks TSEND_C / TRCV_C combine connection establishment, send, and receive into a single FB on S7-1200/1500.

1. Search the consumer program for TSEND_C / TRCV_C / TCON / TDISCON. The instance DB contains the connection parameters:

// TRCV_C instance DB (S7-1500, TIA Portal V16+)
// CONNECT is a TCON_IP_v4 (or TCON_IP_RFC) data type
CONNECT := "connDb".Connect      // pointer to connection description DB
REQ     := TRUE                  // trigger receive on rising edge
CONT    := TRUE                  // keep connection open
LEN     := 100                   // expected payload length
DATA    := P#M200.0 BYTE 100     // local buffer receiving data
ADHOC   := FALSE                // wait for full LEN bytes before DONE
RCVD_LEN := 0                   // actual bytes received
STATUS  := 0                    // STATUS output
BUSY    := FALSE
ERROR   := FALSE

The DATA pointer (P#M200.0 BYTE 100) is the local buffer. Any M-bit, byte, or word that the consumer reads (e.g., "Machine_Ready" = M204.0) must be inside the range covered by the receive buffer. Follow the same logic as PUT/GET: the CONNECT structure contains RemoteAddress, RemotePort, LocalPort, and the active protocol (TCP, ISO-on-TCP, UDP).

For the T_SEND / T_RCV family (S7-300/400 with separate TCON), the procedure is identical: open the instance DB and read ID, CONNECT parameters, and the data pointer.

Official Siemens reference for compact OUC blocks: S7-1200/1500 Communication: TSEND_C / TRCV_C. For the legacy T blocks: Open User Communication with T_SEND / T_RCV.

Step 4: Trace via Profinet I-Device (Lower-Level IO Interface)

An I-device (intelligent IO device) is a Siemens Profinet node that acts as both a Profinet controller (to its own lower-level IO) and a Profinet device (to a higher-level controller). The exchange happens entirely at the IO layer; there are no communication blocks involved. Data exchanged is mapped through a transfer area configured in the I-device's hardware editor.

1. In the consumer project (the higher-level controller), open Devices & Networks and look at the topology. The I-device appears as a Profinet device node connected to the consumer CPU's Profinet interface.
2. Open the I-device's Device view and select the I-device interface > Transfer areas tab. Each transfer area exposes a name, slot, sub-slot, direction (input/output), and the IO address range on the controller side.
3. Suppose the I-device's transfer area 1 is configured as an input area starting at 100 (i.e., addresses %I100.0 through %I107.7 on the consumer). The bits mapped into that range are populated by the producer (the I-device) writing to the same area in its own hardware configuration, on the producer side of the I-device interface.

To complete the trace, you must open the producer project's I-device interface, find the matching transfer area, and read the producer's IO address (typically mapped into a DB or directly into the process image of the producer CPU). The I-device configuration in the producer project shows the source tags; in the consumer project it shows the destination addresses.

Reference: Configuration and Application of the PROFINET I-Device Function. The transfer area configuration in TIA Portal is documented under Devices & Networks → Device view → I-device interface → Transfer areas.

Step 5: Trace via Profibus DP Master/Slave or Direct Data Exchange

Profibus DP supports three roles relevant to interlock propagation:

• DP master class 1 (DPM1): the central controller that owns the bus and exchanges IO data with its assigned DP slaves cyclically.
• DP slave: a passive node whose process data is read/written by the DPM1.
• DP master class 2 (DPM2) and Direct Data Exchange (DX / "Publish/Subscribe"): a second master (or the same one in DX mode) listens to a slave's input broadcast without owning the slave. DX is the classic method for inter-CPU handshaking over Profibus when both PLCs are on the same bus.

For DX-based interlock propagation:

1. In the consumer project, open Devices & Networks > DP master system and look for a node that has its Mode set to "DP slave" on the consumer side, but whose inputs are not generated by the consumer itself.
2. Right-click the slave and select Properties > Direct data exchange (in classic STEP 7) or Operating mode > DX (TIA Portal). The DX configuration lists the source DP slave whose input bytes are being subscribed.
3. The IO addresses populated on the consumer side are visible in the slave's module configuration. Match those addresses to the M-bit or DB bit the consumer program reads.

For DP master → DP slave with PUT/GET used to access the slave's memory: the trace is identical to Step 2 (PUT/GET trace).

Reference: SIMATIC Profibus DP Direct Data Exchange documents the configuration steps and the role of GSD files for third-party slaves.

Step 6: Trace via Symbol Table and Cross-Reference (Last Resort)

If the transport cannot be identified from the program blocks or hardware configuration, the tag may be arriving through a hardware interlock—i.e., a physical wire from a DO module of the producer to a DI module of the consumer. In this case, no software trace exists; the only diagnostic is:

1. In the consumer project, identify the DI module and channel associated with the read tag. Right-click the address and select Go to IO device to confirm the module and channel.
2. In the producer project, identify the DO module and channel that drives that physical wire. The producer's symbol table typically carries a name like "To_MachineA_Ready" that should be searched by keyword fragments (e.g., *Ready*, *To*MachineA*, *Interlock*).

Step 7: Cross-Project Verification (Producer Confirmed)

Once the producer is identified (CPU + tag + transfer mechanism), confirm the trace by going online with both CPUs and observing the tag in real time.

1. Open the consumer's Watch table with the read tag (e.g., "Machine_Ready"). Monitor the value.
2. Open the producer's Watch table with the suspected source tag (e.g., "Part_Present_OK"). Monitor simultaneously.
3. Force the producer tag ON, then OFF, and observe the consumer tag. The values must track within one cycle of the transport latency:
   • Profibus DP: cyclic refresh, default 1–10 ms
   • Profinet IO: 250 µs – 4 ms (RT) or 31.25 µs (IRT)
   • S7 connection PUT/GET: triggered by user code, latency = call interval + acyclic service time (typically 30–100 ms)
   • OUC: triggered by user code, latency = send trigger + one TCP round trip (typically 5–50 ms on a switched LAN)
   • Physical wiring: ≤ 1 scan cycle, typically 1–10 ms

If the values track within expected latency, the trace is complete. If they do not, revisit Steps 2–5: the producer may be on a different connection (multiple PUT/GET partners on the same CPU is common), or the address translation may be off by one or more bytes due to a multi-byte receive buffer.

Step 8: Document the Trace

For repeatability, capture the trace in a worksheet that future engineers can use:

The table above is the minimum data set. Save it to the TIA Portal project as a comment on the receive block, or store it in a project-specific traceability document.

Troubleshooting Matrix: Trace Failure Modes

Automation Tips: Bulk Search Across Large Projects

For facilities with hundreds of inter-CPU signals, manual tracing is impractical. The following bulk-search techniques help narrow candidates quickly:

1. TIA Portal cross-reference across the project tree: From the project root, right-click the CPU and select Cross-references → All usages in project. Filter by "read" to identify candidate remote-source tags without symbols.
2. Find and replace across all blocks: Press CTRL+F with the address or symbol; the find dialog can search "in all program blocks" and reports the location of every reference.
3. Symbol table export to CSV: Right-click the symbol table → Export. Sort the CSV by address range to spot clusters of remote-source tags at the boundary between DI inputs and M/DB areas.
4. Program info → Call structure: From the project tree, double-click Program info > Call structure. PUT/GET/TSEND_C/TRCV_C are highlighted as system blocks; their instance DBs are listed as call targets.
5. Compare projects: If the producer and consumer projects were forked from a common template, use Project > Compare with partner (TIA Portal multi-project) to expose connection differences.

Field-Proven Caveats

• PUT/GET access is disabled by default on S7-1200/1500. The partner CPU property "Permit access with PUT/GET communication from remote partner" must be enabled. In a tracing scenario, if the partner refuses with status 0x80C4, this is the first thing to check.
• TSAP conventions differ between Profibus and Profinet. For Profinet, the TSAP is typically B#16#10, B#16#01 (rack 0, slot 1) or constructed from a project-wide connection resource ID. For Profibus, the TSAP encodes the Profibus address (e.g., B#16#04 for address 4) padded to two bytes.
• Connection IDs are local. Each CPU uses its own connection ID space. The same logical connection can have ID=1 on the consumer and ID=5 on the producer. Do not expect them to match.
• Compact OUC blocks on S7-1200/1500 raise DONE on every successful receive, even with no new data. The consumer's logic should ignore DONE if the LEN or RCVD_LEN indicates no payload change.
• I-device transfer area byte-order: TIA Portal preserves byte order in the transfer area, but the consumer and producer may declare different symbol comments. Always verify by absolute address, not by comment.
• For S7-300/400 with CPs, the legacy AG_SEND/AG_RCV blocks are tied to a CP, not the integrated PN interface. If the project shows the block on the integrated interface, it is misconfigured; either the CP is the wrong one or the block is mismatched. Reference: SIMATIC NET S7-300/400 CPs — Communication Blocks.

Safety Note: Live Modification of Connection Parameters

Changing connection parameters, TSAPs, or transfer area addresses on a running interlock is a safety-relevant operation. The receiving PLC will momentarily lose the signal, which can cause the consumer machine to either drop out of "ready" state (safe) or, in improperly designed interlocks, advance to a hazardous state (unsafe). Always:

1. Place the affected machines in a safe / maintenance state before downloading connection changes.
2. Verify the new connection with the watch table procedure from Step 7 before restoring production.
3. Coordinate the change window with both machine operators; interlocks are shared by definition and a download to one PLC affects the other.

Summary: The 5-Question Quick Triage

When the next engineer asks "where does this bit come from," apply this triage:

1. What is the consumer tag's memory area? (I = hardware/IO, M/DB = S7 comms or OUC, Q = local output only)
2. If I/PI, is there an IO device or DP slave in the hardware configuration that owns that address range? (Profinet I-device, Profibus DP slave, or wired DI)
3. If M/DB, is there a PUT/GET/TSEND_C/TRCV_C/BRCV/AG_RCV block whose data pointer covers the tag address?
4. Open that block's instance DB and read the partner IP/Profibus address/TSAP/connection ID. That identifies the producer CPU.
5. Open the producer project, locate the partner block on the producer side, and read its source pointer. That identifies the producer tag.

The full procedure detailed above expands each of these five questions into the diagnostic and verification steps needed to land the trace conclusively.

FAQ