Configuring Virtual Connections Between Siemens TDC CPU551 Processors

This technical reference describes how to establish virtual connections (VCs) between two Siemens SIMATIC TDC (Technology and Drive Control) CPU551 processor modules. The article covers both transport mechanisms: the buffer-based CTV (Communication Transmit Virtual) and CRV (Communication Receive Virtual) function blocks, and the pointer-based CTV_P/CRV_P variants. The procedure requires at least one CP50M0, CP50M1, or CP51M1 communication module equipped with shared buffer memory, the @GLOB initialization function block on each participating CPU, and NOP8 placeholder blocks used to define the virtual connection endpoints.

The reference covers hardware prerequisites, the virtual connection naming and sequence-number convention, AT/AR connector configuration, the @GLOB buffer-memory initialization, NOP8 interconnection creation, a complete step-by-step configuration, the compile and download procedure, online verification, and a troubleshooting matrix. A FAQ section addresses the most common engineering questions, including the meaning of the LFE (Local Field Element) signal prefix, when a recompile is required, and how to choose between CTV/CRV and CTV_P/CRV_P.

1. Siemens TDC Virtual Connection Overview

A virtual connection is a logical, named data channel that links a signal source on one CPU551 to a signal sink on another CPU551. The connection is "virtual" because no physical wiring exists between the processors; data is moved through the shared buffer memory of a CP50M0, CP50M1, or CP51M1 communication module installed in the same TDC rack. Once a virtual connection is defined, the source signal is written into the CP buffer by the source CPU and read out by the destination CPU on each processing cycle.

Three patterns are used in field installations:

• One-to-one: a single signal or signal group from CPU A is consumed by CPU B. Implemented with a single CTV/CRV pair (or CTV_P/CRV_P pair) sharing one virtual connection name. This is the most common configuration.
• One-to-many: a signal from CPU A is consumed by two or more CPUs. Each receiver CPU uses its own CRV with the same virtual connection name; sequence numbers differ on each CPU's chart set.
• Bidirectional: CPU A sends signal X to CPU B while CPU B sends signal Y to CPU A. Two virtual connections (with two different names) are required, even though the underlying CP buffer memory is shared.

Virtual connections are configured during CFC engineering and resolved at compile time. The compile step generates the runtime data structures that the CPU551 firmware uses to schedule buffer reads and writes. After a successful compile, the configuration must be downloaded to every participating CPU551 before the connections become live. The CFC toolchain performs a structural consistency check at compile time, so most wiring errors are surfaced as compile errors rather than runtime faults.

2. Hardware Requirements: CPU551 and CP50M0/CP50M1/CP51M1 Communication Modules

All cross-CPU signal exchange in a TDC rack requires at least one communication processor module. The supported modules for buffer-based virtual connections are the CP50M0, CP50M1, and CP51M1. These modules differ in throughput, buffer memory size, and the number of simultaneous virtual connections they can sustain at the rack level.

The CPU551 is the user-logic processor. Each CPU551 runs its own CFC chart set with its own sampling time and task assignment. A CPU551 reads from and writes to the CP buffer independently; the CTV/CRV function blocks translate virtual connection names into buffer offsets so the engineer never has to manage raw memory addresses. The CFC runtime resolves these offsets into firmware-level direct memory access operations.

The full hardware specification for the CPU551 and the CP module variants is found in the SIMATIC TDC hardware manual. Engineers commissioning a new rack should plan the slot assignment so that the CP module is electrically adjacent to the CPU551 modules that will exchange data, which minimizes backplane latency.

3. Virtual Connection Architecture and Naming Convention

Each virtual connection is identified by two attributes:

• Name: a user-defined string. The field convention is a structured identifier such as BXD010, where the leading characters identify the connection family and the trailing digits identify the slot or function. The name must be identical on the sending and receiving CPU; capitalization and trailing characters are significant.
• Sequence number: a small integer that disambiguates multiple virtual connections sharing the same name prefix within a single CPU's chart set. Sequence numbers must be unique within one CPU chart set. The sender and receiver do not have to use the same sequence number; only the connection name has to match.

Data flow on a single virtual connection is unidirectional. A CTV block writes to the connection; a CRV block reads from it. If bidirectional exchange is required, two virtual connections (with two different names) are used on the same CP buffer.

The runtime resolution model is "publish by name, subscribe by name." The CTV publishes the value into the named slot in the CP buffer; every CRV in the rack whose AT/AR matches that name subscribes to the slot. The sequence number is purely a chart-side identifier and does not influence buffer addressing.

