News:

  • November 07, 2024, 08:10:10 AM

Login with username, password and session length

Author Topic: Ethernet Failure - BRX Stops Communicating  (Read 9787 times)

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3700
    • Host Engineering
Re: Ethernet Failure - BRX Stops Communicating
« Reply #30 on: June 08, 2023, 02:36:41 PM »
Software Versions:
Do-more Designer: 2.9.3.30
Not related to your issue, but definitely get the latest Designer version (2.9.4) that fixed some bugs.

WRT2

  • Newbie
  • *
  • Posts: 9
Re: Ethernet Failure - BRX Stops Communicating
« Reply #31 on: May 30, 2024, 02:07:05 PM »
I am still running beta version 2.10.0 from last year to avoid Ethernet comm lock-ups. Is it now safe for me to return to a production OS?

Also I have one PLC that still has lock-ups as a Modbus slave. It is the only one that does not use the Ethernet port as a master.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6046
  • Yes Pinky, Do-more will control the world!
Re: Ethernet Failure - BRX Stops Communicating
« Reply #32 on: May 30, 2024, 02:18:48 PM »
I am still running beta version 2.10.0 from last year to avoid Ethernet comm lock-ups. Is it now safe for me to return to a production OS?

Also I have one PLC that still has lock-ups as a Modbus slave. It is the only one that does not use the Ethernet port as a master.

The most recent production has all of the fixes we know about so far.

We have recently managed to duplicate some of the Modbus issues, but haven't yet identified a fix. From what we've observed, the PLC isn't actually failing, it's just overrun some TCP stack resources that are in painfully long TCP timeouts. Every case I've observed has eventually come back on its own. The method of duplication was to do brutally hateful things that honestly shouldn't ever be happening, but would appear to be happening in some unreliable radio installations. We got pulled back into some beta work on the upcoming 2.10 release, and weren't able to chase it further, but the answer may be to reduce the TCP timeouts. I am a little reluctant to do that, since I'm not completely familiar with the significance of them all (there are a half dozen or so), but that may be the only way to fix it if the code isn't really broken.
"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