Inexplicable delay using EtherCAT

[TTRD]

Hello,

I am using a Desktop PC configured as LabVIEW Real-Time Target. The PC is connected to a Beckhoff EK1100 (with an EL1002 and an EL2004) via EtherCAT. For test purposes I connected a DO of the EL2004 to a DI of the EL1002. Via Stimulus profile editor I change the DO from 0 to 1 and log how long it takes until the Real-Time Target registers the change of the DI. I tried setting the rate of the primary control loop and data acquisition loop to 500 Hz, 1000 Hz and 2000 Hz (cycle time between 0.5 and 2 ms). The HP count and LP count are remaining 0 all the time. Thus, there shouldn't be any performance issues, right?.

However, the time from triggering the DO change until detecting the DI change is always between 12 and 20 ms. The weird thing is that the interval is constant as long as the real-time target is powered on. After turning the PC off and on again, the interval changes.

Further, I don't understand why the time between triggering and detection is that long. Concerning the IO-hardware the interval should be about 3 ms. I also tried to replace the LV-RT by a Beckhoff PLC (as EtherCAT-Master) and as expected the interval was about 3 ms. Now I am wondering what the problem could be using the LV-RT as EtherCAT-Master. May it be the custom device that is necessary to use the EK1100? I thought the execution of a custom device (implemented as "Inline HW Interface") takes one cycle. Am I wrong?

Or is the EtherCAT driver of LV-RT too slow? Or could it be the NIC of the Realtime-Target? Has anyone an idea what could cause the slow time interval and why the interval changes after turning the RT off and on again?

Regards,

TTRD

[TTRD]

Additionally, I wrote a LabVIEW VI that is executed on the Real-Time Target. If I press the button and the DO turns from 0 to 1 the counter is set to zero. When the input turns to 1 the value of the counter is displayed. When the timed loop executes with 1ms the value of the counter is the time delay from the output change to the input change. The value does vary between 11 and 19. Because of this result, I suppose the problem is not the custom device, but the EtherCAT implementation by itself.

Please correct me if I'm wrong.

[StephenB · Accepted solution]

Probably because the timed loop of NIVS and in your LV test are not synchronized to scan engine (ethercat).

change your LV test first and try that... If that works then go steal the "sync veristand to scan engine" implementation from the scan engine and ethercat custom device for your own custom device.

[TTRD]

Hello Stephen,

thanks for the answer. That was the problem. After synchronizing my LV test worked.

The "sync veristand to scan engine" implementation is not just one VI in the "Scan Engine and EtherCAT" custom device, isn't it?

Unfortunately, I will not be able to modify my custom device in the next two weeks. Thus, please don't wonder if I don't reply in this period.

Regards,

TTRD

[StephenB]

It is in the timing source VI that is mentioned in the custom device XML.

[TTRD]

Thanks for the answer. Copying the code from the VI and adding the appropriate section in the XML was everything I had to do. Now, the custom device is as fast as the used I/O hardware allows.

TTRD

[StephenB]

Fantastic! Thanks for following up