This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM4376: EtherNet/IP adapter issue

Part Number: AM4376

Hello experts,

we are using the EtherNet/IP adapter v1.0.3.4 on out AM4376 device. When the device is operating in a DLR netword with an active ring supervisor, the active supervisor address (MAC and IP address) is provided by at the following register offests within the ICSS shared data RAM:

DLR_ACTIVE_SUP_MAC_0123 = 0x154

DLR_ACTIVE_SUP_IP_OFFSET = 0x164

The MAC address of the active ring supervisor is always provides at offset DLR_ACTIVE_SUP_MAC_0123, but the IP address of the ring supervisor only sometimes contains the right value. In all other cases, the IP address is 0.

What could be the reason why the IP address of the active ring supervisor is provided with 0?

Best regards

Stefan 

  • Hi Stefan,

    Let me check internally to see if this is a known issue. I don't have a setup to replicate the issue at this special moment.

    Regards,

    Garrett

  • Hi Stefan,

    The MAC address and IP address are updated at different places in the receive flow. This is not a known issue and we will have to reproduce at our side. Is there any specific scenario where the issue is seen. Also capture during the issue will help.

    Please note, we may need more time to get this issue reproduced during the the COVID-19 period.

    Regards,
    Garrett

  • Hi Garrett,

    thank you for your reply. I have seen the issue a couple of times but was not able reproduce it afterwards.

    I will check, if I can reproduce it in a stable way and make a capture.

    Best regards

    Stefan 

  • Hi Garrett,

    I can reproduce the issue every time I startup the DLR network from power-on reset.

    I am using the following network setup:

    • Rockwell CompactLogix L27ERM control as DLR ring supervisor.
    • Our EtherNet/IP adapter with AM4376 and your PRU based EtherNet/IP adapter v1.0.3.4 as DLR ring node (DUT).
    • Ring supervisor and ring node are connected with two CAT 5e Ethernet cables in order to build the mallest possible DLR ring.
    • Additionally, I added an Ethernet TAP between the active supervisor port and our device.

    L27ERM [PORT1] <==> TAP <==> [PORT1] DUT [PORT2]  <==> [PORT2] L27ERM

    When the DLR ring is up and the control application is running, I read out the supervisor address information from the ICSS shared data RAM. The MAC address is equal to the MAC address of the supervisor, the IP address is 0.

    The IP address sometimes contains the correct value, when I remove and re-attach both Ethernet cables from the DUT. But In most cases the IP address remains 0.

    • Removing the TAP results in the same bahavior.
    • Removing only one Ethernet cable does not fix the IP address.
    • Replacing the DUT by a different ring node from another manufacturer the supervisor IP address is always valid.

    I attatched a Wireshark capture file that is made in error case (ring_normal_suv_ip_0.pcapng). I am not sure if you can reproduce the issue but maybe the Wireshark capture contains some more information. If not, are there some indicators in your receive flow that could give a hint what may go wrong?

    Best regards

    Stefan

  • Hi Stefan,

    It seemed you forgot to attach the capture?

    Thanks,

    Garrett

  • Hi Garrett,

    sorry, here it comes.

    Best regards

    Stefan

    ring_normal_suv_ip_0.zip

  • Hello Garrett,

    I would like to ask if you had the opportunity for further investigations?

    Thank you and best regards

    Stefan

  • Hi Stefan,

    I could confirm your observation from the capture - the Beacon frame source IP is always 0.0.0.0 including the frame #209 neighbor check request (but #210 is neighbor check response frame). The lockdown impacts us to reproduce the issue. I have been trying to get more input from team...will get back to you on this.

    Regards,

    Garrett

     

  • Hello Garrett,

    did you receive any further input from your team?

    Best regards

    Stefan

  • Hi Stefan,

    This is still in our list, we are going to update you as soon as possible.

    Thanks,

    Garrett

  • Hi Stefan,

    Comments from our team:

    Firmware updates the supervisor details once there is any change in the DLR state,  IP address from the beacon frames at the time of state change will be updated in the memory. In this case the value is 0 in the beacon frames initially.

    This behavior doesn't seem to be a issue.

    Regards,

    Garrett

  • Hello Garrett,

    thank you for your reply. I have checked the comments but cannot reproduce the described behavior.

    I used a different ring supervisor (Allen Bradley ControlLogix 1769-L83) and started the DLR network from power-on. Again the supervisor IP address remains zero. I have attatched another WireShark capture that shows, whats happening on the ring:

    Frame 92/32

    The DLR ring changes from FAULT to NORMAL state. The supervisor IP address in the Beacon frame is still 0. So far so good.

    Frame 20742/20743

    After ~11 s, the ring supervisor sets the supervisor IP address in the Beacon frame to a valid value (here: 172.29.233.10). The DLR ring is still in NORMAL state. The supervisor IP address provided by the shared mameoy remains 0. This behavior matches to the comments from your team.

    Frame 160648/160649

    After ~37 s, the ring is being interrupted and changes from NORMAL to FAULT state. The supervisor IP address in the Beacon frame is still valid (here: 172.29.233.10). The supervisor IP address provided by the shared mameoy remains 0. This behavior does not match to the comments ("Firmware updates the supervisor details once there is any change in the DLR state ...").

    Frame 181026/181027

    After ~44 s, the ring is being closed and changes back to NORMAL state. The supervisor IP address in the Beacon frame is still valid (here: 172.29.233.10). The supervisor IP address provided by the shared mameoy remains 0. This behavior does not match to the comments ("Firmware updates the supervisor details once there is any change in the DLR state ...").

    -----

    Conclusion: Refering to the comments, I would expect that the last two events schould fix the display of the IP address within the shared memeory. 

    Best regards

    Stefan

    ring_state_change_suv_ip_0.zip

  • Hi Stefan,

    Is the issue still pending with the patch eip_dlr.patch posted in another thread?

    Regards,

    Garrett

  • Hello Garrett,

    yes, the issue is still pending with the eip_dlr.patch from the other thread.

    Best regards

    Stefan