How to achieve simple communication between PLCs

I have no answer for you over why the establishment of communication should be as complicated as it is. You will need to confront a knowledgeable person at Siemens.

Have a look at the following library collection..
Libraries for Communication for SIMATIC Controllers

Mixing Modbus/TCP with other communication protocols on one physical port is not a problem.

We have changed over from Put/Get to Ethernet TCP for our communication needs. I appreciate the fact that we are able to connect and disconnect the link and reuse resources. Though our networking is not as complicated as yours.

alanTI

qwazee

Mixing Modbus/TCP with other communication protocols on one physical port is not a problem.

if I use modbus TCP with third party PLC and RTUs it always works flawlessly. if it is all siemens S7 stuff there are some bugs after downloads and connectivity disruptions. It works but I wouldn't trust my life on it. Something with tcp connection not closing properly.

You are right about that. There has been changes on Siemens' side on that issue. But I have lost track if the solution was implemented on some S7-1200 firmware.

Might I recommend using UDP rather than TCP for point-to-point communications.

Provided there is no hardware in between that can absorb and not forward the UDP packets, you can be very successful.

UDP will blindly send forever even when nothing is receiving.  Never get TCP connection failures.

Just create your own "protocol" for ensuring both ends are online and communicating.

Things like watchdog sending and monitoring on both ends, and how you need to handle a persistent watchdog failure - like sending an email or text message or whatever might be appropriate.

Or, if you have lots of these remote stations, have them all coordinate through a single centralized PLC that has human visibility - like an HMI or Web page showing what remote stations are online, when the last transmission was received, that sort of thing, and perhaps background color Green - watchdog working for that remote device, Yellow for intermittent watchdog, and Red for persistent Watchdog.

All kinds of ways to get fancy with it, but keeping stats inside each PLC that also gets sent to each remote station it connects to, so it gets shared for better visibility.  The more visible things like reaction time from yellow / red to green - indicating someone noticed, then took action and corrected the problem, the better your uptime will be and the easier it will be to keep working smoothly.

It is amazing how small details like that can impact the workplace attitude and actions.  Some peer pressure, some appreciation for being informed, some management pressure (to keep metrics or KPIs good), and some just the desire to do a good job, and probably a few other outside influences I don't think of.

Once worked in a factory where bonuses were awarded based on some KPIs (stats produced by the PLCs).  People started asking for improvements in communicating state changes on the factory equipment.  We added speakers, amplifiers, text-to-speed generated messages played over the local area speakers letting people know a specific machine just went down, or something similar.  Paid for itself in 2 months.

alanTI

Gustavo Antonio Banchetti Brucatori