4. Buffer-Based Transfer: CTV and CRV Function Blocks

The CTV (Communication Transmit Virtual) block transmits a signal group from the source CPU into a named virtual connection. The CRV (Communication Receive Virtual) block receives the same signal group on the destination CPU. The two blocks are paired by the connection name string at their AT and AR connectors respectively.

Connector semantics on the CTV block:

• AT (Address Transmit): the virtual connection name. Enter only the name; do not enter an address stage 1 or stage 2. For example, enter BXD010, not BXD010.1.2.
• Signal inputs: the value(s) to be transmitted. The CTV block typically exposes multiple input pins for a small bundle of signals (booleans, integers, reals). The number of pins is fixed by the FB type; if more signals must travel together, use a CTV_P with a pointer to a structure.

Connector semantics on the CRV block:

• AR (Address Receive): the same virtual connection name used on the CTV (for example, BXD010).
• Signal outputs: the values received from the source CPU. The number of pins and data types must match the sender side. A type mismatch produces a compile error, not a silent data corruption.

The CTV/CRV pair performs implicit data marshalling: each pin on the CTV is mirrored to the same pin on the CRV. Mismatched data types between sender and receiver are flagged at compile time, so a naming typo or a missing pin produces a compile error rather than silent data corruption. The CFC compiler cross-references the AT/AR names across all chart sets in the same workspace; a connection name that appears on a CTV but on no CRV is accepted (data is written to a buffer that no one reads) but is reported as a warning so the engineer can clean up unused publishers.

5. Pointer-Based Transfer: CTV_P and CRV_P Function Blocks

CTV_P and CRV_P are pointer-based variants. Instead of pinning every signal to a named connector, the engineer provides a pointer (memory address) to a contiguous data block. The CTV_P block reads from the pointer and writes to the connection; the CRV_P block reads from the connection and writes to the pointer's destination. This pattern is preferred for:

• Bulk data transfer (arrays, structures, multi-word blocks).
• Loops where many signals of the same type need to be moved.
• Cases where the connection is generated programmatically and the engineer wants to avoid manual pin wiring.

Pointer-based transfers are easier to scale but require the engineer to manage pointer validity carefully. A null pointer, an unaligned address, or a length that exceeds the CP buffer capacity will not be caught by the CFC compiler in the same way that a missing partner block is caught for the non-pointer variant. The standard mitigation is to bound the pointer length at compile time and to validate the pointer against a known-good address range at the @GLOB initialization stage.

6. Buffer Memory Initialization with @GLOB

The @GLOB (Global) function block is inserted on every CPU that participates in cross-CPU communication. It performs one-time initialization of the local CPU's interface to the CP module's shared buffer memory. Without @GLOB, the CTV/CRV blocks have no runtime support and the connections will not become live after download.

Typical @GLOB configuration parameters visible on the block faceplate:

• CP slot address: the rack slot of the CP50M0/M1 or CP51M1 module that this CPU is using. Must match the physical slot of the installed CP module.
• Buffer size hint: an optional sizing parameter that helps the toolchain reserve buffer space for the declared virtual connections on this CPU.
• Initialization mode: cold-start behavior on CPU restart (re-initialize buffer pointers, retain last values, or initialize to a defined default).
• Redundancy role: primary or backup in a redundant CP configuration. Both CPUs in a redundant pair must agree on the role assignment.

The @GLOB block has no signal inputs in the usual sense; it is a configuration block. Place it once per CPU chart set, near the top of the chart hierarchy, so that the initialization runs before any CTV/CRV block executes on the first CPU cycle after a cold start.

7. Configuring Virtual Connections via NOP8 Interconnection Points

The NOP8 (No-Operation, 8-pin) block is used as a placeholder so that a virtual connection has a well-defined source or sink pin in the CFC chart. The actual signal flow into or out of the virtual connection is wired to the NOP8 input or output; the NOP8 itself does not transform the signal. Its purpose is to give the CFC compiler a stable pin to bind a virtual connection name to, even when the upstream or downstream logic is still being developed.

Procedure to declare a virtual connection on a NOP8 pin:

1. Insert a NOP8 block in the CFC chart at the desired location.
2. Right-click on the desired pin (output for sender side, input for receiver side).
3. From the context menu, select Interconnection to address....
4. In the dialog, set the address type to Virtual connection.
5. From the drop-down list, select the virtual connection name (for example, BXD010). New names can be created inline if the name does not yet exist in the workspace.
6. Enter a Sequence number. Use the next free integer in this CPU's chart set (for example, 7 or 8 if 1 through 6 are already used).
7. Click OK. The pin is now bound to that virtual connection. The pin label updates to show the bound name and sequence number.

Repeat the same declaration on the receiving CPU, this time on the input side of a NOP8 block, using the identical virtual connection name. The sequence number does not have to match between sender and receiver; only the connection name has to match.

If the same name with the same sequence number is used twice on the same CPU, the compiler will report a duplicate-sequence error. If the same name is used on the sender and receiver, the connection resolves at runtime. If a connection name exists on the sender but no matching name exists on any receiver, the data is written into the buffer but no CPU consumes it, which is harmless but wastes buffer space and should be cleaned up during commissioning.

8. Step-by-Step Configuration Procedure

Use the following end-to-end procedure to add a new virtual connection between two CPU551 modules. The procedure assumes both CPUs, one CP module, and the TDC toolchain are installed, configured, and online-capable.

1. Confirm the rack. Verify that both CPU551 modules and at least one CP50M0, CP50M1, or CP51M1 module share the same TDC rack. Cross-rack virtual connections are not supported through this mechanism.
2. Open the sender CPU chart set. Launch the SIMATIC TDC / CFC editor and load the chart set assigned to the sender CPU551.
3. Place or verify @GLOB. Confirm that a single @GLOB block is present in the chart hierarchy, with the correct CP slot address. If absent, insert one.
4. Place the CTV block. Insert a CTV block at the location where the signal leaves the sender CPU.
5. Wire the signal inputs to the CTV. Connect the source signal(s) to the CTV input pins. Confirm data types are explicit and match the intended receiver data types.
6. Set the AT connector. On the CTV block, enter the virtual connection name on the AT connector (for example, BXD010). Do not enter an address stage 1 or 2.
7. Declare the virtual connection endpoint via NOP8. Insert a NOP8 block. Right-click on an output pin, choose Interconnection to address..., select Virtual connection, choose the same name (BXD010), and enter a free sequence number on this CPU's chart set.
8. Open the receiver CPU chart set. Switch to the chart set assigned to the receiver CPU551.
9. Place or verify @GLOB. Insert or confirm @GLOB on the receiver CPU as well, pointing at the same CP module.
10. Place the CRV block. Insert a CRV block at the location where the signal is consumed.
11. Wire the CRV outputs to the application. Connect the CRV output pins to the downstream FBs in the receiver CPU.
12. Set the AR connector. On the CRV block, enter the same virtual connection name (BXD010) on the AR connector.
13. Declare the virtual connection endpoint via NOP8 on the receiver. Insert a NOP8 block. Right-click on an input pin, choose Interconnection to address..., select Virtual connection, choose the same name (BXD010), and enter a free sequence number on this CPU's chart set.
14. Compile both chart sets. Run the CFC compile on the sender CPU first, then the receiver CPU, to validate the connection end-to-end. Fix any reported type or pin mismatches before proceeding.
15. Download to both CPUs. Download the compiled configuration to the sender CPU551 and the receiver CPU551. The virtual connection goes live on the next CPU run cycle after the download completes.
16. Verify in online mode. Switch the editor to online mode and observe the CTV input pins and the CRV output pins; the values must match within one sampling interval on the receiver CPU.

9. Compilation, Download, and Online Verification

The compile step resolves the CTV/CRV pair into buffer offsets and inserts the runtime glue that the CPU551 firmware uses to move data on each cycle. The download step transfers the compiled configuration into non-volatile memory on each CPU551. After download, the new configuration becomes effective on the next CPU run-up.

Verification checklist in online mode:

• The CTV block's status output (if present) is OK with no error code.
• The CRV block's status output is OK with no error code.
• Forcing a value on the CTV input pin is reflected on the CRV output pin within one sampling interval on the receiver CPU.
• The buffer memory diagnostic in the CP module (if exposed in the TDC toolchain) reports a non-zero update count for the named connection.
• A watch table on the receiver CPU that references the CRV output shows the expected value during steady-state operation.

If the CRV outputs remain at their initial values (typically zero), the most common cause is that the @GLOB block on either CPU is missing, misconfigured, or points at the wrong CP slot. The second most common cause is a sequence number collision on one side of the pair, which the compile would normally have caught but can reappear if the chart was edited and saved in offline mode without a recompile. A third possibility is that the CTV input pins are driven from a chart segment whose sampling time is much slower than the receiver's sampling time, producing values that appear frozen at the receiver even though the connection is technically live.

10. Troubleshooting Matrix

11. Frequently Asked Questions