QUESTION:
Why isn't it useful to realize BRCV or URCV with an instance via multiple communication connections?

ANSWER:
The communication services BSEND/BRCV and USEND/URCV are bilateral communication functions that enter a 1:1 connection with each other. This is why a BSEND is always assigned to exactly one BRCV via one S7 connection. The S7 communication functions (SFBs) are realized on the S7-400 controllers in such a way that the input parameters ID and R_ID cannot be changed dynamically in the program, but always belong to one specific instance DB.

The dynamics of the downloadable communication functions for S7-300 controllers is different: an instance (DB) is fixed for only one communication task and then it can be used for another partner, i.e. S7 connection. This is practical in particular for the S7 functions PUT/GET in order to be able to address several partners with one instance.

This is more complicated for the S7 functions BSEND/BRCV and USEND/URCV. Here you could implement dynamic use of the instance DBs for the Send blocks BSEND/USEND. However, this is not possible on the Receive side, because you cannot foresee exactly which S7 Communication would like to send.

This applies also for parallel communication functions for an S7 connection that are realized with the parameter R_ID (task reference). There is no point either in using a single instance in this variant of the S7 Communication.

Keywords:
Downloadable communication, URECEIVE, BRECEIVE,
SFB8, FB8, SFB9, FB9, SFB12, FB12, SFB13, FB13, SFB14, FB14, SFB15, FB15