It takes a long time to synchronize with the slave

[casinia]

Hi. I am using SOEM to communicate with the slave. I use ec_sync to calculate toff with red_test.c, but it takes fifteen minutes for the master to synchronize with the slave SYNC interrupt. I used the oscilloscope to test. The blue waveform is that the primary station flips the DO level every time the data is sent. The green waveform is that the slave station does not enter a DC interrupt and flips the DO level. I don't know if my test method is correct, and I don't know why it takes fifteen minutes to synchronize through the waveform, although the slave has already reached the OP state.

[ArthurKetels]

What is your hardware? Is your master clock accurate enough? Any picture available you mention above? Any wireshark trace? Can you make a plot with toff?

DC sync should normally happen within 100ms or so.

[casinia]

This is a waveform that was unsynchronized 15 minutes ago. I turned on the oscilloscope's afterglow effect. This is a waveform that is successfully synchronized after fifteen minutes. This is the data that was fetched when the synchronization was not successful. 15min_before.zip

[casinia]

I am using the RTEMS 4.11. I also found someone use RTEMS in the previous Issues, but it seems to be a problem with synchronization.

The master is using ZYNQ-7020, and the slave's EtherCAT chip is LAN9252.

[ArthurKetels]

The wireshark trace looks ok. One thing to note is that it is advised at the start of pre-op to send a burst of 1000 DC sync packets back to back with no or minimal pause. This will greatly improve the slave to slave DC locking.

But if it is the master that does not lock to reference slave clock then there is something wrong with the PI controller in the SOEM sample. Increase gain. Another, but unlikely, cause could be that the master clock is too far off. DC only works up to 850ppm clock drift.

Could you make a plot or csv file that shows toff?

[casinia]

I make a plot of more than 1000 cycles of toff at the start of Safe-op.

How do I increase gain?

[casinia]

I also noticed that the mastertime64 obtained in ecx_configdc is 3348282508094030000.

[ArthurKetels]

Yes your mastertime64 is some 100 years in the future. Please make a simple program that reads mastertime and print/log it. There should be a large time deviation visible. Even eyeballing is accurate enough.

Like a wrote before, the DC algorithm only works reliably when the clocks are less than 850ppm appart.

It could be that on your platform time is in cpu counts instead of real time.

[nakarlsson]

Inactive?

[casinia]

Can I reopen this question?

[ArthurKetels]

Off course. If you have new input.

[casinia]

Just like what u said, on myplatform CLOCK_MONOTONIC time is cpu counts instead of real time. So i use CLOCK_REALTIME, because i used RTC and I synchronized the system time with RTC during system initialization.

[casinia]

But why multiply by 1000000 here, is the unit of mastertime.sec not a second?

[nakarlsson]

Do you need two issues for the sync issue? Ref #391

[ArthurKetels]

Mastertime64 is in ns. As is the standard EtherCAT specification.

[nakarlsson]

@ArthurKetels , it think we're missing a few zeros right? Should be 1000000000 for conversion s -> ns

[ArthurKetels]

Yes, you are right. This is a bug.

[ChenHades666]

This is not a bug, first multiply the seconds by 1000000 to get microseconds, and then multiply the total microseconds by 1000 to get nanoseconds, no problem.