MrRobotics posted a topic in Allen BradleyHi All, Networking guy here, looking for network experts on a AB PLC (1756-EN3TR/B v217021900) which seems to STOP ARPing for a device after 10 ARP's. The device is purposefully powered down, but when powered up, it can take minutes before the PLC sees it again. The PLC team says only changes in the PLC's logic are made. When an older backup is restored though, I do NOT see the issue somehow. 1) The devices that are powered down are back on the network and reachable within 10 seconds or so (ping). The initial thought was that they were not even on the network, but they are. Just that PLC shows a comms loss. 2) With the 'good code', the PLC, once the device is offine, keeps sending ARPs to find the device. The first one is a directed one, the subsequent ones are broadcasts. These broadcasts keep happening till the device is back online and is able to talk to the PLC again. 1st ARP after comms is lost: 474.423859 Rockwell_cf:a7:6c Hilscher_2e:ea:08 ARP 60 Who has 188.8.131.52? Tell 184.108.40.206 Next and subsequent ARPs after the first one: 475.423471 Rockwell_cf:a7:6c Broadcast ARP 60 Who has 220.127.116.11? Tell 18.104.22.168 These ARPs keep happening every 1 second, till the device is online again. 3) With the bad code, the PLC, once the device is offline, sends only 10 ARP messages total and then stops sending ARPs altogethe . Then it takes 10 minutes* before it sends another one. If the device is backup online by that time, the PLC finds it right away. SO with these 2 different code bases, how is that a low level L2 protocol like ARP is impacted so much. The PLC team tells me that they have no idea and not set anything related to it. My question is where is the ARP network behaviour governed and how to change it? How can older code which supposedly only has changes in logic have different ARP behavior? * The 10 minutes interval might lead people to think it's a ARP timer and most likely it is, but then people usually ask about gratuious ARPS (garp) and I've verified that they make it through from the device to the PLC OK. If the device is offline for say a minute, the PLC mirrored port does indeed see the garps, yet at that point the PLC is no longer ARPing and regardless of that garp, it has to sit out the time till it sends a next ARP till it connects. Thus, I suspect the coming back to life process is governed by the PLC ARPing for it, and not by the detection of a garps. Thanks everyone!