News:

  • October 17, 2026, 04:11:31 PM

Login with username, password and session length

Author Topic: gigabit switch  (Read 6032 times)

mhw

  • Hero Member
  • *****
  • Posts: 250
gigabit switch
« on: April 27, 2021, 04:27:25 PM »
This is more of a network question than a DoMore question but there is tremendous wisdom on this site and I want to tap into it.
Is there a benefit to using a gigabit switch on a LAN that has a couple of BRXs, three EBC100s, five BX-DMIOs, and a couple H0-ECOMs?
Now for a BRX question. How much hit does the scan time take for each BX-DMIO that is added?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3850
    • Host Engineering
Re: gigabit switch
« Reply #1 on: April 28, 2021, 09:32:25 AM »
This is more of a network question than a DoMore question but there is tremendous wisdom on this site and I want to tap into it.
Is there a benefit to using a gigabit switch on a LAN that has a couple of BRXs, three EBC100s, five BX-DMIOs, and a couple H0-ECOMs?
Now for a BRX question. How much hit does the scan time take for each BX-DMIO that is added?

Time on a wire for 100 MBit Ethernet is not much, so switching to gigabit won't help.  Comm processing by the PLC is done at the bottom of the PLC scan (with buffering), so even a 1Gigabit Ethernet CPU would just let it arrive sooner for the PLC to process the packet at the bottom of the PLC scan.

Regarding Ethernet I/O, the PLC CPU does not "wait" for responses to packets, so the hit is minimal, however long it takes to build up the packet.  Also, the Ethernet I/O response packet data is optimized so that they just need to be copied - very little "parsing".  Your HMI and Designer probably cause more of a "hit" than all your I/O.

In Computer Science, you learn NOT to "optimize" where you think you need to optimize.  Bottle Necks need to be measured empirically.  Do-more's MATH box contains a TICKus() (microsecond) register that you can use to measure changes in time for an instruction, an section of code, a code block, or even overhead (e.g. stick a MATH w/TICKus() BEFORE the code you want to measure, like in $tBottomOfScan, and another one AFTER the event you want to measure, e.g. $tTopOfScan, take the difference, and you get the amount of time in MICRO seconds for that section of code).  Paretto analysis for optimizing PLC scan time is highly recommended. Programmers waste time "optimizing" things that are not that big of a scan hit - actually complicating the code and actually sometimes making it SLOWER.  MATH/TICKus() is your friend for helping optimize PLC scan time.