[Etherlab-users] DC and oversampling with EL2262
Gavin Lambert
gavin.lambert at tomra.com
Sun Mar 2 23:22:48 CET 2025
The latency between master and first slave will usually be higher than from first slave to next; likewise for jitter. That’s part of the reason why a slave is always the reference clock rather than the master. I’m not sure if that’s expected to translate to a higher time difference or if that’s a quirk of the EK1100; it’s never seemed to be a problem in practice for me, so I never looked into it too closely.
If you have a look at the rtai_rtdm_dc example (bearing in mind that this is for RTAI/Xenomai, so will not directly translate), there’s an alternative clock approach controlled by SYNC_MASTER_TO_REF which perhaps you might prefer – rather than passing the master time to the reference clock at all it just allows the reference clock to free-run and then calculates a conversion between the master and reference clocks. You’re not really losing anything from this approach because the CLOCK_MONOTONIC master clock isn’t providing “full” DC time anyway (and most slaves are perfectly happy with that). This isn’t necessary, though; either method works perfectly fine.
Regarding selecting the reference clock, as previously mentioned it should be possible to select a different clock (though you usually wouldn’t). Check the syslog during your application startup for messages related to the reference clock; it should tell you which slave it’s selecting and why.
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: dabbede at gmail.com <dabbede at gmail.com>
Sent: Saturday, 1 March 2025 12:13 pm
To: Gavin Lambert <gavin.lambert at tomra.com>
Cc: etherlab-users at etherlab.org
Subject: Re: [Etherlab-users] DC and oversampling with EL2262
Dear Gavin,
I've managed to address the last question (reading the register in application interface) using ecrt_reg_request_read() and ecrt_reg_request_data()... I had just missed their reference in the docs when I searched the first time.
Now, my setup has evolved like this:
- EK1100
- EL2262
- EL3702
The last two modules are able to oversample data using Sync0 and Sync1. My example code is to test the synchronization among the two, and for this they are wired together.
From what I can tell, most of the functionality seems to work. By using the ecrt_reg_request_read() on register 0x92c I can confirm that both EL2262 and EL3702 are indeed synced (well below 1000ns, normally around 10ns or so), even when my application period is as low as 200us.
So far, so good. What still bothers me is the first slave (EK1100) being the reference clock, because that slave has a residual time difference in the order of 1000ns or 10000ns. Since I was wondering about a defective unit, I've also tried to replace it, without any improvement. Moreover, I can't change the reference clock using ecrt_master_select_reference_clock()... this command is simply silently ignored...
My questions are:
- is it normal to have such a high time difference on the first DC slave? Maybe is it normal for the EK1100?
- Should I worry or, as long as the other 2 are synced, everything is as good as it could be?
Thank you for your support, best regards
Davide
On Mon, Feb 24, 2025 at 10:35 PM dabbede at gmail.com<mailto:dabbede at gmail.com> <dabbede at gmail.com<mailto:dabbede at gmail.com>> wrote:
Dear Gavin,
thanks for your precious help! I had no idea that all the slaves must obey the same ESC register as Beckhoff's ones... I was assuming that the ESI file was needed to specify these sorts of things.
I was also assuming that there was a "lower level" (hardware) memory area with addresses not necessarily aligned with the "higher level" (logical) registers...
I guess it makes more sense, now, but I'm still in doubt if I miss something in my "vision" of every piece in the puzzle...
Anyway, so now I downloaded the register manual for Beckhoff ET1100, and I can confirm that register 0x09A4 is used to set the offset - not the cycle - between Sync0 and Sync1.
(I was not doubting your explanation, I was just checking if I could find the same info there, for future reference).
Regarding ecrt_master_reference_clock_time(), you correctly spot the error: I was calling it after ecrt_master_sync_slave_clocks(). I'm still confused why it should make any difference where I call the query, but I've learned the lesson and I'm not gonna move it.
I think I'm almost done, but unfortunately I still think that something fishy is hitting my configuration... As I previously wrote, I cannot select the reference clock using ecrt_master_select_reference_clock(). No matter my choice, the CLI command "ethercat master" always shows that the ref clock is slave 0 (the coupler EK1100). In theory I would not mind that, but what bothers me is that if I issue a sync check with ecrt_master_sync_monitor_queue() and ecrt_master_sync_monitor_process(), I always find "big" numbers, well above 1000 and often 10000 or more (at application start, the number is even bigger, so for sure some synchronization has been performed, just not as good as hoped). At the same time, if I call "ethercat reg_read -p1 -tsm32 0x92c" from the CLI, I receive small numbers, in the order of ~10 for slave 1 and 2, while I get big numbers only for slave 0...
If EK1100 supports DC, it should be able to get below 1000 without any problem... Is my slave defective? Is there anything else I can change to force the synchronization to a slave in position > 0?
Moreover: the command "ethercat reg_read -pX -tsm32 0x92c" seems a reliable way to ensure that DC is properly configured... is there a way to get the same output within the (userspace) Application Interface?
Thanks again, best regards,
Davide
On Wed, Feb 19, 2025 at 1:35 AM Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>> wrote:
The behaviour of Sync1 is common to all masters and slaves; it’s a quirk of how Beckhoff specified the EtherCAT ESC. If you have access to the hardware datasheets, it’s documented in the behaviour for the DC configuration registers; unfortunately, I’m not allowed to reproduce my copy of it here. The Etherlab master simply writes the values given directly to the corresponding registers during slave configuration. Unfortunately, Beckhoff’s own slave documentation (which should specify this sort of thing) only focuses on configuration via the TwinCAT UI and ignores other masters. Still, if you dig into the XML files or inspect the configuration packets it’s possible to extract the actual configuration that it sends, which follows those rules.
Regarding ecrt_master_reference_clock_time, it will return EIO if the time synchronisation datagram has not circulated yet. Ensure that you call it before calling ecrt_master_sync_slave_clocks and after receiving datagrams. It will likely still error out the first time it’s called.
As for the “DC reference time” in the “ethercat master” output, it looks like that is only updated (based on ecrt_master_application_time) when the master is activated; it’s used as a reference to calculate various DC delay offsets, not as a representation of the current time. The “Application Time” is the current time (still based on ecrt_master_application_time).
Gavin Lambert
Software Engineer
[cid:image001.png at 01DB8C2C.AF9A5B60]
[cid:image002.jpg at 01DB8C2C.AF9A5B60] <https://www.facebook.com/TOMRA.Food/> [cid:image003.jpg at 01DB8C2C.AF9A5B60] <https://www.linkedin.com/company/tomra-food/> [cid:image004.jpg at 01DB8C2C.AF9A5B60] <https://twitter.com/TOMRAFood> [cid:image005.jpg at 01DB8C2C.AF9A5B60] <https://www.youtube.com/playlist?list=PLDD3B1A7BAE919EC6> [cid:image006.jpg at 01DB8C2C.AF9A5B60] <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: dabbede at gmail.com<mailto:dabbede at gmail.com> <dabbede at gmail.com<mailto:dabbede at gmail.com>>
Sent: Tuesday, 18 February 2025 10:32 am
To: Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>>
Cc: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: Re: [Etherlab-users] DC and oversampling with EL2262
Dear Gavin,
thank you for the help. The Sync1 specification was completely obscure to me. If it is something "general" (not slave specific) I think it should be better described in the documentation.
Regarding my example, with EL3702 I think I'm starting to approach a working solution: the slave is OP and oversampled data appears every cycle.
What I still don't completely understand is why if I run in the terminal the command "ethercat master -v" I see that the DC reference time does not increment.
To better understand this, I've tried to check the return values in my code after calling "ecrt_master_sync_reference_clock_to()" or "ecrt_master_sync_reference_clock()" (used exclusively one or the other) and they both are 0.
Then, I tried to read the reference clock using the provided function "ecrt_master_reference_clock_time()" and, in this case, I get the return -5 (-EIO) and the print message "Failed to get reference clock time: Input/output error"
In another console, if I check the DC residual error by continuously watch "ethercat reg_read -p1 -tsm32 0x92c", I see that the number starts big and gradually reduces to ~<100.
This information seems to contradict each other: on the one end the application seems to work, and the time error is minimal, on the other it seems that the reference clock is not properly set...
I don't know who to trust :-)
Have you any idea why ecrt_master_reference_clock_time() could fail? Is it an error in the slave configuration or in the master?
Thanks again, and best regards
Davide
On Sun, Feb 16, 2025 at 11:36 PM Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>> wrote:
>
> The EK1100 is DC-capable (it has a DC clock and can be assigned as reference clock) but does not actually use DC-application functionality, so you don’t call ecrt_slave_config_dc on it (thus it doesn’t need an AssignActivate word).
>
>
>
> Note that if you have Sync0 = 1000000 and Sync1 = 1000000 then you are not 1x sampling, you are 2x sampling (Sync0 pulses at 1000000ns and Sync1 pulses at 2000000ns, so your application cycle interval should be 2000000ns). Sync1 is an offset; it works differently than Sync0. Blame Beckhoff.
>
>
>
> If you actually want 1x sampling at an application cycle rate of 1000000ns then you need to specify Sync0 = 1000000 and Sync1 = 0. For 4x sampling at 1000000ns then Sync0 = 250000 and Sync1 = 750000. You may also need a non-zero Sync0 shift value; for that you’ll need to check the documentation of your slave.
>
>
>
> Gavin Lambert
>
> Software Engineer
>
>
>
>
>
> 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: dabbede at gmail.com<mailto:dabbede at gmail.com> <dabbede at gmail.com<mailto:dabbede at gmail.com>>
> Sent: Saturday, 15 February 2025 12:29 am
> To: Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>>
> Cc: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
> Subject: Re: [Etherlab-users] DC and oversampling with EL2262
>
>
>
> 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<mailto: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
>
>
>
>
>
> 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<mailto:etherlab-users-bounces at etherlab.org>> On Behalf Of dabbede at gmail.com<mailto:dabbede at gmail.com>
> Sent: Monday, 10 February 2025 9:54 pm
> To: etherlab-users at etherlab.org<mailto: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<mailto: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/20250302/ab244bc1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 6455 bytes
Desc: image001.png
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250302/ab244bc1/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 10123 bytes
Desc: image002.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250302/ab244bc1/attachment-0010.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 10214 bytes
Desc: image003.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250302/ab244bc1/attachment-0011.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 2256 bytes
Desc: image004.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250302/ab244bc1/attachment-0012.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 10218 bytes
Desc: image005.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250302/ab244bc1/attachment-0013.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 10303 bytes
Desc: image006.jpg
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250302/ab244bc1/attachment-0014.jpg>
-------------- 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/20250302/ab244bc1/attachment-0003.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/20250302/ab244bc1/attachment-0015.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/20250302/ab244bc1/attachment-0016.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/20250302/ab244bc1/attachment-0017.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/20250302/ab244bc1/attachment-0018.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/20250302/ab244bc1/attachment-0019.jpg>
More information about the Etherlab-users
mailing list