Communication between CPU’s can be done in different ways, we’ve already covered Put/Get. BSEND/BRCV gives you a little more control over when you want to receive information and when the sender wants to update information.
🎯What’s In This Post?
↗️BSEND Interface
The interface for the BSEND function block is not too dissimilar to the PUT function block:
- REQ – On positive edge, sends the data in SD_1 to the partner located at ID
- R – When
True
, resets the connection between the partner CPU - ID – The ID of the partner
- R_ID – The ID of the Pairing between a BSEND/BRCV
- SD_1 – Pointer to the data that is to be sent (in this example, we’re just using a single variable)
- LEN – The length of the data to be sent. This allows for partial sending of structures for example. (If 0, all data is sent)
↘️BRCV Interface
he interface for the BRCV function block is not to dissimilar to the GET function block:
- EN_R – Enable receiving of Data when
True
- ID – The ID of the partner
- R_ID – The ID of the Pairing between a BSEND/BRCV
- RD_1 – Pointer to the receiving area in which the data will be placed
- LEN – The length of the data received
🔒Additional Tip
[membership level=”4,1″]
It’s a good idea, when using the R_ID field, to start your pairing numbers at the same number as the ID.
In this example, our ID is 16#100
and our R_ID is 16#100
. If we wanted to add a secondary paring of information for this PLC setup (between the same CPUs), we could then use 16#101
as the next R_ID.
If we wanted 1 of the CPUs to talk to a 3rd PLC, we could use the ID of 16#200
and repeat the process using a pairing (R_ID) if 16#200
.
This approach helps save confusion over what the R_ID is used for and keeps it relative to the pairing
[/membership]
[membership level=”-4,-1″]
⚠️ Membership Required
[pmpro_checkout_button class=”pmpro_btn” level=”4″ text=”Become A Lifetime Gold Member”]
🔒What Am I Missing Here?
A tip about how to handle R_ID for multiple pairings between 2 controllers
[/membership]
🧠BSEND/BRCV Logic
BSEND/BRCV work in pairs. Without a corresponding pairing, no information will be sent or received.
Because of this pairing, both sides of the communication setup can decide whether or not Sending / Receiving is possible at any one particular time.
For example, in the below short video, we can see that the GET_DATA.Counter
variable is incrementing in PLC_1, and the SEND_Required
variable is True
on the REQ
interface of the BSEND function block, but the information is not being received in PLC_2.
This is because the EN_R
(Enable Receive) interface in PLC_2‘s BRCV function block is set to False
However…
Even when we then set EN_R
to True
in PLC_2, no update occurs to the GET_DATA.Counter
variable in PLC_2 (on the RD_
1) interface…
This is because the BSEND‘s REQ interface is triggered on a Rising Edge Only. You must set it to False
again between requests to send information.
Once the REQ is set to False
and then back to True
, the information updates
Note: The PLC is scanning and updating the value all the time, hence a small discrepancy between the two PLCs
We can see that the GET_DATA.Counter
in PLC_2 has now updated.
🗃️File Download
[membership level=”-4,-1″]
⚠️ Membership Required
[pmpro_checkout_button class=”pmpro_btn” level=”4″ text=”Become A Lifetime Gold Member”]
🔒What Am I Missing Here?
Buttons to download the PLC project and associated PLCSIM Virtual Memory Cards
[/membership]
[membership level=”4,1″]
[/membership]