[Etherlab-users] FW: DC synchronization demo about etherlab master

[Graeme Foot]

Hi Circle,

m_dcDiff should jitter around zero.  The previous slave time to current slave time should jitter around your period (e.g. 1ms).  The PC clock total adjustment should drift by an approximate constant amount over time.  It can drift at slightly slower or faster rates over time due to electronics issues (such as thermal changes etc.)

The master needs to account for the time drift between the ref slave and PC clock so that it interacts with the fieldbus in the fieldbuses timeframe.  Looking at 0x92C of subsequent slaves won’t help as that is their syncing to the ref slave.  We are dealing with the master syncing to the ref slave.

If you enable “ethercat debug 1” and start your app you should see in the logging (where main-1 is the ref slave number):

  *   Using slave main-1 as DC reference clock
  *   DEBUG 0-main-1: Checking system time offset.
  *   DEBUG 0-main-1: DC 64 bit system time offset calculation: system_time=50278625750, app_time=42973023400, diff=-7305602350
  *   DEBUG 0-main-1: Setting time offset to 18446744066403949266 (was 0)
  *   first master diff: -609.

The first master diff should be quite small (within the jitter range).

You shouldn’t be getting any "Failed to get reference clock time" messages.  What is the error number that is output with it?

I’m starting to think you may be getting comms errors or something.  Can you send the kernel log messages (e.g. dmesg / journalctrl -k) (with “ethercat debug 1” set before startup) and maybe the wireshark logs.

Check for comms error using the “ethercat crc” command, check for unmatched datagram errors in the system logs and potentially check the wireshark logs for mismatched frames around the time of your errors.

Also check that you have the CPU speed stepping (dynamic frequency scaling) turned off in the kernel configuration options.  That can cause problems with the timestamp clock.

If you have an intel CPU you may need to disable the SMI interrupt.

Also, what are the Yaskawa sync errors you are getting?  Are the A12 errors?  If so these generally only occur (by default) after three missed PDO’s in a row.  You don’t generally get those alarms when you are just having drifting errors.  Check the wireshark logs around the time of the error and check the reference clock times to see when the master is sending the frames.

Under RTAI you need to have the RTDM interface enabled to allow realtime calls from the user space into the masters kernel space.  RTAI will allow you to make non-realtime syscalls, but you will lose hard realtime while the syscall is occurring.  You can check for any lost hard realtime events using the “/cat /proc/rtai/scheduler” command.  I don’t know what the equivalent in Xenomi is.


Regards,
Graeme.


> From: Circle Fang circlefang at live.com<mailto:circlefang at live.com>
> Sent: Friday, 2 May 2025 05:33
> To: Graeme Foot Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>
> Cc: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
> Subject: 回复: DC synchronization demo about etherlab master
>
> Hi Graeme,
>
> I think I was wrong about option a and b. I should compare reference clock time "slaveTime" with ideal values( i.e.,  initial slaveTime + cycle_counters*cycle_ns); And if that difference soon converges to 0, rather than some big weird values for several consecutive cycles (bigger than "sync error limit" threshold in slave) occasionaly . that will prove master is well synced to reference, right?
>
> I should continue on this bug.
>
> How do u_appTimeBase and m_dcDiff change in your app? is there any patterns?
>
> Many thanks again for your help.
> Best Regards,
> Circle
>
>
________________________________
>发件人: Circle Fang <circlefang at live.com<mailto:circlefang at live.com>>
>发送时间: 2025年5月1日 16:22
>收件人: Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>
>抄送: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org> <etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>>
>主题: 回复: DC synchronization demo about etherlab master
>
> Hi Graeme,
>
> Where and what value should I monitor if I want to check if my master is well synchronized to reference slave or not? I think that value should eventually converges to 0 soon (or maybe some constant value). I used the following 2 options:
> Option a: Initially, I monitor the reference's slaveTime - prev_slaveTime, and it converges to 1000000, meanwhile the jitter of this value is about +- 20 us. I thought this should prove that the master is well synced to reference, since it implies that time of ecrt_master_send is well aligned, but dc sync error still occurs occasionally when app running for several hours.
> Option b: Then I start to monitor m_dcDiff in ecMaster_syncDistClock(since first m_dcDiff  is probably several milliseconds which i don't know why, marked as "fixed", so my m_dcDiff formula is m_dcDiff = (uint32_t)ecMaster->m_dcTime - slaveTime - fixed), and soon eventually it also converges to 0, meanwhile the jitter of m_dcDiff is about several microseconds.
> And I think Option a and b is essentially same. Can I use these values to check synchronization, like 0x92c in other slaves(BTW, 0x92x is no more than 30 nanoseconds usually).
>
> Sometimes I got error from master, "Failed to get reference clock time", even no dc sync error occurs meanwhile.
>
> At last, when I monitor u_appTimeBase, I can see it's increasing(or decreasing) monotonically, like, eventually 1 second per day. Is this normal? ( J1900 cpu and xenomai).
>
> Any ideas/advices are highly appreciated.
> Best Regards,
> Circle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20250502/b4aa0415/attachment-0001.htm>