News:

  • October 13, 2025, 07:37:25 PM

Login with username, password and session length

Author Topic: OPENTCP Timeout setting  (Read 1257 times)

johnr

  • Full Member
  • ***
  • Posts: 44
OPENTCP Timeout setting
« on: August 15, 2022, 04:59:28 PM »
Is there a way to read and/or set the time period before the On Error Set Bit will trigger on OPENTCP failure?  It looks to be about 15 seconds but I don't see anywhere in ladder logic or in configuration settings where this value can be accessed. 

I don't need to change it - I have my own timeout in ladder logic that triggers faster than the instruction does, but I did want to know if the built-in timeout can be tweaked by someone else, thereby affecting my intended response.

ksasikumar

  • Full Member
  • ***
  • Posts: 33
Re: OPENTCP Timeout setting
« Reply #1 on: September 01, 2022, 10:52:35 AM »
This would be helpful to me as well - in my case I want to increase the timeout so that I get less warning messages on the PLC.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6126
  • Yes Pinky, Do-more will control the world!
Re: OPENTCP Timeout setting
« Reply #2 on: September 02, 2022, 04:08:14 PM »
It is hardcoded into the IP stack and there is no current way to change it. The default was 120 seconds (if memory serves) which was painfully long and could result in significant amounts of IP stack resources getting tied up. We shortened it because if a TCP connection doesn't establish in 15 seconds it's very rare that longer will be any better. I guess some forms of unreliable network hardware (radios, for instance) might take longer, but in the current era 15 seconds is a long time for network comm. I'd say it would be possible to make it configurable, although it would require modifying the stack, which is something we are pretty reluctant to do.

BTW, all of those warnings in DST or ST can be cleared by logic. If you are aware of the significance of the result and don't see a need to show the warning or error from DmD, just clear it from logic. Best practice is to handle both success and failure, so just clean it up in the error handler.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO