EC-Engineer V3.3: New Features

Version V3.3 of EC-Engineer contains multiple new functions for creating the configuration for the EtherCAT network simulation software EC-Simulator. This enables the simulator to better simulate the real slaves with their properties.

Simulated slave that support CAN application protocol over EtherCAT (CoE) contain an Online Dictionary. The EXI (Extended Network Configuration) file may optionally contain the slave-specific Object Dictionary declarations. These slave-specific Object Dictionary declarations can be generated from the ESI file provided by the device manufacturer, or uploaded from the slaves via the EtherCAT network. In addition to the overall structure of the object dictionary, even the objects’ data can also be included in the EXI file.

System Architecture

Screenshot from Settings in EC-Engineer

If the EXI file does not contain a slave-specific Object Dictionary for a simulated slave, then EC-Simulator provides a generic Object Dictionary.

The slave's actual Online Object Dictionary depends on the device firmware and other criteria. The generic Object Dictionary therefore likely mismatches the slave's actual Object Dictionary. Some common mismatches between the generic Object Dictionary and the slave's actual Object Dictionary are more or less objects, differences in data types, and differences in content.
The master application might behave differently if using a generic Object Dictionary instead of the actual Object Dictionary. Therefore, by including the actual object dictionary in the EXI file, it is possible to make the slave’s simulated online dictionary match the slave's actual object dictionary.

Slave-to-Slave communication via the Master is the typical approach that is independent of the network topology. The data from the server devices is copied to the client device via the master stack.
This approach requires usually two communication cycles (Frame 1 and Frame 2).
In Cycle1, Frame 1 is sent and data from the slaves are read (IN).
The master then internally copies the IN data that is received in Cycle 1 into the OUT data area.
In Cycle 2, Frame 2 is sent with this data and this data is written to the appropriate slave (OUT).
Please note, there is no restriction regarding the topology. The Slave where the data shall be copied to (OUT) can be located either in front of the slave where data shall be read (IN) or after this slave.
A common use case for Slave-to-Slave communication is the exchange of safety data (FSoE connections) between the FSoE Master and FSoE slave devices within the EtherCAT segment.

For more information about FSoE please refer to theETG.1500 Master Classes Directive available for ETG members on www.ethercat.org

It is also possible to transfer data from one slave to another slave within the same cycle. This is called Slave-to-Slave In-Cycle Communication.
This approach only requires a single communication cycle (Frame 1).
Every EtherCAT frame will be sent from the master and is updated by each slave, see here: https://www.youtube.com/watch?v=z2OagcHG-UU
In every cycle, Frame 1 is sent and data is read from the input slaves (IN). This frame is then forwarded to the next slave and data read from the input slave (IN) can be copied into the slave where it should be written (OUT).
However, this has some limitations

• The slaves providing data to another slave must be located physically before the slave consuming this data within the network topology. Meaning that only a downstream communication is possible within the cycle.
• Only the whole TxPDO of the sending slave can be copied to the whole RxPDO of receiving slave. The number of transferred bits has to be equal and the used logical read/write (LRW) command has to activate the corresponding SyncManager in both slaves. As an example, it is not possible to copy data from a slave which has 4 bytes input data into another slave which has 2 bytes or 8 bytes output data.

Another drawback of this solution is that the Working Counter cannot be checked by the receiving slave.
A common use case for S2S in-cycle is to provide the encoder position of a motor to the servo drive amplifier as fast as possible.

EC-Engineer V3.3 offers a convenient dialog to define the communication relationships between the slaves. The application is consistently checking in the background if slave-to-slave in-cycle communication is possible, and will notify the user if the restrictions are violated.

EC-Engineer V3.3 now provides a mechanism for the user to create the recorder configuration file used by the Real-time Data Acquisition Library. The XML formatted DAQ Configuration File is used to define what kind of data shall be recorded. Typical data includes general parameters like the name of the record file, the sample rate, a list of the process data to be recorded, and also the trigger conditions used to start/stop recording. EC-Engineer is able to handle multiple DAQ configuration files and stores everything in the project file.