CPU resource consumption with multiple EtherCAT devices

[psears]

I am using a cRIO 9074 as an EtherCAT master and am seeing extremely high CPU usage with only a handful of devices deployed, despite not performing any seemingly CPU-intensive tasks.

Setup: I am running a simple 100Hz timed loop synchronized to the scan engine which prints out a message to the debug console each cycle and samples CPU usage once every 100 cycles. As I add more drives (3rd party motor drives from Copley), I see the CPU load climb as follows:

Drives / CPU useage

0 / 43%

1 / 67%

2 / 74%

3 / 81 %

4 / 89%

5 / 95%

6 / 99 %

7 / 100%

Keeping in mind that I am not performing any other operation including PDO/SDO read/writes, I would expect much better performance. Supposedly EtherCAT is capable of communicating with dozens of devices at rates of up to 1 khz. Is this a limitation of the controller I am using, or do I need to take some other action to get the resource consumption under control?

Thanks,

Patrick

[Jesse_D]

Hey Patrick, 

By default the scan engine reserves 40% of the cpu time for ethercat. 

If you arent transfering much data you can change this. See the "EtherCAT:Basic Property Page" page of the ethercat help. 

[Jesse_D]

My last reply may not address your question, re-reading it. 

The 9074 does have a small processor. If you have a byte count or IO count you are transfering we can compare to benchmarks we run.  

In essence, the more CPU power you have the faster you can run ethercat. This should be independent of the type of drive you are talking to. 

[psears]

By byte count I assume you are referring to the bandwidth of all mapped PDO objects?

On each of the 7 drives, I transmit 4 objects (12 bytes) and recieve 4 objects (12 bytes). This seems like a quite low bandwidth so I am surprised to see such a performance hit with each additional drive. Is it possible that each drive reserves CPU time on top of the 40% that the scan engine reserves?

I'd be very interested in running benchmarks to compare system performance if you have any in mind.

[Jesse_D]

Correct,  

These benchmarks are roughly accurate. Our driver has slowed down slightly since they were posted because we have added more c-series modules. 

However, for 84 bytes I expect you easily will hit 1 kHz. 

I am still not convinced this is an ethercat issue though. The amount of time allocated for ethercat transfer will remain at 40% (or whatever you set it to) until too much data transfer is attempted in that time. 

To me it looks like something else is happening on the CPU to cause the additional time. Can you post you project? 

[psears]

I just updated to LabVIEW 2013 and started a clean project to test on, same result. I've also included a copy of the XML file I am using (it is for a Copley 090-36). For what it's worth, I tried running my project on a PXI chasis and it seems to handle the same code with minimal CPU load, but I'd love to see if there is a way to run this on a cRIO.

[psears · Accepted solution]

I seem to have discovered a solution to this problem.

I was using scanned I/O read/write blocks but did not connect the error terminals. When I wired the error terminals together in series I see a massive reduction in CPU consumption and can attain loop rates of >500hz.. It also seems to have helped that I removed extraneous software add-ons which lowered the baseline resource consumption on the cRIO.

[Jesse_D]

I recall that issue coming up but haven't observed it myself. You also may consider the programmatic API, you can just right click on the blocks and click "replace with programmatic access."