News:

  • June 08, 2026, 02:13:29 AM

Login with username, password and session length

Author Topic: General Networking Information Between Master/Slaves  (Read 5475 times)

RBPLC

  • Hero Member
  • *****
  • Posts: 586
General Networking Information Between Master/Slaves
« on: July 09, 2021, 08:00:41 AM »
I currently have a system running with 1 BRX and 2 EBC100's. The system has been running for about three weeks with no known performance issues that I've seen. My questions concern Ethernet traffic between the master and slaves. With the EBC's, the poll rate is 100ms, timeout is 500ms and retries are set at 5 for each EBC. This isn't a particularly fast process so the time to fault is relatively large. I pulled up the Ethernet I/O monitor this morning to get a sense of what has been going on with the traffic. I see that the retries for one EBC is 47 and 42 for the other. There are 218 dropped packets, 0 Ethernet Interrupt Stopped, 0 send errors and 0 missed frames. My questions are:

1) Is it common to see dropped packets/retries with most systems? Is this anything to be concerned about?
2) From a system performance perspective (at a high level) are dropped packets and retries a big deal as long as they don't fault the system based on the poll rate/retries specified? I assume that on systems with quick timeouts that dropped packets and retries become much more critical.
3) I guess what I'm asking is that if the system has been running without faulting out due to comms issues, do I need to worry about the details of the Ethernet traffic?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6158
  • Yes Pinky, Do-more will control the world!
Re: General Networking Information Between Master/Slaves
« Reply #1 on: July 09, 2021, 01:15:28 PM »
Dropped packets are the PLC defending itself against excessive traffic. It will accept the first 16 packets in a single scan without consideration for the speed they came in, but then it switches into a protective mode, where it starts dropping packets to keep the average at 1 packet per 100us. After receiving 32 packets in a single scan, it shuts off the interrupt until next scan. You aren't getting enough packets to stop the interrupt, but you are getting enough to start throttling.

If your I/O is running on an isolated network, you shouldn't see retries at all. Running on a public-ish network, it can definitely happen. As long as retries clear it up, you don't mind the bump to the I/O update, and you never trip the I/O fatal, it's no big deal. If any of those things are a problem, you really need to isolate the I/O.
"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