Siemens TDC Virtual Connections: CP Buffer Memory Configuration

Overview of Virtual Connections in Siemens TDC

Siemens Technology and Drive Control (TDC) systems exchange cyclic data between CPU551 processors through virtual connections hosted on CP50M0, CP50M1, CP51M1, or CP53M0 communication modules. A virtual connection is a logical channel declared in the CFC chart that occupies a fixed region of the CP module's 8 MB buffer memory. The 32 MB working memory visible on a CPU551 in HWConfig is application memory for charts, not the resource that backs virtual connections, and it does not extend the connection capacity.

From the engineering perspective, every virtual connection must be anchored by an @GLOB function block compiled onto the CP that physically owns the buffer. The same mechanism covers:

• Intra-rack data exchange between two CPU551 modules sharing one TDC rack and connected through the backplane to a common CP.
• Cross-rack transfer between CPUs in separate TDC stands, where the CTV FB reports the HW address of the CP that is bridging the data.
• Refresh/Multiple and Handshake/Select semantics, both of which consume the same buffer pool but with different overhead coefficients.

The CFC editor does not impose a numerical cap on declared connections. A chart can contain hundreds of connections; what stops an over-provisioned design is the buffer itself. When cumulative usage exceeds the 8 MB resident on the CP, the CPU dot-matrix display shows the character C and cyclic communication halts until the offending chart is recompiled with a smaller footprint.

Hardware Prerequisites: CPU551 and CP Module Selection

A TDC virtual-connection design must be validated against the CP module that will host the buffer. The four candidates are listed in the table below. They differ in backplane interface, number of physical communication ports, and maximum sustained buffer throughput, but they all share the same 8 MB buffer pool.

The CPU551 module itself carries 32 MB of working memory for charts, data blocks, and trace buffers. This figure appears in HWConfig's Module Description dialog and is frequently confused with the CP buffer. The two are separate physical memories on separate modules; a CPU cannot borrow capacity from a CP, nor vice versa.

Additional prerequisites for a working virtual-connection design:

1. CPU551 module with current firmware loaded (verify revision on the operator panel front sticker).
2. One CP module from the table above, installed in the same TDC rack slot family as the CPU and configured in HWConfig.
3. For cross-rack transfer: a fiber or copper link between the CP51M1 ports of stand 1 and stand 2, plus matching GLOB library on both stands.
4. CFC and HWConfig installed on the engineering station, with the SIMOTION/TDC add-on package licensed.
5. For distributed I/O referenced in the same chart: an ET200 station with IM153 interface module, configured under the same CP.

Buffer Memory Sizing Formula

The Siemens TDC manual provides a direct equation for sizing the buffer that a single virtual connection consumes. Two channel semantics are recognised, and each has its own coefficient.

Add the per-connection footprints for every declared connection in every chart that is bound to the CP's @GLOB FB. The sum must be less than or equal to 8 MB (8 388 608 bytes).

Worked example. A TDC stand declares the following virtual connections on a single CP53M0:

• 40 Refresh/Multiple channels, each carrying 256 bytes of user data.
• 20 Handshake/Select channels, each carrying 32 bytes of user data.

Per-channel consumption:

• Refresh/Multiple: 150 + 2 × 256 = 662 bytes.
• Handshake/Select: 150 + 1 × 32 = 182 bytes.

Aggregate consumption:

• Refresh/Multiple total: 40 × 662 = 26 480 bytes.
• Handshake/Select total: 20 × 182 = 3 640 bytes.
• Combined: 26 480 + 3 640 = 30 120 bytes (~29.4 KB).

This is well below 8 MB. The reason field installations often approach the limit is not the byte count of payload but the number of connections: each connection costs 150 bytes of fixed overhead even if no payload is exchanged. A design with 1 000 Refresh/Multiple connections of 0-byte payload still consumes 150 000 bytes (~147 KB) of buffer. Scale that to 50 000 connections and the overhead alone is 7.5 MB.

Channel Types: Refresh/Multiple vs Handshake/Select

The two channel semantics are not interchangeable. Choosing the wrong one doubles the buffer cost for the same payload, so the choice should be made deliberately at chart design time.

Use Refresh/Multiple when the producer overwrites the same memory location each cycle and subscribers only need the latest value. Use Handshake/Select when the consumer must confirm it processed the value before the producer can write again. The buffer penalty for Refresh/Multiple is real: every byte of payload effectively costs twice as much as in a Handshake channel.

Configuring the @GLOB Function Block on the CP

The @GLOB FB is the single anchor that binds a chart's virtual connections to the physical CP module. Every chart that contributes to the buffer must reference this FB, and the FB must be installed on the CP that physically holds the 8 MB pool.

Configuration steps:

1. Open HWConfig and place the CP module (CP50M0 / CP50M1 / CP51M1 / CP53M0) into the rack slot adjacent to the CPU551.
2. Right-click the CP slot and assign the slot address; this address is what the CTV FB will later report at its CTS input.
3. Open the CFC chart that owns the virtual connections.
4. Insert an @GLOB FB on the CP target. The FB symbol must be dragged from the library onto the CP chart partition, not onto the CPU partition.
5. Wire every virtual connection's source/destination pair to this @GLOB instance.
6. Compile the chart. The compiler must report success on the CP target; an unresolved @GLOB means the connection will not be backed by buffer memory.

Common configuration errors:

• @GLOB placed on the CPU chart partition instead of the CP chart partition. The compiler accepts the placement but no buffer is allocated; the connection simply does not appear online.
• Two @GLOB instances on the same CP in different charts. This is allowed but the buffer accounting is duplicated and the second chart's download can fail silently.
• Mismatched slot address between HWConfig and the CTV FB's CTS input. The FB then points to a phantom CP and the connection never updates.

Cross-Rack Communication with CTV and BXDXX0

When data must cross from a CPU551 in one TDC rack to a CPU551 in a second rack, the chart on the source side uses a CTV (Communication Transfer Virtual) FB. The CTV FB exposes two interesting pins:

• CRT (output) reports the module identifier BXDXX0, where XX is the logical slot of the CP that is forwarding the data.
• CTS (input) is the hardware address of that CP. This address must match what HWConfig assigned to the CP module.

The number of cross-rack channels available, and the maximum payload per channel, is determined by the CP module that bridges the racks (typically a CP51M1). The CTV FB performs no data buffering of its own; it consumes buffer on the same CP that hosts the @GLOB FB. So the same 150-byte overhead rule applies, with the same Refresh/Multiple or Handshake/Select coefficient.

Engineering checklist for cross-rack transfer:

1. Confirm the bridging CP51M1 has fibre/copper link status LEDs green on both stands before commissioning.
2. Confirm the CP51M1 slot address in HWConfig matches the value wired to the CTV CTS input on both stands.
3. Confirm @GLOB is placed on the CP chart partition on both stands, not just the source stand.
4. Confirm payload size fits within the CP51M1's documented maximum per-channel user data length. Exceeding it is silently truncated and causes handshake timeouts.

Step-by-Step: Adding Virtual Connections Between Two TDC Stands

Use this procedure when a field engineer needs to add new virtual connections between a CPU551 in stand 1 and a CPU551 in stand 2, each stand carrying its own CP module and its own @GLOB FB.

1. Confirm free buffer. On the engineering station, go online to both stands and open HWConfig → right-click CP → Module Information. Record the Used and Free buffer values for both CP modules.
2. Plan the additions. For each new connection, choose Refresh/Multiple or Handshake/Select, compute the byte cost using the formula, and confirm the sum fits in the free buffer on both CPs.
3. Edit the source chart. Open the CFC chart on stand 1 that contains the source connection. Add the new connection outputs and wire them to the @GLOB instance on the stand 1 CP.
4. Edit the destination chart. On stand 2, add matching connection inputs into the chart that consumes the data. Wire them to the stand 2 @GLOB instance.
5. Compile both charts. Each CPU551 has its own compile pass. Do not assume the compiler on one stand validates the other.
6. Download both targets. Both CPU551s require a chart download. The source CPU distributes the updated connection list to its CP; the destination CPU does the same on the second stand.
7. Verify online. After download, force a value on the source chart and trace it on the destination chart. Confirm the value updates within one TDC cycle.

Compile, Download, and Module Information Diagnostics

Compile/download sequencing for TDC charts is stricter than for S7 because the chart target is the CP module, not the CPU. The sequence must be:

1. Compile the chart in offline CFC. Resolve all FB instance references; any unresolved FB means the chart will not bind to @GLOB.
2. Switch CFC to online mode against the CPU551 in stand 1.
3. Select Chart → Download. This pushes the compiled chart to the CPU and to its co-resident CP.
4. Wait for the CPU RUN/STOP LED to settle on RUN with no C on the dot-matrix display.
5. Repeat steps 2-4 against the CPU551 in stand 2.

Forensic diagnostics if a C LED persists:

1. Open HWConfig → CP → Module Information. The buffer detail page shows the byte count used by each connection.
2. Sort the buffer table by descending byte cost. The first entry is the largest connection and the prime suspect if buffer overflow is suspected.
3. Cross-check the Number of channels field. If the field shows, for example, 6 connections of 4-byte payload, the buffer cost is 6 × (150 + 2 × 4) = 6 × 158 = 948 bytes, not 24 bytes. The 24-byte figure (visible as 6 × 4 in some dialogs) is the user data alone; it does not include the per-connection overhead.
4. If the sum still does not explain the C state, inspect the diagnostic buffer for OB1 / OB40 / OB85 / OB86 entries indicating rack failure or CP failure. These are independent of buffer overflow and indicate a physical link problem.

Memory Monitoring and Capacity Planning

Buffer monitoring should be a recurring maintenance task, not a one-off commissioning check. The 8 MB pool fills incrementally as charts are modified over the life of the system, and a connection that ran fine at commissioning can push the design over the limit three years later.

For capacity planning, build a spreadsheet listing every connection declared in every chart bound to each CP, with the channel type and payload. Multiply per the coefficient table, sum, and compare against the 8 MB ceiling. Repeat this exercise whenever a new chart is released.

Fault Conditions and the CPU 'C' LED

The CPU551 dot-matrix display can show a single character that summarises the worst active fault. The relevant one for virtual-connection problems is C. Other characters indicate unrelated faults (e.g. B for battery, F for firmware). The fault table below is specific to virtual-connection scenarios.

Field-Proven Caveats and Edge Cases

Several behaviours are documented but commonly misapplied in field installations. Keep these in mind whenever reviewing an existing chart set.

• The 32 MB figure in the CPU551 catalog is not the buffer. Field engineers frequently quote this number as the connection capacity. It is not. The 8 MB on the CP is the only resource that matters.
• The "6 × 4 = 24 bytes" view is misleading. The 4-byte payload is only the user data. The 150-byte per-connection overhead is invisible in some HWConfig dialogs and must be added back manually.
• Adding a connection on only one stand. If you recompile and redownload only the source stand, the destination stand still holds the previous chart. Cyclic updates from the source have nowhere to land and the CPU on the destination drops into C at the next buffer rebalance.
• @GLOB on the wrong partition. The CFC compiler accepts an @GLOB on the CPU partition, so this error is silent until the chart is downloaded and the connection never updates online.
• ET200 IM153 confusion. IM153 is the interface module for ET200 distributed I/O and is unrelated to the CP module's virtual-connection buffer. Distributed I/O does not consume virtual-connection memory; it consumes its own backplane slot on the CP that is configured as the IO controller.
• Refreshing only the CPU. A chart that touches only the CPU partition will not update the CP-side connections. Always run the chart download in the mode that updates both CPU and CP chart partitions.
• Mixing channel types in one chart. This is legal but raises the coefficient risk: a chart accidentally using Refresh/Multiple where Handshake/Select was intended doubles the buffer cost for that connection.

Verifying a Virtual-Connection Design Before Commissioning

Run this verification checklist before authorising a download to a live TDC stand. Each item is a single binary check.

1. Sum of all per-connection buffer costs ≤ 7.2 MB on every CP involved.
2. @GLOB FB present on CP chart partition of every stand that hosts connections.
3. CTV CTS input on every cross-rack connection matches the CP slot address in HWConfig.
4. Both CPU551 charts compiled cleanly with zero unresolved FB instances.
5. Both CPU551 charts downloaded, and dot-matrix display on each shows no C character.
6. Forced value on source chart traces through to destination chart within one TDC cycle.
7. For cross-rack transfer, fibre/copper link LEDs green on both CP51M1 front panels.

FAQ