![]() ![]() If you unplug the receiving device and plug it back into a different port, one of two things should happen 1)the entry in the MAC Table will time out (maybe 5 minutes) and the Switch will then try to determine where the device is at or 2)the originating device will determine there is a problem and start sending ARP Requests. If you unplug the receiving device and plug it back into the same port, everything should pick right back up. What should happen when cables are unplugged? If the Destination MAC Address is in the MAC Table the Switch will send the packet to the proper port, if the Destination MAC Address is not in the MAC Table the Switch can send a Flood to all the ports to try and determine which port the MAC Address is at. The Switch will update it's MAC Table with the Source MAC Address and look for the Destination MAC Address in the MAC Table. When the Switch receives a packet it looks at the header and checks the Source and Destination MAC Addresses. The Switch sends the ARP Reply back to the originating device and the originating device updates it's APR Table. At this point the device with the IP Address such and such will say that's me and will send an ARP Reply stating I am IP Address such and such and my MAC address is yada yada yada. If there is no listing in the ARP Table then the device will send out an ARP Request, which basically says "I am IP Address so an so and my MAC Address is blah blah blah, Who is IP Address such and such and what's your MAC Address?" The Switch will receive the ARP Request and since this type of request is a broadcast request the Switch will send the request to all it's Ports. When a device wishes to send a packet to an IP address it checks it's ARP Table to see if it already knows the MAC address. Switches contain a MAC Table which is a mapping of MAC addresses to (Physical) Ports. Devices have an ARP Table which is a mapping of IP to MAC addresses. That may help down the road, but not today.īasically local network communication is done by MAC addresses. I now know that the issue occurs with an unmanaged switch also.įrom another post, I saw a link () to a switch with built in port mirroring. The drive folks are pointing at the Stratix since their in house testing used an unmanaged switch. Rockwell is already pointing the finger at the drive folks. I've already informed all parties involved that this is NOT a workable solution! The only way I've discovered to resolve the issue is to cycle 24VDC to the drive. Note: I can ping the drive just fine at this point. When the cable is plugged back in, the connection doesn't get reestablished and 16#0204 stays put, along with the yellow triangle. RSLogix comes up with a 16#0204 error indicating a connection timeout error. The problems start when a connection is temporarily lost, i.e. specification of unicast connection over EI/P, RPI = 20ms. I was able to connect the drive to the PLC with no issues. I'm currently bench testing this setup prior to connecting to the actual process equipment, so I have a bit of latitude to play around. Thanks for the inrush of interest, folks! Basically, here's the highlights: ![]()
0 Comments
Leave a Reply. |