Hello! This problem occurs from time to time, so it must not be a software, but hardware or some limits that i don't know. 

The system contains one 414-2 DP controller with CP 443-1 as a "master" PLC that puts (SFB15) orders and gets (SFB14) statuses from three 315-2 DP PLCs with CP 343-1. Data is separated by purpose in 5 FB's. First is for PUT, that works by a bit, other 4 are for GET, different data collected in different cycles of time (10, 30, 45, 60 seconds). If it's matter it is possible that several PUT's activate during one scan, but this code works for years and there are 3 slave PLC's with the same data exchange code (one PLC exchange after bit NDR=1 of previous's) but I have problem only with one of them.

So the problem is that I can't collect or send data to one of the "slaves". Status freezes at "19" even when the REQ bit is already "0". It is always one particular PLC, but I can't find out what is wrong. PLC has no problems, CP is available and o.k., I can reach online blocks of PLC via Ethernet. The HMI panel works fine. I also noticed that some other status blinks at the moment of REQ=1, and caught it. It is "B"(11), so it's normal in my situation. I also tried to switch all REQs to 0, deleted all statuses by downloading instance DBs and switched one REQ  to 1. Still status "19" showed up and froze.

I've tried to replace CP, did not worked. Stop/run of CPU and CP don't help either. Temporary win is switching off and on power from controller+CP. After that everything works. But you can never predict for how long. Sometimes it's minutes, sometimes weeks and months. Should I try to replace controller? I have searched in all properties and now I have no clue what can be wrong.

Tell me if any screens or additional information is needed.

And sorry for my English if there are mistakes, it's not my native.

Thank you!

update. There is one more thing that is happening when such freeze occurs. The HMI pannel TP 277 10' of a master PLC (connected via DP) is restarting time to time (pretty frequently, maybe 1-2 times in an hour, but can't exactly). Sounds like nonsense but it happens only in a pair with data exchange problems.

Thank you for your reply!

1. I don't think it is noise, wiring and grounding are made well, very professional (almost all equipment is made by one good big German company). The equipment is pretty old, but worked well for years. No big changes and new wires were set on the equipment.

2. Yeah, it sounds fair, but still, somehow this worked without problems for many years, why did it start to freeze, and why is it only one particular PLC-partner? I think get/put call it is not the answer here.

3. I cant really recall exactly what was the status, but i think it was like it is now when everything is working.

The slave PLC (reserved/occupied):

PG comm. 1/1, OP comm. 3/2, S7 basic comm. 10/0, Other comm. --/1;

Master PLC:

PG comm. 1/1, OP comm. 1/2 (how is it possible?), S7 basic comm. 4/4, Other comm. --/0;

.... oh, maybe that's the problem and i should increase communications on master? But i think 414 CPU has no such options and it opens new connection by itself, but i cant say for sure (i'll try it later when equipment will be in stand-by.)

4. OK, I'll make a cage for several errors (because for one the result is always "11")

Once again thank you for your help. I'll write here later when I have some new information.

Hi,
Why a particular PLC?
The PLC is the partner. Its operating system is responsible to answer to the GET/PUT requests.
It might be that the PLC is busier than the others, or has a very short cycle time, or the % of the cycle reserved for communication load set in HW config is low, ... 
Even an older FW version can make things different.

Freeze is in most of the case a deadlock happening with overload.
It is bad to trigger again a job that is still running.
Should be part of your interlocks.

If you run several jobs over the same connection, be sure not to start them all together at the same time.

Hi,

This PLC is really busier than others, more data collected from it. Configured cycle load due to communication is 35% (20% in other partner-PLCs). Still I think it is worth trying to increase this number. 

FW is the same at all HW, all partners were bought and set at one time.

Also I will think about making new interface code to avoid possibility of triggering data transfer twice at the same time.

Thank you a lot for tips and advices!

Hi!

Some new info. I found out that as you said in first reply there must be something with communication. As I wrote it down:

"The slave PLC (reserved/occupied):

PG comm. 1/1, OP comm. 3/2, S7 basic comm. 10/0, Other comm. --/1;"

So, when the problem appears the connection is lost! Slave PLC has "Other comm. --/0". That must be it. Now what I need to do is to find why a connection can be lost by a PLC. Seems to be not very easy, but at least I see the direction I should "dig". 

update. There are more things that can help to figure it out. In NetPro, master PLC has 4 comms. Only one has TCP connection, others have MPI. So for Ethernet partnership there must be a connection created at both PLCs. And i found that at the slave PLC a connection status is red even when data transfer is working. I find this very strange. I attach screens.

Also, these PLCs are in pretty big network, I wonder what if there is some other device that is not always on, but has the same IP with controller (or has dhcp option), would this cause such problem or not. I also try to check it. 

I'll be happy to read all thoughts about it.

Thank you.

Ok, the problem is solved. Somehow I thought it was the least chance but It was all about power supply. As I  mentioned there was a problem with rebooting OP while disconnections. So that was it. A sitop power supply of OP has gone mad and even after switching off by switch it has powered on again by itself making noises. So after replacing it all problems with data transfer has gone. Probably PS made power line to suffer, so all ethernet switches that were supplied from it had problems. 

Hope my experience will be helpful for someone. 

Thanks all for help. See you.

Hello, I had the same problems, the simple solution for me was to stop the Cp card and start again, then the communication worked again.

S7-1215, TIA18

Same problem

Souce of the problem: I startet the FB "GET" from 2 Tasks, one time from OB1 one time from OB31 accidentelly. After 5-20 readings the FB "GET" stopped with STATUS=16#0019 and no other error.

The communication was not restartable by resetting communication or other user reactions, only restart the controller helped.