[etherlab-users] Sync problems and DC mode

[Ignacio Rosales Gonzalez]

Thanks for your reply Graeme!

I would try your changes for the A method (a EtherCAT master is the master
clock:) putting domain_queue the first.

By the way for the B method (Slave DC master is the master clock) what is
wrong in this approach?:

  // send process data
  rtapi_mutex_get(&master->mutex);

  // queue domain data
ecrt_domain_queue(master->domain);


//get the DC slave reference clock time and save in master->reference_time
ecrt_master_reference_clock_time(master->master, &master->reference_time);

// sync slaves to ref clock
ecrt_master_sync_slave_clocks(master->master);

//update master time with time got from dc ref slave
  ecrt_master_application_time(master->master,
master->reference_time+master->app_time_period);

// send domain data

  ecrt_master_send(master->master);
  rtapi_mutex_give(&master->mutex);

Best regards,
Ignacio Rosales


2018-01-23 2:18 GMT+01:00 Graeme Foot <Graeme.Foot at touchcut.com>:

> As Boris says, master->app_time needs to actually match your PC's time
> (converted to your app's timeframe).
>
> Another change you could try is as below.  From line 1115:
>
>   // send process data
>   rtapi_mutex_get(&master->mutex);
>
>   // queue domain data
>   ecrt_domain_queue(master->domain);
>
>   // update application time
>   master->app_time = rt_get_app_time();
>   ecrt_master_application_time(master->master, master->app_time);
>
>   // sync ref clock to master
>   ecrt_master_sync_reference_clock(master->master);
>
>   // sync slaves to ref clock
>   ecrt_master_sync_slave_clocks(master->master);
>
>   // send domain data
>   ecrt_master_send(master->master);
>   rtapi_mutex_give(&master->mutex);
>
>
> You want as constant a time between calling ecrt_master_application_time()
> and ecrt_master_send() as possible.  The calls to ecrt_domain_queue() call
> takes variable amounts of processing time, so do that first.  Also call
> ecrt_master_sync_reference_clock() every cycle to ensure the reference
> slave gets lot of small updates rather than a few big updates.  This helps
> all slaves keep sync better.  It also avoids another source of variable
> processing time between ecrt_master_application_time() and
> ecrt_master_send().
>
>
> Graeme.
>
>
> -----Original Message-----
> From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On
> Behalf Of Boris Skegin
> Sent: Tuesday, 23 January 2018 2:07 p.m.
> To: etherlab-users at etherlab.org; Ignacio Rosales Gonzalez <
> narogon at gmail.com>
> Subject: Re: [etherlab-users] Sync problems and DC mode
>
> Hello.
>
> > With this version
> > <https://github.com/narogon/linuxcnc-ethercat/commit/e4ab86ba6167ced53
> > 2e49904059df580062b2d97#diff-059a684a933530837771b5a249433ff3>
> > (also as attachment lcec_main.c) I get the servos sync and OP but it
> > seems that the PDO doesn't arrive for some of the slaves (no idea why).
>
> master->app_time += master->app_time_period;  means that you just sum
> up constant cycle times of  the LinuxCNC thread. So any latency
> information gets lost here.
>
> Rather  make  master->app_time  be equal to something like
> rt_get_time() transferred to EtherCAT time.
>
> I also think that a proper value for sync0Shift  can help a lot.
>
> If however nothing of that helps, then proceed  to  Graeme Foot's option
> b) .
>
> BTW, what exactly is your kernel and network card and do you really use an
> adopted ( non-generic) network driver?
>
> Regards,
> boris
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20180123/343d006d/attachment-0003.htm>