• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 208 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2432: Profinet Testcase MRP Interop Client failed

Andrea Politano
Prodigy 240 points

Part Number: AM2432

Hi,

I am using AM2432 with the Industrial SDK 11.00.00.08.

The Profinet certification laboratory has reported us a problem (with test bundle v2.45):

Problems with Testcase “MRP Interop_Client (CLRPC)”:

When the MRP-ring is closed, your device breaks down the AR to the controller (with DHT/WDT Alarm).

Then, also the Scalance-AR breaks down.

Failure is Reproducible. (Always your device is the first device that breaks down the AR.)

I read in Profinet Device Known Issues that this case is marked as a known issues, however, the actual behavior of the stack is not specified. Could this be the problem that is being reported to us?

I send them the link and asked them which specific version they were using and if they were aware of this issue. This was their response:

I can say, that we use 2.45.0.2 now for the test, and the MRP topology/ring is correct and that the MRP domain is changed, in order to fit together with the ART software.

Could this still be a problem? Have you ever tried testing with the version they specified?

I attach the wireshark log and our GSDML: MRP.zip

Thank you,

Best Regards, 

Andrea

  • 0
    TI__Intellectual 1840 points

    Hello Andrea,

    The test bundle we used to test SDK 11.00.00.08 was v2.45.1.2. We are now on v2.46 (the latest one available on the official website).
    So far we have not observed any issues with this test case and our AM243_EVM is certified for the mentioned SDK.

    I'll take a deeper look into the file you shared and get back to you.

    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 240 points

    Hi Kamil, thank you for your reply.

    I add some new information that has been provided:


    the MRP-failure already occurred already during preparation of the MRP-project (making the MRP setup), not during the MRP interop testcase execution.
    Make an MRP-project with a device line that is built like this:
    CPU <–> Scalance B <–> (port1)DUT(port2) <–> Device D(=ET200SP)
    And then startup the Devices at the CPU. (=> This will work.)
    When you then close the MRP ring (by connecting Device D <-> CPU), then you will see the failure.

    I read that MRP may require responses within a short deadline. Could this be a task priority issue? In my project, the main task has priority 31 (in addition to other tasks but with priority 6 or lower), and I noticed that in the demo, the main task has priority 22. Could this be a problem?

    Could you suggest something I can try to better verify the problem?

    Thank you,

    Best Regards,

    Andrea

  • 0 in reply to Andrea Politano
    TI__Intellectual 1840 points

    Hi Andrea,

    thanks for the clarification. I assume by MRP setup you still mean "MRP Interop test setup" but not the testcase itself.

    I took sometime today to look into your traces and it seems like, upon topology switch-over, your device is not processing the messages sent by the PLC on the new port which leads to a DHT timer expiry.

    Task priorities might be something to consider, especially that we don't have this issue on our side. However, first I would like to get more information about your devices and configuration.

    1. Which device has the MAC address 00:1b:1b:c9:23:ce? if it's for Device D then what about 28:63:36:12:97:5d and 28:63:36:12:97:5e?
    2. What's the ABB device advertising the IP address 192.168.6.18 in this topology?
    3. MRP reconfiguration can take up to 200ms. Have you accounted for this while configuring the DHT timeout?
    4. Would it be possible for you to share the TIA portal project you're using to produce the failure?

    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 240 points

    Hello Kamil, thank you for your reply.

    The configuration should be this one:

    CPU <–> Scalance B <–> (port1)DUT(port2) <–> Device D(=ET200SP)

    28:63:36:86:95:13 -> CPU1516F
    00:1b:1b:c9:23:ce -> Scalance B (=X204IRT V5.5) (because of location of the capturing-TAP, you won’t see very much of its communication); This device is the MRP-Manager.
    ac:d3:64:00:10:01 -> DUT
    28:63:36:12:97:5d -> Device D (=ET200SP V3.3)
    ac:d3:64:21:00:12 -> other device (the one with IP Address 192.168.6.18), to be ignored

    I share the TIA Portal project used by certification lab: ABB_Ekip_COM_PN__MRP-Setup_Rel-V19.zip

    As an option, it would be possible to have a Profinet stack that does not include MRP functionality? I believe that some acyclic responses from the stack would definitely need to be corrected, but I don't know if there is anything else to consider.

    Thank you,

    Best Regards,

    Andrea

  • 0 in reply to Andrea Politano
    TI__Intellectual 1840 points

    Hi Andrea,

    I tried the shared project on my side and it seems to work.
    1. Did the test lab try to set another MRP-manager? like the PLC instead of Scalance?
    2. Did the test lab try to increase the DHT timeout further? did this change the behavior?
    3. Are you able to test MRP on your side? if yes, please share your setup environment and test results, syscfg file, linker.cmd and map file. We can try to figure out the differences between your project and ours in order to narrow-down the list of possible causes.

    Regarding your second point, MRP functionality cannot be disabled in our official released package. However, you can reach out to your sales representatives for customization of standard deliveries. It is also not possible to disable MRP in the GSDML file since you have a 2-port device.

    Thank you.
    Kind regards,
    Kamil