MrRobotics

ARP-ing behaviour of an AB PLC (1756-EN3TR/B v217021900)

2 posts in this topic

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!

 

Share this post


Link to post
Share on other sites

Hi! This is a strange issue where an older version works as expected but newer version does not... (logic changes only... hmm...)

Intuition says it's not logic related but some other obscure setting such as firmware version. Get your PLC guys to check the version of Studio/RSlogix being used and see if there is a PLC firmware difference, eg Version 20 vs 21 vs 24 (check major and minor versions) etc etc... While they're at it, get them to check ethernet module versions are also configured identically between the working and non-working project - see screenshot...

 

good luck!

vds

EthernetFirmware.jpg

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now