T ESTING AND PERFORMANCE EVALUATIONS

The first test performed was to verify the EtherCAT Slave configurability feature as it was one of the principal requirements.

The Listing 7.1 shows the configuration file that was prepared and provided to the driver.

Listing 7.1 Test configuration file

In addition to the EtherCAT interface serial number, some process variables are configured. Four variables of different data types are read form the EtherCAT frame, and four variable of different data types are written in the EtherCAT frame and provided to the network.

The EtherCAT Slave driver was started with the given configuration. Figure 7.1 shows the result of the configuration loading where the configuration is correctly loaded.

#Interface serial number interface: A04A8FF6

# Input from the PLC VarIn_UInt32:uint32:in VarIn_Int16:int16:in VarIn_Float:float:in VarIn_Bool:bool:in

# Output to the PLC VarOut_UInt32:uint32:out VarOut_Int16:int16:out VarOut_Float:float:out VarOut_Bool:bool:out

106

Figure 7.1 Result of the configuration loading.

The loaded configuration is provided to the driver, so the configuration is loaded into the EtherCAT Slave interface as shown in Figure 7.2.

Figure 7.2 Mapping of the process variable in the slave.

As can be seen in the Figure 7.2, during the INIT state, four ADIs are correctly mapped in the “read” direction (mapped read ADI), and four ADIs are correctly mapped in the “write”

direction (mapped write ADI). The read and write processes data size were also correct since eleven bytes of data matched with the used data types: one 32-bits unsigned integer (4 bytes long), one 16-bit signed integer (2 bytes long), one floating point (4 bytes), and a Boolean (1 byte long).

Once the EtherCAT Slave is configured a network scan was performed from the EtherCAT Master. The scan was made inside TwinCAT with the system in configuration mode.

107

Figure 7.3 The result of the network scan

Figure 7.3 shows the result of the network scan. As can be seen the EtherCAT Slave was correctly found and the process data correspond to the given configuration.

At this point the TwinCAT configurator was used to map the variables to the PLC process data and then the configuration was flashed on the Beckhoff PC to be executed in the TwinCAT runtime environment. Figure 7.4 and Figure 7.5 show how the data are correctly received in both directions.

Figure 7.4 Data written by the PLC and received by the slave.

Figure 7.5 Data written by the slave and received by the PLC.

108

A second test was performed to assess the time taken by an EtherCAT frame to traverse through the network back to the master. This time is called roundtrip time and it is directly calculated by TwinCAT in the EtherCAT tab which becomes available when the EtherCAT master device is selected in the IO tree.

Figure 7.6 The EtherCAT tab

Figure 7.6 shows the EtherCAT tab. In the table at the bottom the following information are available:

▪ Frame column shows the number of the cyclic transfer frame, which contains the respective EtherCAT command. An EtherCAT transfer frame can contain one or more EtherCAT commands.

▪ Cmd column shows the type of the respective EtherCAT command.

▪ Addr column shows the address of the data section of the EtherCAT slave device that addresses the respective command. If the respective EtherCAT command uses logical addressing (LRW, LW or LR), then the column specifies the logical address.

▪ Len column shows the length of the addressed data section.

▪ WC column shows the expected “working counter”. Each EtherCAT slave device addressed by an EtherCAT command increments the “working counter”. In case of read/write command 3 means that both operations are successful.

▪ Sync Unit column shows the name of the Synch Unit associated with the EtherCAT command.

▪ Cycle (ms) column shows the cycle time with which the transfer frame is sent.

▪ Utilization (%) column shows the EtherCAT load in percent.

109

▪ Size/Duration (µs) column indicates the size of an EtherCAT frame in bytes and the time in microseconds that a frame needs to circulate in the network.

The test was performed by providing different configuration files increasing the number of 4 bytes data types up to the maximum length for the data section in an EtherCAT frame.

The chart in Figure 7.7 shows the variation of the round-trip time as function of the number of bytes and number of variables in the EtherCAT frame. As can be seen a frame with the maximum allowed data length has a round-trip time of almost 100 microseconds as stated in the EtherCAT specification.

Figure 7.7 EtherCAT frame round trip time as function of the data size

A third and final test was performed using the Testbed.CONNECT system as EtherCAT Master and the EtherCAT Slave executed under the INtime RTOS. The EtherCAT Slave was configured with the same configuration file used for the test performed under Windows OS.

Then the ENI file was exported from TwinCAT and provided to the Testbed.CONNECT Navigator which is the application used to configure the system. A simple RT model was developed to generate a sawtooth signal and then was executed in real time at the maximum allowed frequency of 10KHz so that new data are sent with a cycle time of 100 microseconds.

The generated signal is periodic with a period of one second so the values from 0 to 9999 are generated by the real time model.

Since was not possible to launch the EtherCAT Slave in the Testbed.CONNECT the generated sawtooth signal was looped back in the application to achieve the results.

The Testbed.CONNECT can measure how many cycles (steps) are necessary to see back a value sent previously.

Figure 7.8 shows the setup that was used to execute the final test.

110

Figure 7.8 The setup for the test with Testbed.CONNECT.

To launch the real time version of the driver application the hardware interface was first provided to INtime node for the control. The operation was performed using the INtime configuration application.

Figure 7.9 Passing the EtherCAT Slave interface to INtime.

As shown in Figure 7.9 the INtime Device Manager applet is selected to access the INtime Device Manager windows, then the INpact PCIe interface node under Windows devices was right clicked and the item Pass to INtime using MSI was selected. The operation was applied by clicking on the exclamation mark button in the toolbar. The control of the interface was successfully transferred to the NodeA under the INtime devices tree as shown in Figure 7.10.

Figure 7.10 EtherCAT slave interface passed to INtime.

111

The real time application is launched by the INtime Explorer application which allowed to select the desired .rta file from the system and run it on the desired INtime node. The INtime Explores is shown in Figure 7.11.

Figure 7.11 INTime Explorer to load and launch real time applications.

The application was left running for 17 hours (overnight test) and the round-trip time was measured.

The Figure 7.12 shows the result of the round-trip time measured during the test in terms of execution steps at 10KHz. As can be seen the delay has a mean value of 4 steps with a maximum of 5 steps and a minimum of 3 steps; moreover, no drifts were seen over the whole test duration. At a frequency of 10KHz the time delays were respectively 400 µsec, 500 µsec, and 300 µsec.

Figure 7.12 Delay measured with Testbed.CONNECT @10KHz

112