-
Notifications
You must be signed in to change notification settings - Fork 691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial Offset between Master and slaves - Distributed clock #494
Comments
Check this post on DC written by Arthur, #487 (comment). The offset between the master and the slave ref is controlled by the application (eg. you), check red_test ec_sync. Again, check the red_test sample. |
Thank you for your suggestion. Is the sequence of ec_send_processdata() and ec_receive_processdata() does matter?. Because only in linux\red_test example, the sequence is But in other examples the sequence is ec_send_processdata() immediately ec_receive_processdata()? Is there any significance? |
Yes and No. The "DC ref clock" timestamp is generated/taken when ec_send_processdata() is called and the frame is received in the DC ref slave. So, that is what you need to consider, how (1), (2), (3) affect the offset and what kind of jitter they can/may introduce. (3) is fairly constant, (1) as well if you call ec_receive_processdata() when a frame is expected to have been received. Using the seq below will use less CPU since you sleep when the frame is traveling in the EtherCAT slave network. (1). ec_receive_processdata(), |
Can you post your complete synchronized process data exchange function source (including any helper functions)? Then it would be obvious if there are any parts that might explain the behavior as in your scope images. Did you check with hardware other than your servo drives? Perhaps there is something odd with your servo drive firmware. For a similar test for a customer I once modified a simple Beckhoff IO slave. Soldered a wire directly on the sync0 output pin of the ET1200 EtherCAT chip. Then attached a scope to get a similar picture as your setup. By excluding any software after the sync0 signal you get the cleanest measurement possible. |
@nakarlsson @ArthurKetels |
Dear Sir, I observe a jitter on master waveform of about 100 microseconds, which is same as timer tick granularity of application. (2). we used gl_delta, instead of toff as toff is very small value which did not work to achieve the synchronization. I have attached the code used to test the master with two servo drives as slaves, even though entire application code is very huge. Please suggest is it right way to get proper synchronization? Thank you in advance. |
@aithalks , can this issue be closed? |
The code is working fine with above modification, and changing the timer tick duration of Operating system. |
Dear Sir,
I am using SOEM to control two servo drives. The master is x86 based single board computer. SOEM is modified to suit RTOS-32 operating system.
I could able to achieve the synchronization (DC-sync0) between master and two servo drives as slave. To check the synchronization, I am toggling digital output of parallel port, just before ec_send_processdata(); and toggling digital output at slaves using PDO variable.
But I have following problem:
The offset between master waveform and slave waveform is changing at every restart of the application. But remains synchronized with slaves, till the application is switched off.
Attached .JPG files are waveform captured at two different restart of application. (i.e., power on of the application).
Ch1 is master waveform, Ch4 is one of the slave waveform.
Please suggest any remedy to overcome this issue.
The text was updated successfully, but these errors were encountered: