• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 1357 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.

DP83822I: EtherCAT

Hirotaka Matsumoto
Guru 27595 points

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

  • 0
    TI__Mastermind 23675 points
    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
  • 0 in reply to Ross Pimentel
    Guru 27595 points

    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

  • 0 in reply to Hirotaka Matsumoto
    TI__Mastermind 23675 points
    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
  • 0 in reply to Ross Pimentel
    Guru 27595 points

    Ross san

    Thank you very much for your reply!!

    OK, we got it.

    Kind regards,

    Hirotaka Matsumoto