[Etherlab-users] load when reading SDOs

Fri Sep 19 02:46:26 CEST 2025

ecrt_master_sdo_upload is mainly intended for use when a master app is not running (or just starting, prior to realtime).  You can run it concurrently with a master app, but only from a non-realtime thread.  It's the equivalent of running the "ethercat upload" command.  There is a risk that this can impact the performance of the realtime thread, as under the hood it uses mutexes.  (YMMV for linux-default vs. linux-rt vs. Xenomai.)

The ring vs. alias addressing isn't usually a big problem, since you can enumerate the ring to translate from one addressing format to another.  There is a risk of a misread if the network changes while in the middle of a transfer (though that should hopefully be rare), but you can at least detect that by checking the network state before and after.  This may be impractical if you want to do frequent or constant polling of the SDOs, but it might be acceptable if this is only an occasional thing and if you can spread out queries to each device over time rather than bunching all devices together.

The sdo_requests are the way to go if you want to ensure there's reduced performance issues while concurrently running a master app, but you do need to use them correctly.  You create the SDO request before starting the realtime thread, then within the realtime thread you need to run a mini-state-machine where you do nothing when nothing is pending, call request_read/write just once to kick off a request, and call request_state once per cycle (or less often) only while a request is in progress.  (It's mostly harmless to call request_state unnecessarily, so you could just call it blindly if you don't want to separately track which requests are in progress, but I consider that bad style.)

At minimum you will need one request object per slave.  It's up to you whether you make only one per slave or one per SDO on that slave you want to read; either way, while you can queue up multiple requests (on distinct objects), only a single request per slave can actually make forward progress at a time.

Gavin Lambert

Software Engineer

[cid:TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png]
 [cid:TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg] <https://www.facebook.com/TOMRA.Food/>  [cid:TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg] <https://www.linkedin.com/company/tomra-food/>  [cid:icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg] <https://twitter.com/TOMRAFood>  [cid:TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg] <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6>  [cid:TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg] <https://www.instagram.com/tomrafood/>
 TOMRA Food (ANZ) Limited | 4 Henderson Place | PO Box 13 516 | Onehunga 1061 | New Zealand

 Phone: +64 96 34 00 88 | https://www.tomra.com/food
The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
From: Etherlab-users <etherlab-users-bounces at etherlab.org> On Behalf Of Mittermeier Franz
Sent: Friday, 19 September 2025 2:23 am
To: etherlab-users at etherlab.org
Subject: [Etherlab-users] load when reading SDOs

Hello all,

i try to read some SDOs from a slave, the PDOs are limited and that values need not to be updated with high frequency.

My first trial was using the function "ecrt_master_sdo_upload" in a non realtime task.
Problem here besides of the blocking behaviour is, that it needs the slave position and not its alias,
which i think is a problem in case of dynamically connected/disconnected slaves.

So i tried using the methods "ecrt_slave_config_create_sdo_request, ecrt_sdo_request_timeout ,ecrt_sdo_request_read, ecrt_sdo_request_state, ecrt_sdo_request_data"
in the realtime task.
That works, but with this i see a process "EtherCAT-OP" in the task list with a cpu load of more than 20%, while my test application consumes about 1%.
This is for reading only one SDO. Without reading the SDO "EtherCAT-OP" is also at about 1% load.

So my question, does reading one SDO really cause this high cpu load? Is there something wrong? Or am i on a totally wrong way to read some SDOs?

My test application is mainly derived from the "user" example, of course i can share the source if of interest.
It uses a cycle time of 5ms, so it should be not too fast.
It runs on a plc (Cortex A8) with Preempt_rt patch, etherCAT version is 1.6.1.
There are 4 slaves connected, 3 Beckhoff and one NORD inverter, from which I need to read the SDOs.

I really appreciate receiving some tips!

Best regards
Franz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png
Type: image/png
Size: 6455 bytes
Desc: TOMRA_CMYK_final_size_times_two_cd761a01-1d1f-446e-9316-8012271820b6.png
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: TF-FB-icon_b77c57e4-4990-4f9d-b3a2-8e6ab45df7f2.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: TF-LinkedIn-icon_d54c4829-dcb9-450c-9187-34b26e85ebaa.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg
Type: image/jpeg
Size: 2256 bytes
Desc: icons-social-media-twitter_small_2_4bae5ad2-4add-4314-a352-5b317f784956.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg
Type: image/jpeg
Size: 10218 bytes
Desc: TF-Youtube-icon_8b2c830c-70d9-48da-a4db-db9191d346ba.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: TOMRAinstagram_45b30c55-490a-4f32-8fd3-998c152e3494.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250919/896cd6eb/attachment-0009.jpg>