 | 1 | initial version |
Thanks for providing pcap files @casper, the pattern in them is very interesting. First of all, it is not a memory problem on the Robot. As you demonstrated with FTP from a CMD window (according to the file name), the whole file can be sent to the robot. In fact, the PLC is also capable of sending the whole file to the Robot, but while it is doing this some problems with the control connection arise.
The Robot takes some time to process the received data, you can see this by the shrinking receive window (tcp.window_size). This happens in both the CMD and the PLC uploads. But each FTP/TCP implementation is dealing with this differently. While the CMD is waiting for enough room to send a full MSS (1460) bytes, the PLC just fills up the last bit of the receive window (hence the Window-full/Zero-window expert info messages). All in all, the processing of the data by the robot takes ~17 seconds.
During the slow transfer, it seems the PLC control channel has reached a timeout on hearing back that the file transfer was complete and it tries to close the control channel and also tries to open a new control channel (which does not make much sense, as the data channel is bound to the first control channel).
I'm not familiar with PLC programming and/or Beckhoff function blocks. But I hope there are some settings that you can change. I would look for timeout settings in the FTP function block and increase the timeouts on the control channel to 30 seconds or even higher, depending of other large data transfers that might be needed between the PLC and the Robot.
I hope this makes sense, it would have been a bit easier if the FTP commands were not stripped away by the anonymization, as they might have "documented" what was happening a bit more I guess :-)
