The following function get the time from the slave at which the EtherCAT frame went through it ecrt_master_reference_clock_time(master->master, &master->reference_time);
The following function will update the masters time with the last slaves time plus the app time period ecrt_master_application_time(master->master, master->reference_time+master->app_time_period); One problem is that the ecrt_master_application_time() call may not be exactly one master->app_time_period value beyond the slaves reference time. There are many sources of jitter in your application, from the realtime wakeup time to various amounts of processing time since the wakeup to the above function call. So you need to relate the ecrt_master_application_time() to your app's clock time. Another thing you need to do for option B is relate the previous master->reference_time to the ecrt_master_reference_clock_time() and adjust your apps's time base to account for drift. You can then sleep and wake up your rt thread in keeping with your slaves time period. Graeme. From: Ignacio Rosales Gonzalez [mailto:[email protected]] Sent: Wednesday, 24 January 2018 12:57 a.m. To: Graeme Foot <[email protected]> Cc: Boris Skegin <[email protected]>; [email protected] Subject: Re: [etherlab-users] Sync problems and DC mode 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 <[email protected]<mailto:[email protected]>>: 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:[email protected]<mailto:[email protected]>] On Behalf Of Boris Skegin Sent: Tuesday, 23 January 2018 2:07 p.m. To: [email protected]<mailto:[email protected]>; Ignacio Rosales Gonzalez <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://lists.etherlab.org/mailman/listinfo/etherlab-users
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
