Outputs on the command line like these:

082039 : eUsrJob_ProcessAllRxFrames - not all previously sent frames are received/processed (frame loss)!
082039 : No response on cyclic Ethernet frame
082039 : DCM Status: ERROR: controller error - synchronisation out of limit (0x981201C2)

082039 : DCM Status: ERROR: controller error - synchronisation out of limit (0x981201C2)

If the jitter of the Distributed Clock (DC) is too high, this error message is displayed. If the Linux master synchronizes the clock (busshift-mode), then the master probably has realtime-performance problems.

082039 : eUsrJob_ProcessAllRxFrames - not all previously sent frames are received/processed (frame loss)!
082039 : No response on cyclic Ethernet frame

The Acontis stack could not receive/send the PDO in time. The master probably has realtime-performance problems.

If you use the bus shift mode (default) then the Linux master sets the clock for the DC. In this case, the DC clock is only as stable as the Linux master.

However, a slave can also set the clock for the DC. Since EtherCAT slaves often have hardware clocks, these clocks are often much more stable and accurate. This mode is called master shift mode.

To use the master shift mode, add the parameters „-dcmmode mastershift“ when calling the application.

Understanding bus/master shift mode

See this instruction on how to measure and improve realtime-performance.

Within a cycle, the system needs to:

• Send/receive a data frame (PDO)
  • If 50% of the maximum bandwidth is used, at least 50% of the cycle is used to send/receive the EtherCAT frame
• User application
  • The control application; i.e. EEROS
• Jitter of the real-time system

If all this points add up to more than the cycle duration, than the system can not send a frame every cycle.

You can try to:

• Send less data over PDOs.
• Lower the calculation time of your control application.
• Increase real-time performance
• Increase the cycle time (lower control frequency)