Sometimes takes 5-10 trials get a stable connection

[lio94]

I notice it sometimes takes 5-10 tries to establish connection, returning different errors, mostly "CLI: Client not connected". This seems happen more likely on the S7-300s and when my application has been closed and restarted (works fine after a complete reboot of the computer).

Task.Factory.StartNew(() => {
  int err = client.ConnectTo(IPAddress, Rack, Slot);
  if (err == 0)
  {
      Connected = client.Connected;
      client.ReadArea(S7Area.DB, InputDB, 0, InputDBSize, S7WordLength.Byte, InputDBBuffer);
  }
  else
  {
      Connected = false;
  }

I was wondering if this is somehow related to not properly handling Sockets and their connection status? #4

Is there an established pattern/guideline on how to bind the connection, and what all possible error checks should be incorporated?

[fbarresi]

Hi!

I don't think it could be related to #4 . The return code after the connection attempt should confirm the connection state to you.

The error message tells you the client you are using for reading/writing stuff is actually not connected.

I see you run the connection in a Task: did you check if you attempt to connect multiple times with the same client? Did you use the correct rack and slot configured in the PLC?

Any relation with a clean pc reboot let me just guess some resources might be not correctly disposed: you might try to analyze the object with a memory profiler. If you have multiple undisposed open sockets, the PLC might let you connect up to a max number of clients.

If I were you, I would try to validate/debug your logic without a physical PLC, e.g. with SoftPlc.

Best regards, FB

[lio94]

Hi,

Thanks for getting back. SoftPlc looks really cool tool, but I have the possibility to test it in the field, which I think is always better :-)

I did not find a pattern so far, the problem seems a bit sporadic. Most of the time the first connection when restarting the app works. Which I find a bit odd, as both disconnecting the connection inside the app and when closing the app, client.Disconnect() is called which should dispose of the socket and make it free for reuse.

I have understood that the rack and slot are always 0 and 2 in my case, as I connect to S7-300 CPUs. I also have commented out the asynchronous TCPPing() from the client.Connect() method to make sure it is not causing some sort of unintended double connection.

The problem persists. I get a random number of "An existing connection was aborted by the host computer under software control" exceptions happening at TCPSocket.Send(Buffer, Size, SocketFlags.None), followed by S7 errors Error 7 (errTCPDataSend) and Error 9 (errTCPNotConnected), before finally getting a stable connection.

Could be related to https://github.com/fbarresi/Sharp7/issues/3 ?

I feel like commenting the TCPPing() out and calling Close() always when a read error occurs (as suggested in #3) made the behavior better, but I still get occasionally the same error behavior. Here is my logs of the problem:

26.09.2024 11:02:29;WaitForData;Timeout occured!
26.09.2024 11:02:29;Send;Eine bestehende Verbindung wurde softwaregesteuert
durch den Hostcomputer abgebrochen
26.09.2024 11:02:29;Send;   bei System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   bei Sharp7.MsgSocket.Send(Byte[] Buffer, Int32 Size)
26.09.2024 11:02:29;Error;7
26.09.2024 11:02:30;Error;9

So it seems to be a timeout happening inside WaitForData: if (Expired) { S7.WriteLog("Timeout occured!"); LastError = S7Consts.errTCPDataReceive; } My _ReadTimeout parameter is 2000 milliseconds.