Delta RMC101 - Manual (Page 368)

RMC100 and RMCWin User Manual
5-118
How not to Control Collisions
Do NOT set the Ethernet switch port to the RMC100 to full-duplex. This is why:
1. A collision is defined on a half-duplex 10/100baseT Ethernet segment as happening when the Tx
wire pair and Rx wire pair are active at the same time. Notice that there is no electrical contention
on 10/100baseT during a collision like there was on a truly shared media like Coax (10base2)
Ethernet.
2. When a device says that it is Half Duplex, it is saying that its internal Ethernet controller cannot
handle receiving data on the Rx pair at the same time it transmits on the Tx pair.
3. Ethernet has a protocol for half-duplex communication to incur minimal delay on this conceptually
shared media.
4. There are 3 pieces to this scheme: (1) before sending data on a half-duplex segment, the device
(switch or RMC) must wait until its partner is not sending, (2) if the Rx pair is idle, then the send
begins, but the sender monitors for a collision during the first 512 bits, (3) collision during this
phase is perfectly NORMAL and triggers a quick retry (see our help topic on just how short this
is).
5. So when both sides (switch and RMC in this case) play by the rules, then only one side sends at
a time, and when they happen to start talking at the same time, then a timely retry is done
automatically.
So, what happens when the switch decides to NOT play by the rules? (i.e. the switch thinks the
link is full duplex, but the RMC is still limited to half duplex)
1. The switch will receive any data sent by the RMC without watching to see if the Rx lines are busy
when it sends on the Tx lines.
2. Because the switch sends data to the RMC without looking for a collision, the packet may be
discarded by the RMC's Ethernet chips, while the switch is blissfully unaware that the packet was
thrown away, so it WILL NEVER BE RETRIED! Further, it may or may not interrupt the packet
going from the RMC to the switch, causing missing packets in the other direction.
In review, all that is accomplished by setting the switch to Full Duplex is it turns off REPORTING
of collisions on the switch side, and makes matters worse by trading normal (quickly retried)
collisions for worse errors that do not resend the packet. Because EtherNet/IP is a robust
protocol, it can handle a few missed I/O packets without a hiccup. However, if one of the packets
that was thrown away was from an MSG block, then it could be multiple seconds before it gets
retried by the protocol! A properly configured Ethernet system should never see Jabber,
Underrun, Late Collisions, Bad CRC, Extra Data, or Runt errors.
5.2.6.3.7.6 Setting Up Large EtherNet/IP Networks
Most examples given thus far show only small EtherNet/IP networks. They do so for simplicity.
Larger EtherNet/IP networks are possible as well. This topic discusses a few issues that come to
the forefront with large systems. The terms "large" and "small" are ambiguous, but similarly, the
concepts really apply to both large and small networks. An example of a small systems is one to
four RMCs connected to a single 1756-ENET or 1756-ENBT. An example of a large system is 40
RMCs connected to one or, ideally, more 1756-ENBT modules.
• Reduce Bandwidth Usage to Actual Requirements.