Hello,

really it is hard to remember what FC5 and FC6 are, it is better share names of blocks also. So you didn't have problems previously? This is common problem - not good test of prj for many possible situations especially ETH cable disconnection Shifting is also more possible in situations where data are comming shorter or longer than expected, better say how long is buffer defined. This is also problem, dynamic length of data exchange. I recommend to you to do simple test, ommit at tests everytime one PLC with PC app that simulate it (Hercules can be used) to see what really data are exchanged or received from specific PLC. Believe me, you can be really impressed what steps you maybe forgot to test previously

Sry, yes, you can use ISO if you want.

Hello,

if version is the problem is hard to say. In my shoes I'll try put that PC app instead of PLC2 to see exactly PLC1 sends 84 bytes. As I recommended previously, then you can do same with PLC1, here set Hercules app and send 84 bytes cyclically to PLC2 if all is ok. Now is simply important to maybe play with same system of comm procedure you have between both PLCs, this I don't see and don't know. Logically, if you didn't change something and your report about functionality previously is ok, then RCV block version isn't problem. Really is hard to say, reports that 'it was working previously ok' are very strange and says nothing to give proper help. Did you tried that ETH cable disconnection what will happen on both sides? Maybe here you need to do some procedure to check this situation to continue ok. Maybe one side will stuck with some number of bytes. I expect simply functionality ok from start of PLC and after some event (ETH cable or other) is simply functionality broken at RCV side (PLC2). Simply, it looks like maybe that Pointer is still somehow set somewhere else or wrong info about LEN or still not received number to fill up full buffer is passed. Simply here then isn't output signal set correctly, only if recv buffer is filled with exact number of bytes and here can be problem. This working like this, this isn't AdHoc, this is only defined buffer length system that need to be filled to last number. Try also this, set recv buffer longer/shorter than 84 bytes what will happen but after that all tests. Really I don't know what else I can recommend to you. Carefully check all output parameters like DONE/NDR, STATUS, LEN,...

Update: I think again about your statement that it was working previously. It can be also that your system of execution of blocks are changed because of new code parts (cycle is higher) or isn't correctly handled. I mean and ask how you simply executing blocks. I mean also that important check of send finished and also same at other PLC is required prior to do next run. If you don't proceed with some correct handling of that it is possible that something changed within procedure. I don't know your situation so hard to help exactly.

Hello,

yes but therefore I said to you about this system that this isn't AdHoc but full stream system to fill only full expected buffer length. If not then this issue is occured. Also now I see that you did changes  as I expected, with different version of code so this is that problem also in case you did maybe wrong other changes inside code but this I don't know and it isn't clear because we don't know what you do inside your prj. This behaviour is only with use of CPs not with PN CPUs. As I also recomemnded already (because this behaviour is clear) to you, ISO can be used. With that recommended PC apps tests is then also clear where possible problem can be existing. With your old prj with send 62 bytes is then all clear as I said, your buffer with defined higher Pointer is not filled to full expected length and then it is shifted logically. You need have defined receive Pointer with length everytime expected same length and also with same send length. My experience is better using S7-1200 with TCP/UDP tasks or use PN port CPUs (S7-300/400 and also ET200S CPUs) where this is working ok and no with same behaviour. Read pls again my posts where all is clear how it works.