Search the Community

Showing results for tags 'net loss dpi p5'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Found 2 results

  1. I have an issues with various Powerflex 700S drives tripping out periodically on Net Loss DPI P5 fault (F# 59). These drives are set up on the same ControlNet network to communicate with the Contrologix 5563 processor. The drives will reset easily and the process restarted, but it is a nuisance and time is lost resetting the equipment. Any advice will be appreciated.
  2. Hi 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 192.17.150.208? Tell 192.17.150.30 Next and subsequent ARPs after the first one: 475.423471     Rockwell_cf:a7:6c     Broadcast             ARP      60     Who has 192.17.150.208? Tell 192.17.150.30 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!