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.f...@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-boun...@etherlab.org] On > Behalf Of Boris Skegin > Sent: Tuesday, 23 January 2018 2:07 p.m. > To: etherlab-users@etherlab.org; Ignacio Rosales Gonzalez < > naro...@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@etherlab.org > http://lists.etherlab.org/mailman/listinfo/etherlab-users >
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users