Typically, the reference clock should be the first DC-capable device on the network (often an infrastructure device like a coupler, if present – as in your case), because the DC time only flows downstream from that. It’s unusual for it to be your DC-consuming device directly unless you don’t have any others. Thus, it’s not usually necessary to call ecrt_master_select_reference_clock unless you have special requirements (such as DC synching across multiple networks).
Since you’re using ecrt_master_sync_reference_clock_to and you’re saying that the DC time doesn’t appear to be advancing, ensure that your code actually does advance the time in your realtime loop – that’s your responsibility when you use that method rather than the alternatives. There can be many reasons why a device refuses to transition to SAFEOP (or does but then faults back to PREOP). You’ll need to review the syslog to see what error codes it’s reporting, if any. (But it could just be due to the DC time not advancing.) Try comparing your code against the existing examples such as dc_user, and pay close attention to your slave’s documented requirements for ecrt_slave_config_dc – in particular note that the SYNC1 time is specified in an unusual way. 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-boun...@etherlab.org> On Behalf Of dabb...@gmail.com Sent: Monday, 10 February 2025 9:54 pm To: etherlab-users@etherlab.org Subject: [Etherlab-users] DC and oversampling with EL2262 Dear Etherlab community, I have been using the EtherCAT master for a few days. I think I understand more or less how to configure the PDOs and domains for one or more slaves, but I'm having trouble with the distributed clock (DC). In particular, my setup is currently as follows: - master - Beckhoff EK1100 - Beckhoff EL2262 The latter is a digital output with oversampling capabilities. It can output a sample every Sync0, which in turn can be set to trigger faster than the application cycle. I used this slave successfully with other EtherCAT masters, so I know it is working properly. In my code I've set the PDOs using "ecrt_slave_config_pdos" and assigned them to the domain1 using "ecrt_slave_config_reg_pdo_entry". Then I've set this slave to be the reference clock using ecrt_master_select_reference_clock (master, sc); // Set this slave to be reference clock and finally I've set the DC settings (and Sync0/1) using "ecrt_slave_config_dc" (by the way, the AssignActivate data is 0x0730 for this slave). Then, for every application cycle I call, in order: - ecrt_master_application_time - ecrt_master_receive - ecrt_domain_process - check_domain1_state - ecrt_master_sync_reference_clock_to - ecrt_master_sync_slave_clocks - ecrt_domain_queue - ecrt_master_send The problems I see are: - the outputs are constantly OFF, even if I've set an alternating pattern of ON and OFF, - the slave stops at PREOP, - if I inspect the master from the cli using "ethercat master -v", I see that the reference clock is set to Slave 0, instead of Slave 1. Moreover, the DC reference time is set correctly every time I restart the application, but it does not update during execution. Conversely, the application time increase as expected - during " check_domain1_state", I see that the wc_state==EC_WC_ZERO (no process data exchanged) I am willing to share my code if it is required. Thank you for your help and, especially, thank you for providing such powerful software as open source. Best regards, Davide
-- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
