Siemens 319F-3 PLCs communication over Ethernet

Currently I have two (three in the near future) 319F-3 PN/DP CPU's that need to communicate.
PNPN couplers are not possible because of distance.

I currently use TCON - FB65 method with FB63/64 to send / receive data.
This function does work.

I previously used the SFB12 + 13 method by setting up the S7 connection inside Netpro on another project. Now is this method more secure?

I just need the more bulletproof option

When you ask which would be more "secure", what aspect of security are you referencing? What is your security concern?

Neither method is encrypted normally. Neither protocol has any authentication built in, although Bsend/Brecv has a small amount of security by obscurity in it's favor. I think you may get some real security options with the CP343-1 Adv, where you can do communications over a VPN.

If by "secure" you mean "which method is less likely to fail" then I'd have to say I'm not sure. I'd probably consider them equal. In general, once they are working, I haven't seen them stop, unless there is a network failure.

By secure I meant not likely to fail And when it sends data, it is accurate.

I can do more test on the current implementation as I don't want to have to download hardware again if not needed.

Is the path between PLC's redundant?
I think either the BSEND/BRCV or AG_SND/AG_RECV are good enough. Something that is worth adding is a rolling counter or hearbeat to detect failure.

One thing that I did pick up on from the manuals is that using PUT and GET for communication between PLC's doesn't take into account the running state of the PLC. Meaning that you can program the comms with these functions, set one PLC to stop and the functions will continue working without throwing errors on the running PLC. Hence why I now always add a rolling counter (just in case).

If it's about failure resistance it makes no difference, as all type of communication you have mentioned are using Ethernet and TCP.

The Ethernet CRC check can detect up to 5 independent bit erros (Hamming distance of 6). If the CRC is wrong, then the packet is discarded, and the TCP does the automatic retransmission of the lost packet(s). And TCP ensures that the packets are received in the same order as they were sent.

To detect a loss of communication, I would add a lifecounter to the transmitted data which is incremented each second (or whatever you need).

Thanks for the advice, would add an extra life counter as suggested

The only difference I really then saw is that with the BSEND method, is that it can send more data, which I don't really need.

I would say that that depends on if you have configured Tsend with ISOOnTcp or TCP/IP. TSEND can use either IsoOnTcp or TCP/IP i would say that IsoOnTCP is to be preferred in a Siemens world. TCP/IP is stream based and ISOOnTCP message based. So for tcp/ip there is no way to tell where the message ends if you don't use fixed lengths or handle that with end bytes or similar. Even if you use fixed lengths there can be a problem. You could end up receiving half of the old message together with half of the new which you don't want.

Tsend can handle 32767 bytes at least with the new firmwares so there is no length difference for a 300 cpu. There is however a benfit using BSEND if you only want to use one connection but have several partners since that is implemented in the BSEND protocol since that is above the IsoOnTcp protocol.