Basic principles
The TE1111 TwinCAT EtherCAT Simulation function simulates an EtherCAT segment. An already created I/O configuration of the real plant is exported and can be imported into a second system as an ‘EtherCAT Simulation’ device. A mirrored process image is thus available on this system that can be linked with corresponding TwinCAT modules (e.g. written in the IEC 61131-3 languages or generated from Matlab®/Simulink®). The desired behavior of the machine must be implemented with sufficient accuracy in these modules. If the TwinCAT real-time is now started on both systems, one has an HIL simulation without having to adapt the original project in order to achieve this.
 | Since the project for the control system to be tested should not be changed, the EtherCAT Simulation Device operates unsynchronized. This means that the task that drives the Simulation Device has to run twice as fast on account of Shannon’s theorem (sampling theorem). On standard IPC hardware the shortest cycle time of the simulation device is currently 50µs. HIL simulations of the control system to be tested are thus possible with a cycle time of 100µs. |
In addition to HIL simulation, EtherCAT simulation can also be used to simulate one or more EtherCAT segments on the same computer, as long as sufficient free network interfaces are available. Depending on the application, various cabling options are available, which are described in the chapter Cabling.
The EtherCAT simulation is essentially limited to the EtherCAT-relevant aspects of the bus devices. The internal behavior of the bus devices themselves is neglected. For some bus devices, however, it is necessary to simulate at least part of the behavior, as otherwise the EtherCAT master cannot be started correctly (e.g. EL6224). To simulate this, the EtherCAT simulation offers the possibility to activate theMailbox Auto Response option, which automatically answers such requests without having to implement anything. If these parameters are still required, this option can also be deactivated. In this case it is possible to redirect the CoE, SoE and AoE communication into a user PLC module and to react there to these telegrams (see CoE / SoE / AoE).
Another example in which the pure EtherCAT consideration of the devices is not sufficient are drives. Here it is necessary to implement at least part of the drive state machine so that TwinCAT NC can start correctly. For the drive profiles CoE and SoE, these are implemented as function blocks as examples (see ). These function blocks can be instantiated in a PLC module for each drive contained in the configuration and linked to the axes. They are thus switched between the EtherCAT simulation and the process simulation to be implemented.