Skip to content
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

Closed
aithalks opened this issue Mar 30, 2021 · 8 comments
Closed

Initial Offset between Master and slaves - Distributed clock #494

aithalks opened this issue Mar 30, 2021 · 8 comments

Comments

@aithalks
Copy link

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.

if (sToggle == 1)
{
	RTOut(DATAPORT, 0xFF);
	CmdOutStrct->DigOut1 = CmdOutStrct->DigOut1 | 0x00010000;
	CmdOutStrct->DigOut2 = CmdOutStrct->DigOut2 | 0x00010000;
	sToggle = 0;
}
else if (sToggle == 0)
{
	RTOut(DATAPORT, 0);
	sToggle = 1;
	CmdOutStrct->DigOut1 = CmdOutStrct->DigOut1 & 0xFFFEFFFF;
	CmdOutStrct->DigOut2 = CmdOutStrct->DigOut2 & 0xFFFEFFFF;
}
ec_send_processdata();			/* First send, afterwords receive */
ec_receive_processdata(100);

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.

PHOTO_20210328_084047

    --------------------------                                               -------------------------------
    |                                    |                                              |                                            |       master waveform
    |                                    |                                              |                                            |
    |                                    |                                              |                                            |

            ----------------------------                                                  -----------------------------
            |                                       |                                                  |                                        |   slave waveform
            |                                       |                                                  |                                        |
            |                                       |                                                  |                                        |        

PHOTO_20210328_083818

    --------------------------                                               -------------------------------
    |                                    |                                              |                                            |       master waveform
    |                                    |                                              |                                            |
    |                                    |                                              |                                            |

      here time between master and slave changes.

                    ----------------------------                                                  -----------------------------
                    |                                       |                                                  |                                        |   slave waveform
                    |                                       |                                                  |                                        |
                    |                                       |                                                  |                                        |        

Please suggest any remedy to overcome this issue.

@nakarlsson
Copy link
Contributor

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.
So, when you do the (re-)start of the application, you need an step where you synchronize the master to the Slave DC ref clock, basically check the incoming DC ref clock and control your master process data cycle to be synchronized with that.

Again, check the red_test sample.

@aithalks
Copy link
Author

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
(1). ec_receive_processdata(),
(2). other work of master
(3). ec_sync calculation
(4). ec_send_processdata().

But in other examples the sequence is ec_send_processdata() immediately ec_receive_processdata()?

Is there any significance?

@nakarlsson
Copy link
Contributor

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.
(2) depends on your application.

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(),
(2). other work of master
(3). ec_sync calculation
(4). ec_send_processdata().
(5). "sleep" for ec_sync calulation time

@ArthurKetels
Copy link
Contributor

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.

@aithalks
Copy link
Author

@nakarlsson
thank you. I will try in a similar manner as you suggested and will give the feedback.

@ArthurKetels
Thank you sir for your comment. Right now the full source code is very huge which includes full CNC functionality. I will definitely extract relevant code related to synchronized PDO exchange and post it. Mean time I will do above experiment.

@aithalks
Copy link
Author

Dear Sir,
With your suggestion, I am able to get initial offset between master and slaves fairly same after every time (re)start of application.

PHOTO_20210410_160200

I observe a jitter on master waveform of about 100 microseconds, which is same as timer tick granularity of application.
We use RTOS-32 operating system (www.on-time.com). As per manual setting lesser timer tick (lesser granularity) will have higher overhead on OS, hence we set the timer tick as 100 microseconds. Hence RTKDelayUntil() [clock_nanosleep() equivalent] gives the jitter of 100 microseconds.

(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?

AceEcat-Soem -Forum.zip

Thank you in advance.

@nakarlsson
Copy link
Contributor

@aithalks , can this issue be closed?

@aithalks
Copy link
Author

The code is working fine with above modification, and changing the timer tick duration of Operating system.
Thank you for your support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants