Encapsulating Siemens FB12 BSEND and FB13 BRCV in a Custom FB

Overview

Siemens S7-300/400 communication blocks FB12 "BSEND" and FB13 "BRCV" ship from the Standard Library > System Function Blocks and form the buffered, bi-directional S7 communication pair used to exchange variable-length data records between two CPUs. Wrapping both blocks inside a single user function block (for example FB100) keeps the call surface compact, centralises the connection-ID, error handling, and status evaluation, and allows the application code to treat the S7 link as one logical channel.

The pattern works fine for scalar parameters (INT, BOOL, WORD), but breaks down when the application wants to expose a single ANY input on the wrapper and forward it to the inner SD_1 (FB12) and RD_1 (FB13) parameters. The reason is that the ANY pointer is not passed by value; STEP 7 stores it in the calling block's local stack and supplies the called FB with a cross-reference pointer to that local area. Direct symbolic assignment of an IN-OUT ANY to another IN-OUT ANY therefore fails silently: STATUS stays W#16#0000, DONE never sets, and ERROR never sets, because the inner FBs never see a valid source/destination area.

This article shows two production-quality methods for routing an ANY from the wrapper FB to the inner BSEND/BRCV instances: a TEMP-based byte copy and an AR2-relative direct read. Both rely on the multi-instance mechanism for the inner FBs.

Prerequisites

• STEP 7 V5.4 or later (the STL examples use the classic AWL syntax). For TIA Portal V16+ the same logic applies; the BSEND/BRCV instances are dragged from Instructions > Communication > S7 Communication.
• S7-300 or S7-400 CPU with a configured S7 connection in NetPro / Devices & Networks. See the official application example at How do you configure and program an S7 connection and the "BSEND" and "BRCV" instructions.
• Standard Library blocks: FB12 BSEND (multi-instance capable), FB13 BRCV (multi-instance capable), FB15 PUT (optional, for asymmetric variant). Confirm availability in the PCS 7 environment per What should you watch out for when using the blocks BSEND and BRCV in the PCS 7 environment.
• For S7-1500 / S7-1200 G2, use the TIA Portal example at Program example for BSEND & BRCV (S7-1500, S7-1200 G2); the same encapsulation logic applies because TSEND_C/TRCV_C in TIA V16+ accept the ANY pointer by reference and the wrapper pattern transfers unchanged.
• Working knowledge of address registers AR1 / AR2 and the local stack layout described in Programming with STEP 7 V5.4, Appendix A.3.4.5.

How STEP 7 Stores the ANY Parameter

When the OB1 calls FB100 with a literal ANY such as P#DB1.DBX0.0 BYTE 5, the compiler emits a 10-byte ANY constant and parks it in the calling block's TEMP area. The first 4 bytes of the called FB's local stack contain the cross-reference P#Lx.0 pointing to the 10 bytes. Inside the FB, the formal parameter DataArea is therefore accessed through that 4-byte descriptor; it is not a direct pointer to the data area.

To pass that ANY to the inner BSEND/BRCV instances, you must copy those 10 bytes from the calling block's local stack into a TEMP ANY in FB100 and then assign that TEMP symbolically to SD_1 / RD_1. A direct wire from DataArea to SD_1 does not work because both parameters are formal IN-OUTs and the compiler cannot chain cross-references of equal depth.

The AR2 Trap in Multi-Instance FBs

STEP 7 uses AR2 to store the multi-instance offset of the currently executing FB. As soon as you touch AR2 in your own STL without saving it first, every subsequent symbolic access to instance-DB variables resolves to the wrong offset. The official Siemens FAQ on register/ACCU handling documents the full set of opcodes that overwrite AR1, AR2, and the accumulators:

• Which operations overwrite the content of ACCU or registers in STEP 7?
• How do you parameterize blocks, which have "ANY"-type or "Pointer" type parameters?

Save/restore AR2 around any direct register manipulation, or stay inside the LAR1 / T W[AR1,P#x.y] idiom that the compiler can supervise. Solution 1 below uses the safer idiom.

Solution 1: TEMP ANY with Byte-by-Byte Copy

Add a single TEMP ANY in the wrapper FB and copy the 10 bytes from the formal parameter's local location to that TEMP. Then assign the TEMP symbolically to the inner instances. This is the recommended pattern because the compiler can still relocate AuxAny without breaking the code.

FB100 declaration (top portion):

FUNCTION_BLOCK FB100
TITLE = 'S7 Communication Wrapper (BSEND + BRCV)'
VERSION : '1.1'

VAR_INPUT
  DataArea : ANY;          // Source/Destination ANY from caller
  ID        : WORD;        // Connection ID from NetPro
  R_ID      : DWORD;       // Request ID, must match on both sides
  REQ       : BOOL;        // Rising edge starts BSEND
  EN_R      : BOOL;        // Enable BRCV reception
END_VAR

VAR
  BS_inst   : BSEND;       // Multi-instance: FB12
  BR_inst   : BRCV;        // Multi-instance: FB13
  DoneX     : BOOL;
  ErrorX    : BOOL;
  StatusX   : WORD;
END_VAR

VAR_TEMP
  AuxAny    : ANY;         // Working copy of the caller ANY
  SaveAR2   : DWORD;       // AR2 save slot (only for Solution 2)
END_VAR

Network 1 - Copy the 10 bytes of the caller's ANY into AuxAny:

      L     P##DataArea        // Pointer to the IN parameter descriptor (4 bytes)
      LAR1                      // AR1 now points to the 4-byte cross-reference
      L     P##AuxAny           // Pointer to the TEMP ANY (10 bytes)
      LAR2                      // AR2 -> AuxAny (touched AR2, restore later!)

      L     W [AR1,P#0.0]       // Syntax ID + length high word
      T     W [AR2,P#0.0]
      L     D [AR1,P#2.0]       // Length low word + DB number
      T     D [AR2,P#2.0]
      L     D [AR1,P#6.0]       // Area + byte address
      T     D [AR2,P#6.0]

The first 4 bytes of DataArea in the local stack are the cross-reference P#Lx.0. Indirectly reading with L W[AR1,P#0.0] therefore yields the first 2 bytes of the actual 10-byte ANY (skipping the cross-reference header). The displacements P#2.0 and P#6.0 map exactly to the ANY layout shown above.

Network 2 - Call BSEND with the working copy:

      CALL  BS_inst
        REQ   := REQ
        R     := FALSE
        ID    := ID
        R_ID  := R_ID
        DONE  := DoneX
        ERROR := ErrorX
        STATUS:= StatusX
        SD_1  := AuxAny          // symbolic assignment of the working ANY
        LEN   := 0               // 0 = use the full length from SD_1

Network 3 - Call BRCV with the same working copy:

      CALL  BR_inst
        EN_R  := EN_R
        ID    := ID
        R_ID  := R_ID
        NDR   := NDR_X
        ERROR := ErrorBR
        STATUS:= StatusBR
        RD_1  := AuxAny          // shared buffer for receive
        LEN   := LenRcv

Because both BSEND and BRCV read AuxAny symbolically, the compiler emits the correct cross-reference at call time. The previous failure (DONE=0, STATUS=0, ERROR=0) is replaced with a real status word such as W#16#0000 after the job completes or an explicit error code such as W#16#000A for an unknown connection.

Solution 2: AR2-Based Direct Forwarding (Advanced)

If you must avoid the TEMP copy (for example to keep determinism in a fast OB), forward the ANY by keeping AR2 intact and re-loading it from the instance DB after the manipulation. The block is rarely worth the maintenance burden, but is included for completeness:

      L     P##DataArea
      LAR1
      TAR2  SaveAR2              // save multi-instance offset

      L     W [AR1,P#0.0]
      T     W [AR1,P#0.0]        // no-op: shows the pattern only

      LAR2  SaveAR2              // restore multi-instance offset
      CALL  BS_inst
        SD_1 := DataArea         // now safe, AR2 restored

Any direct STL that touches AR1 with LAR1 inside a multi-instance FB must end with a matching LAR1 back to the instance offset, or the next symbolic access will corrupt the variable image. The two Siemens links above list every opcode that clobbers AR1 and AR2.

Diagnostics and Common Faults

For PCS 7 users, Siemens flags additional constraints: BSEND/BRCV must be called in OB1 (or a cyclic OB of the same priority class) at a defined interval to maintain the receive side, and the connection must be configured as S7 connection in NetPro, not as a TCP connection. These are detailed in the PCS 7-specific FAQ linked above.

Step-by-Step Commissioning Procedure

1. Open NetPro and create an S7 connection between the two stations. Note the ID shown in the connection properties (hex, e.g. W#16#0001).
2. Generate a new DB10 in the partner CPU that mirrors the data layout. Ensure DB10 length is greater than or equal to the highest DataArea length used in the application.
3. Create FB100 in the program, declare BS_inst : BSEND and BR_inst : BRCV as STAT (multi-instance), and add the TEMP AuxAny and IN parameters as listed in the declaration above.
4. Paste Networks 1-3 from Solution 1 into FB100 and recompile. The instance DB for FB100 will contain the BSEND/BRCV instance data automatically.
5. Call FB100 from OB1 with DataArea := P#DB10.DBX0.0 BYTE 20, the same ID from step 1, a matching R_ID, and a 1-Hz clock on REQ to drive the send.
6. Download both stations and place the partner CPU in RUN. Observe StatusX in VAT: a successful first send returns W#16#0000 and sets DoneX := TRUE for one cycle.
7. Trigger a receive on the partner by writing into its DB10 from a third station or an HMI script and watch BR_inst.NDR rise on the wrapper FB. LenRcv reports the actual bytes received.

Verification

Confirm correct behaviour with the following checks in VAT or with the online monitor:

• After REQ rising edge, BS_inst.DONE is TRUE for one OB1 cycle, BS_inst.STATUS = W#16#0000, and the partner's receive data block has been overwritten with the sent bytes.
• After the partner writes back, BR_inst.NDR is TRUE for one cycle, BR_inst.STATUS = W#16#0000, and the wrapper's DataArea shows the new values.
• Force a wrong ID (e.g. W#16#00FF): BS_inst.ERROR must rise and BS_inst.STATUS must read W#16#000A (unknown connection) or W#16#0001 (low-priority setup fault) - this proves the wrapper is actually executing the inner FB and not returning a frozen zero status.
• Cross-check the DI monitor on the instance DB of FB100: the AuxAny TEMP is volatile and invisible in the instance DB; only the multi-instance data of BS_inst and BR_inst must appear.

Performance and Stack Depth Notes

Copying 10 bytes per call adds roughly 0.5 microseconds of OB1 time on an S7-315-2 PN/DP and is below the 1 ms jitter threshold for cyclic communication. The TEMP footprint is 12 bytes (10 for the ANY plus 4 for the cross-reference pointer, aligned). For a wrapper that fans out to N parallel BSEND/BRCV pairs, allocate a separate AuxAny per pair; do not reuse one TEMP across calls because BSEND and BRCV both read the ANY asynchronously between OB1 cycles.

The local stack depth of OB1 grows by the sum of TEMP usage of all FBs in the call chain. Adding 12 bytes to FB100 is negligible on S7-300 (default 256-byte local stack per priority class) but should be measured on S7-400 CPUs in heavily nested OBs.

Migrating to TIA Portal and S7-1500

On S7-1500 with TIA Portal V16 and later, BSEND and BRCV are available as BSEND / BRCV instructions in the Communication > S7 Communication palette and accept ANY parameters through their SD_1 / RD_1 inputs. The wrapper pattern translates directly: declare an InOut of type Variant on the wrapper, convert to ANY via VariantToAny (SCL) or the legacy byte copy (STL), and assign to the inner instructions. For S7-1500 firmware V2.5+ you may alternatively use the optimised TSEND_C / TRCV_C blocks, but they are TCP-based and not drop-in replacements for the S7-connection semantics of BSEND/BRCV.

The TIA Portal sample at Program example for BSEND & BRCV (S7-1500, S7-1200 G2) shows a full two-CPU project that compiles against the same wrapper contract described in this article.

Safety and Operational Caveats

Multi-instance FBs that use AR2 for parameter passing must be compiled in the same OB priority class as their caller. Mixing priority classes (for example calling FB100 from OB35 and from OB82) is legal but each caller must use its own instance DB; the multi-instance offset is stored per instance, not per call site.

FAQ