EtherCAT Questions: cyclic & acyclic communication, scheduling, latency

[CodeShepherd]

Q1: The EtherCAT communication is a part of the datalayer and integrated in it. How is the cycle time for updating cyclic process data (send and receive)? Is this cylce time configurable?

Q2: When and how is the image of the I/O prcess data stored in the data layer?

Q3: Which additional latencies can the data layer occure?

Q4: Is it possible to create an acylic communication between the Master and Slave? An how can it be done?

Q5: Who is responsible for the start of an acyclic communication? Time scheduling and free slots on data canal?

Q6: Other competitors support an EtherCAT communication with a standard office switch in the topology. If you use an office switch in the ctrlX system, they appears an error "topology mismatch". Why?

[MrLurtle · Accepted solution]

Hi together, 

I want to share some informations and answers to frequent asked questions I´ve got from several customers:

Q1: The EtherCAT communication is a part of the datalayer and integrated in it. How is the cycle time for updating cyclic process data (send and receive)? Is this cylce time configurable?

Q2: When and how is the image of the I/O prcess data stored in the data layer?

Q3: Which additional latencies can the data layer occure?

Q4: Is it possible to create an acylic communication between the Master and Slave? An how can it be done?

Q5: Who is responsible for the start of an acyclic communication? Time scheduling and free slots on data canal?

Q6: Other competitors support an EtherCAT communication with a standard office switch in the topology. If you use an office switch in the ctrlX system, they appears an error "topology mismatch". Why?

A1: the standard configuration is 2ms. At the moment there is no other configuration possible. It isn´t configurable for now, but in further relases it will be configurable. The minimum cycle time will be >1ms. The Focus in wave1 is on Applications >1ms cycle time.

A2: The image of the inputs of the process data is stored at the beginning of a plc cycle. The image of the outputs of the process data is stored at the end of a plc cycle. This is typical behaviour of an embedded plc system. 

In PLC Engineering you can configure a PLC task which is triggered by an external Event "TASK_EXTERNAL_EVENT_07". If you do this, your plc task is always running in the EtherCAT buscycle Task. Please don´t define a priority <14 for your task for now.

A3: the system guarantees a equidistant actualisation of the I/Os in the configured cycle time.

Latencies can occure in the operation of the plc programme, but the I/O conditions are always consistent due to the exact "latch" of the image of the process datas. The DC Sync functionality guarantees the synchonous operation between Master / Slave and Slave / Slave.

A4: Yes it is. In the first releases we support only SoE communication via EtherCAT. So you can only read and write acyclic S and P Parameters and you need a slave, which support SoE communication e.g. our ctrlX Drive or Indradrive CS...

In future we implement also CoE and it should be released on November 2020. So in this case, you can also read and write SDO via EtherCAT and you can realize an acyclic communication for EtherCAT slaves, which support only CoE.

In PLC Engineering for example, you can find the commands for an acyclic communication in the library: "CXA_ETHERCATMASTER". Further libraries will be provided, if CoE is released.

A5: As soon as the functional block is triggered with an rising edge on the Execute input, the acyclic communication is started. The command is added to the queue of the EtherCAT message box and the communication is running. 

A6: Some competitors identify the network type before they start the EtherCAT communication. If they detect a network device, which supports no realtime communication, they change the type of the network communication and use UDP/IP communication instead. But in this case, the realtime communication is switched to a non realtime communication, too. So you can not guarantee a real time behaviour.

Our focus is embedded control systems and because of this, we only use hard realtime communication which is defined by Ethertype 0x88A4 (OSI Layer2 based communication). And in this case, it is not possible to use standard office switches without any realtime support.