do two PLCs that are not on the same LAN and presumably not even at the same site need to exchange data (even if it's just a small amount) directly?

In the field of water management it is becoming essential, as reservoirs are often kilometers apart. the need of communication can in most cases be reduced to 2 bool "need water" and "heartbeat".

Back in the old days it was all buried cables with discrete signals, but this was not very thunderstorm resistant. then came bus cables, more flexible than discrete and slightly more thunderstorm resistant, since it is easy to decouple the wires. Then came fiber, but if you are not creating new pipes it is prohibitively expensive to make a brand new buried line.

These days, unless it is a critical infrastructure, we just use mobile network, because we need remote supervision anyways, might as well use the link to communicate.

As for the "directly" part, in my opinion it comes down to k.i.s.s. I do not want some cloud or scada connecting the remote stations. 

qwazee

Have a look at the following library collection..
Libraries for Communication for SIMATIC Controllers

I do already use this library, just never bothered to look at all the instructions, looks like LCom is flexible enough and not too much of a problem to implement.

qwazee

Mixing Modbus/TCP with other communication protocols on one physical port is not a problem.

if I use modbus TCP with third party PLC and RTUs it always works flawlessly. if it is all siemens S7 stuff there are some bugs after downloads and connectivity disruptions. It works but I wouldn't trust my life on it. Something with tcp connection not closing properly.

qwazee

We have changed over from Put/Get to Ethernet TCP for our communication needs.

@qwazee may I ask what implementation of tcp communication? Custom function using basic blocks, tsend_c/trcv_c,  LCom or something else?

Willybong

If the PLC is quite newer, you could try an OPC UA communication.

I have already looked into it, it looks like the future will go in this direction, but for today I cannot implement it between 2 1200s. Also I dislike doing things in hardware configurations, I feel like I depend too much from Siemens. If I code something completely in SCL there is a high likelihood that I will be able to replicate it in any other PLC.

Thank you all for your interest and suggestions!

I think it is worth the effort to - upon receiving error 16#80A1 - to disable sending data, and delay a new attempt until the UDP connection has been established.

Which Siemens Library did you pull "UDPtemplate" from?

alanTI

For the moment I have decided to implement the UDPtemplate from the communication library offered by Siemens. I have left it completely as-is, and it worked on the first try.

What I like:

- no errors if partner is offline
- very quick to connect and disconnect
- seems robust enough, tried messing with RUN/STOP, dropping links, changing configuration on the fly, ...
- most of the times I got it stuck after downloading modified software i got it running again simply by reinitializing the DB

What i don't like:

- seems obtuse having to map bytes in 2025, but i can live with it
- the 80A1 error, where the only solution I found is RUN/STOP/RUN (happened 3 times on an entire workday of testing) this is not really a problem with my implementation but more generalized to all TCP OUC. sometimes a badly closed connection just remains in limbo.

here is my implementation of 2 connections in one PLC, I am open to suggestion/critics:

#comm_trig(IN := not #comm_trig_q,

           PT := #send_interval,

           Q => #comm_trig_q);

if #comm_trig_q then

  #UDP1.send := true;

  #temp_ser_pos := 0;

  #temp_int := Serialize(SRC_VARIABLE := "UDP_data".to_rmt_1,

                         DEST_ARRAY => #UDP1_snd_buffer,

                         POS := #temp_ser_pos);

  #UDP1.sendLen := DINT_TO_UDINT(#temp_ser_pos);

elsif #UDP1.instTUSend.BUSY then

  #UDP1.send := false;

end_if;

if #comm_trig_q then

  #UDP2.send := true;

  #temp_ser_pos := 0;

  #temp_int := Serialize(SRC_VARIABLE := "UDP_data".to_rmt_2,

                         DEST_ARRAY => #UDP2_snd_buffer,

                         POS := #temp_ser_pos);

  #UDP2.sendLen := DINT_TO_UDINT(#temp_ser_pos);

elsif #UDP2.instTUSend.BUSY then

  #UDP2.send := false;

end_if;

//communication reset in case of error

if #UDP1.error or #UDP1_en = false then

  #UDP1.enable := false;

elsif #UDP1.statFBState = 0 and #UDP1_en then

  #UDP1.enable := true;

end_if;

#UDP1(connParam := #UDP1_para,

      rcvdData := #UDP1_rcv_buffer,

      sendData := #UDP1_snd_buffer);

if #UDP1.ndr then

  #temp_ser_pos := 0;

  #temp_int := Deserialize(SRC_ARRAY := #UDP1_rcv_buffer,

                     DEST_VARIABLE => "UDP_data".from_rmt_1,

                           POS := #temp_ser_pos);

end_if;

if #UDP2.error or #UDP2_en = false then

  #UDP2.enable := false;

elsif #UDP2.statFBState = 0 and #UDP2_en then

  #UDP2.enable := true;

end_if;

#UDP2(connParam := #UDP2_para,

      rcvdData := #UDP2_rcv_buffer,

      sendData := #UDP2_snd_buffer);

if #UDP2.ndr then

  #temp_ser_pos := 0;

  #temp_int := Deserialize(SRC_ARRAY := #UDP2_rcv_buffer,

                     DEST_VARIABLE => "UDP_data".from_rmt_2,

                           POS := #temp_ser_pos);

end_if;

 ...in my production code there are more comments and the tags are more descriptive =)