[Etherlab-users] DC and oversampling with EL2262
dabbede at gmail.com
dabbede at gmail.com
Fri Feb 14 12:28:33 CET 2025
Dear Gavin,
thank you for your insight and sorry if I didn't reply earlier... your
message has been classified as spam and I missed it...
Yes, I know that usually the reference clock is assigned to the first
DC-capable slave: in my simple setupthis slave is the bus coupler EK1100,
but other EtherCAT masters refuse to assign the reference to a coupler, and
generally use the first "normal" slave. This is the case for TwinCAT and
Koenig Pa., for example. Moreover, I don't have an "AssignActivate" word
for EK1100... Anyway, I've tried both with and without the specification of
"ecrt_master_select_reference_clock" and the result does not change: the
reference clock is always Slave 0, and the DC reference time does not
advance.
Since I was having issues on sending EL2262 to "OP", later I've tried to
use a different slave with similar characteristics (DC capable and
oversampling), which is EL3702. With that, I could go "OP" without problem,
but all the other issues related to the reference clock staying assigned to
Slave 0 (despite ecrt_master_select_reference_clock ) and DC reference time
which does not advance remained the same.
Of course I strictly followed the example dc_user (that was my starting
point), and in fact my cyclic task has this form:
clock_gettime(CLOCK_TO_USE, &time);
ecrt_master_sync_reference_clock_to(master, TIMESPEC2NS(time));
ecrt_master_sync_slave_clocks(master);
I don't know if I'm allowed to attach files to this mailing list. I'm going
to try with a minimal example and, if it does not work, I'll copy in the
next message the content of the file.
I don't know if anyone of you owns a EL3702 to try replicate the error, but
this is what I can see with the attached minimal example:
- the file compiles properly, and does run "as expected" without printing
any "if-exception"
- the output is
Activating master...
Using priority 97.
Starting cyclic function.
2 slave(s).
AL states: 0x02.
Link is up.
AL states: 0x08.
Domain1: WC 1.
Domain1: State 2.
- the command ethercat config -v gives
Alias: 0
Position: 0
Vendor Id: 0x00000002
Product code: 0x044c2c52
Attached slave: 0 (OP)
Watchdog divider: (Default)
Watchdog intervals: (Default)
SDO configuration:
None.
IDN configuration:
None.
Feature flags:
None.
Alias: 0
Position: 1
Vendor Id: 0x00000002
Product code: 0x0e763052
Attached slave: 1 (OP)
Watchdog divider: (Default)
Watchdog intervals: (Default)
SM0, Dir: Input, Watchdog: Default
PDO 0x1b00
PDO entry 0x6800:01, 16 bit
PDO 0x1a00
PDO entry 0x6000:01, 16 bit
SM1, Dir: Input, Watchdog: Default
PDO 0x1b01
PDO entry 0x6800:02, 16 bit
PDO 0x1a80
PDO entry 0x6000:02, 16 bit
SM2, Dir: Input, Watchdog: Default
PDO 0x1b10
PDO entry 0x1d09:98, 32 bit
SDO configuration:
None.
IDN configuration:
None.
Feature flags:
None.
DC configuration:
AssignActivate: 0x0730
Cycle [ns] Shift [ns]
SYNC0 1000000 0
SYNC1 1000000 0
- the command ethercat master -v gives
Master0
Phase: Operation
Active: yes
Slaves: 2
Ethernet devices:
Main: 00:12:cd:07:a3:4a (attached)
Link: UP
Tx frames: 2102849
Tx bytes: 139702270
Rx frames: 2102848
Rx bytes: 139702206
Tx errors: 0
Tx frame rate [1/s]: 1000 1000 995
Tx rate [KByte/s]: 64.2 64.2 63.9
Rx frame rate [1/s]: 1000 1000 995
Rx rate [KByte/s]: 64.2 64.2 63.9
Common:
Tx frames: 2102849
Tx bytes: 139702270
Rx frames: 2102848
Rx bytes: 139702206
Lost frames: 0
Tx frame rate [1/s]: 1000 1000 995
Tx rate [KByte/s]: 64.2 64.2 63.9
Rx frame rate [1/s]: 1000 1000 995
Rx rate [KByte/s]: 64.2 64.2 63.9
Loss rate [1/s]: 0 0 0
Frame loss [%]: 0.0 0.0 0.0
Distributed clocks:
Reference clock: Slave 0
DC reference time: 6591555116393
Application time: 6842454116393
2000-01-01 01:54:02.454116393
Notice that DC reference time and application time are different and that,
while the latter updates at each call, the first does not.
The original code was more complicated, to account for the oversampling
also in the PDOs, but even this minimal one with oversampling = 1 still
does not work, so I don't understand if I'm missing something or if these
types of slaves are not supported...
Thank you all for your patience and for any guidance.
Regards,
Davide
On Tue, Feb 11, 2025 at 4:15 AM Gavin Lambert <gavin.lambert at tomra.com>
wrote:
> 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
>
>
>
>
> [image: tomra facebook] <https://www.facebook.com/TOMRA.Food/> [image:
> tomra linkedin] <https://www.linkedin.com/company/tomra-food/> [image:
> tomra twitter] <https://twitter.com/TOMRAFood> [image: tomra youtube]
> <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6> [image: tomra
> instragram] <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 *dabbede at gmail.com
> *Sent:* Monday, 10 February 2025 9:54 pm
> *To:* etherlab-users at 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 at etherlab.org
> https://lists.etherlab.org/mailman/listinfo/etherlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/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: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/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: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/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: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/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: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/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: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/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: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/attachment-0009.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal.c
Type: application/octet-stream
Size: 6640 bytes
Desc: not available
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250214/62f9e507/attachment-0001.obj>
More information about the Etherlab-users
mailing list