Configuration example

Configuration example

The functionality of FoE will now be illustrated on the basis of a programming example. The following illustration shows the physical structure with a CX2040 Embedded PC incl. CX2100-0014 power supply unit and downstream EL2809, EL1004 und EL6695, where the Ethernet connector X001 of the CX PC is connected to the “upper” RJ45 connector X1 of the EL6695 bridge terminal:

Configuration example 1:
Configuration with CX2040 including CX2100-0014 power supply unit and EL6695

Furthermore, the CoE object 0x1A05 is to be added in the System Manager so that it is possible on the receiving side to detect, on the basis of the info object “Data Bytes Pending”, whether data or a file have been received. To do this the respective checkbox must be activated in the process data. This is shown in the illustration only for the secondary side, which represents the receiving side in this example. Furthermore, the openly accessible variable “ScndFoeBytesToRead” contained in the TwinCAT sample program is to be linked with “Data Bytes Pending”.

Configuration example 2:
Addition of 0x1A05 (Data Bytes Pending) on the secondary side

Init – startup configuration

In accordance with the configuration definition of the object 0xF800 (see CoE/Parameter directory – profile-specific objects), two values have to be entered in 0xF800 for the transition from the Init state to the PreOp state (I → P):

The procedure using the System Manager (TC3.1) user interface is shown below, the selected “Startup” tab on the primary or secondary side marked terminal or box:

Configuration example 3:
Entry of the value 0x4000 in the device configuration 0xF800:01 (comment = Config 1: Disable EoE)

The value 0x4000 (type 00 40) is to be entered here for the object 0xF800, subindex 01 in order to deactivate EoE. This is necessary only due to the use in this example of the connection of the primary and secondary side of the terminal, since both sides are connected to an EtherCAT master.

Configuration example 4:

Blocking the EoE protocol under FoE

If the primary and secondary sides are connected in one EtherCAT line, the EoE protocol must be blocked by setting bit 14 (0x4000) in object 0xF800:01 on the terminal, since otherwise the terminal will be blocked (due to repeated ARP Ethernet requests).

Furthermore, the value 0x0100 (type 00 01) must be entered for 0xF800:02 (Comment = Config 2: Enable FoE Buffer). It doesn’t matter whether this is done on the primary or the secondary side of the EL6695 bridge terminal, since these settings are always also adopted on the respective other side.

Configuration example 5:

Changing the Device Config 0xF800

The object 0xF800 is configurable on both the primary and secondary side and is always adopted by the respective other side.

Care must be taken that the correct transition is selected: P → S must be off, I → P must be activated. Once this has been done it should look like the following illustration:

Configuration example 6:
Entry of both values in the device configuration 0xF800

Explanations regarding the program example

The program example in the attachment, which is intended to illustrate an FoE data transfer, is based on the state diagram for the write and read access illustrated in the following.

Configuration example 7:
State diagram for the example program: writing and reading random data by “OPEN”, “ACCESS” and “CLOSE”

The bEnabled flag defined in the program is intended for the control of the program and is used for the start condition or restart condition. On account of the additional declaration AT%I*, this flag can be linked with a “real” input of an input terminal in order to control the program “from the outside”, e.g. with a connected button (up +).

In addition, the bEnabled flag is tested for TRUE within state 1 of the state machine for writing the data, whereby the write process is then only started by an OPEN.

On account of the additional declaration AT%Q*, bDataEqual can be linked with an output variable of a terminal that provides digital outputs. By this one can see at the end whether the correct data transport has taken place.

The individual states 0 to 4 are programmed as follows as iWrState:

At the next start new random numbers are generated again, which should once again correspond to the read values when compared. The bDataEqual flag is provided for and can indicate this, as we shall see in the following.

The state diagram for the read access looks similar in principle and has in state 4 a program section for the data comparison of the written values with the read values.

The individual states 0 to 4 are programmed as follows as iRdState:

Configuration example 8:

Using the sample programs

This document contains sample applications of our products for certain areas of application. The application notes provided here are based on typical features of our products and only serve as examples. The notes contained in this document explicitly do not refer to specific applications. The customer is therefore responsible for assessing and deciding whether the product is suitable for a particular application. We accept no responsibility for the completeness and correctness of the source code contained in this document. We reserve the right to modify the content of this document at any time and accept no responsibility for errors and missing information.

→ Download example program FoE:

Program

Preparations for starting the sample programs (tnzip file / TwinCAT 3)