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.

DP83822I: EtherCAT

Part Number: DP83822I

Hi all

Would you mind if we ask DP83822I?
We would like to use EtherCAT with DP83822I, is it possible?

This device seems as follows;
-Fast link detection <15us
-Address 0~31

DP83822 is fill with requirements.

Kind regards,

Hirotaka Matsumoto

  • Hi Hirotaka-san,

    Yes, the DP83822 is an EtherCAT certified ENET PHY.
    Please see the selection guide that lists us as an approved device:
    download.beckhoff.com/.../an_phy_selection_guidev2.5.pdf

    Kind regards,
    Ross
  • Ross san

    Thank you for your support always!
    If it is possible, we would like to know one point.

    Link loss reaction time of TI's phy is configurable with less than 10us or 200us~250us.
    Competitor devices is defalut less than 10us one.
    Why is TI's phy configurable?
    Is the reason which normal Ethernet cycle time requires 250us?

    We need your help.

    Kind regards,

    Hirotaka Matsumoto

  • Hi Hirotaka-san, TI allows for a configurable link loss reaction time because not all applications will need it. For example, if you were only interested in UDP applications, you would not mind having some intermittent link issues because it would not greatly diminish the user experience. However killing the link with the fast link loss would cause issue for you because a poor link would be better than no link. However, for industrial applications this is opposite. You would want to kill the link and try another path. This is for both safety and quality. You would most likely be running some form of TCP and want to ensure zero packet loss. If there is a poor link it is better to remove the link quickly and find and alternative path while resolving the failure in the background. Does this make sense? Kind regards, Ross
  • Ross san

    Thank you very much for your reply!!

    OK, we got it.

    Kind regards,

    Hirotaka Matsumoto