BECKHOFF EtherCAT Technology Section I - Manual (Page 44)

Ethernet Physical Layer
I-24 Slave Controller – Technology
5.8 EtherCAT over Optical Links (FX)
EtherCAT communication over optical links using Ethernet PHYs is possible, but some requirements
of EtherCAT have to be respected, and some characteristics of EtherCAT slave controllers have to be
considered.
Some ESCs are prepared for FX operation, others require external logic to achieve EtherCAT
compatibility.
Refer to the EtherCAT Slave Controller application note “PHY Selection Guide” for details on FX PHY
connection and example schematics. The application note is available at the Beckhoff website
(
http://www.beckhoff.com ).
5.8.1 Link partner notification and loop closing
The main principle of EtherCAT operation in case of link errors is disabling unreliable links by closing
loops. This is automatically performed by the ESCs. The ESCs rely on the LINK_MII signal from the
PHYs for detecting the link state.
With FX connections, it could happen that the Transceiver device is powered, while the PHY (and/or
the ESC) is not active. The communication partner would detect a signal, causing him to open the link.
All frames will get lost because the PHY (and/or the ESC) is not operating.
So at least the following two requirements have to be fulfilled, otherwise frames will be lost:

ESC in reset state → Transceiver disabled

PHY in reset state → Transceiver disabled
The recommended solution for this issue is to enable the transceiver together with the PHY by using
the PHY’s reset signal for the transceiver, too. If the transceiver has no suitable input, the power
supply of the t
ransceiver can be switched off. Since the PHY’s reset should be controlled by the ESC’s
reset output (either main reset output or individual PHY reset output), the transceiver will power down
while the PHY is in the reset state and also while the ESC is in the reset state. Thus, the ESC and the
PHY will be active when the transceiver gets active, and no frames are lost.
5.8.2 Far-End-Fault (FEF)
Some FX PHYs offer a Far-End-Fault (FEF) generation/detection feature. The intention is to inform the
link partner of a bad link.
FEF Generation
If an FEF-supporting PHY receives a signal with a quality which is not sufficient, the PHY will transmit
a special FEF pattern to the link partner.
FEF Detection
If an FEF-supporting PHY receives the FEF pattern with good signal quality, it will continue
transmitting regularly, but it will indicate “no link” locally to the ESC, until the FEF pattern ends.
Conclusion
The FEF feature is advantageous for EtherCAT, because the PHYs will only indicate a link when the
signal quality is high enough. Without FEF, the EtherCAT slave controllers have to rely on the
Enhanced Link detection feature for detecting a low quality link.
Nevertheless, Enhanced Link detection becomes active only after the link is already established, thus,
in case of a low quality link, the link status will be toggling on/off (link up
→ Enhanced link detection
tears down link → link up …). This is sufficient to locate an issue in the network, but it might disturb
operation of the remaining network.
So, it is highly recommended to use PHYs which fully implement FEF generation and detection.
NOTE: Some PHYs are claiming FEF support, but they are either not supporting FEF generation or detection, or
they require configuration commands via MI management interface, which cannot be issued by the ESCs
automatically.