Loss of Synchronicity Error

Owned by William Chin
Last updated: Apr 29, 2024 by Corey Boyles
3 min read

If you encounter a synchronicity error during application development, it is probably a result of one of the possible causes discussed below. This error can be seen on the General tab of your SoftMotion axis in online mode.

A synchronicity error indicates that the EtherCAT_Master task has had some sort of overrun and has not serviced the EtherCAT bus cycle within its allotted time period. The most common causes of synchronicity errors are:

  • Running Modbus in the EtherCAT_Master task

  • Performing file access (e.g. recipe operations) in the EtherCAT_Master task

  • Large looping statements that greatly impact cycle time when they execute

  • An EtherCAT_Master task cycle time that is too short

Modbus in the EtherCAT_Master Task

Many applications use the PAC's Modbus TCP Master or Slave implementation to communicate with third-party devices. However, care needs to be taken to assign an appropriate priority to Modbus so that it remains secondary to EtherCAT. Otherwise, the TCP protocol on which Modbus relies (which is by its nature highly non-deterministic) could interfere with the timely maintenance of the EtherCAT bus.

To determine whether this is a problem, double-click on either Modbus TCP Master or the Modbus TCP Slave Device depending on whether the PAC is being configured as a master or slave. This device is always one indentation layer deeper than the Ethernet device in the Devices Tree. The figure below shows which devices may need to be checked:

The Bus Cycle Options group box shows the task in which Modbus executes. The images below show where to find the Bus Cycle Options group box.

By default, the Bus Cycle Task setting is Use parent bus cycle setting, which means that the PAC's bus cycle (the EtherCAT_Master task) will be used for running Modbus. This setting can be changed to use any task configured in the PAC.

One good option is to simply create a new task in the Task Configuration called ModbusTask. Typically, 20 ms is a good cycle time for Modbus communications. The priority should be set to some number between 1 and 31. Be sure to weigh the importance of timely Modbus updates against the importance of other lower-priority logic tasks in the application. The nice thing about having a task dedicated to just Modbus is that it allows the priority and cycle time to be changed independently of all other logic in the application.

File Access

File access operations are relatively slow compared to the high speed requirements of most of the PAC's duties (motion, I/O, EtherCAT). They are also blocking operations that take an indeterminate amount of time to finish. This is why all file access operations should be kept in low-priority tasks. This way, EtherCAT, motion and other time-critical control functions will always be given priority over them. Common examples of file access operations are:

  • Recipe usage (reading, writing, creating, deleting, etc.)

  • CNC motion when using the SMC_ReadNCFile function block

  • Using SMC_ReadCAM or SMC_WriteCAM function blocks

  • Any functions in the SysFile or SysDir libraries, as well as their CAA counterpart libraries

Large Looping Statements

Looping statements, such as WHILE, REPEAT or FOR statements, can have a significant impact on task cycle time under one or more of the following conditions:

  • The statement loops over a large range (e.g. 1-100,000)

  • The statement has no fixed termination, common for WHILE statements

  • The control variable or expression for the statement is subject to writing from within the statement

It is generally good practice to limit use of looping statements where possible because they are a common source of bugs. If a looping statement is required, best practice is to attempt to use a FOR statement before considering other possibilities. This is because FOR statements have their control variable built into the structure of the loop, making it less likely that the loop will fail to terminate or deviate greatly in terms of execution time.

Short EtherCAT_Master Task Cycle Time

In some cases, the EtherCAT_Master task cycle time may simply be too small for the size of the application being developed. To determine whether this is the case, double-click the Task Configuration in the Devices Tree while in Online Mode, then go to the Monitor tab:

To get accurate readings, make sure to right-click on each row and click "reset" when the window first comes up. The first 1-2 cycles after the PAC boots are nominally much longer than usual, making the Max Cycle Time look very large.

In general, the Max Cycle Time should only be about half to two thirds the value of the configured cycle time. If it is much more than that, situations could arise during execution where the task takes more time than is available and misses an update. If the EtherCAT_Master task is taking too long to execute, then either the task cycle time needs to be extended or non-essential (non-motion) code needs to be offloaded to a lower priority task.

22JAN2019 DCLIFFE
UPDATED 23JAN2019 DCLIFFE