Dear All,

There is an option of establishing communication between 2 PLCs using ethernet or MPI in which  SFB14 and SFB15 are used in programming.A partner ID is set in Netpro.I hope you have understood that which type of communication I am discussing about.

Now my question is

1. In this communication sfb14 and sfb15 is used in any one plc between the two.In that plc wherer sfb14 or sfb15 has been used it is easy to search that which are data that are communicating.

But in the other plc where these blocks are not used, it is not possible to understand which are the data that are going to the other plc and which are the data that are coming from the other plc. So sometimes it becomes very comfusing for some data that we can not understand that from where they are coming.

suppose in my plant I have 10 plc. so the data can come from any of them. so it is almost impossible to find the origin of the data

What is the actual procedure to handle this kind of situation.

2. I read in some places that there is not any difference betweeen MPI and profibus except the speed. Profibus can support much more higher speed than MPI.

but why this type of plc to plc communication (using sfb14 and SFB15) can only be done in MPI. Why profibus doesnt support this. We know that to establish PLC to PLC communication in Profibus, DP coupler is needed.But why in case of MPI any similar device like DP coupler is not used?

Regards

Swagata

Hello,

To clarify, SFB14 and SFB15 belongs to the functions available in S7 protocol (among other functions), where SFB14 is a GET function (read data in the partner) and SFB15 is a PUT function (write data in the partner). An exemple is here:
Sample program: S7 communication with the blocks SFB14 ("GET") and SFB15 ("PUT") with S7-400

These S7 functions can be used on MPI, Profibus, Industrial Ethernet (Profinet) networks.

When using GET and PUT, the PLC is acting as an S7-Client (system having initiative), the partner is acting as S7-Server (system answering to PUT/GET requests).
I agree that no explictit function call is needed at the server side, because the operating system of the S7-server handles everything without user program. And therefore it becomes hard to know when the S7-Clients read/write in the partner.

Now, to use PUT and GET, you need an S7 connection. And you have several options here.
1) If the s7-client connects to the special resource 03 at the partner, here again, no connection data required at the server side (only the client is to be loaded with connection data). The server will accept the connection, as long as enough s7 resources are available. And you have the risk that you depicted. Newer models (S7-1200 and s7-1500) have a check box in their recentt firmware "allow put/get" so that you have the option to protect the PLC from external write operations.
2) if the S7-client connects to a dedicated S7-connection resource at the partner, both systems have a connection description (you must load both systems with connection data). You still can use PUT and GET but now also other functions like BSEND or USEND.
Interesting with two latest functions is that now you need a BRECV or URECV block in the partner.
And these functions have two features you asked for: a conenction ID (you know who is the partner), a destination for the data (you tell where the sent data goes), and a bit New Dat Received (NDR). NDR informs the program that new data was sent by the partner.
You can even enable or disable the reception for the time needed to handle the previous received data with the signal EN-R at the reception block.
An example is here: How do you program communication blocks FB12 "BSEND" and FB13 "BRCV" for data exchange in the S7 program of an S7-300 CPU?

Solution 2 is more secure. However, because both partners must make changes, solution 1 was very popular (no changes required at the partner).

Hello,

another addition, to communication between 2 PLCs via Profibus you don't need DP Coupler. So maybe you need check documentation about Coupler functionality/requirement. I think you must also think about basic example of 'real' Profibus where one PLC acts as Master and f.ex. distributed stations with I/O as Profibus Slaves signal terminals are exists on bus. In this case Master sets signals via Profibus to distributed I/O of Slaves only like they are exists on PLC rack modules, in basic principle no other exchange of communication between Slaves exists. Also no SFB14/15 are used in this situation.