On 16 May 2018 4:34 a.m., quoth Michael Ruder: > Now I want to have the slaves also synchronized to this time frame and have > the following dilemma: > > - normally, I would like to call > > // cycle begins > > ecrt_master_receive(master); > ecrt_domain_process(domain1); > > // do a lot of stuff > > clock_gettime(CLOCK_REALTIME, &time); > ecrt_master_application_time(master, ((time.tv_sec - 946684800ULL) * > 1000000000ULL + time.tv_nsec)); > > ecrt_master_sync_reference_clock(master); > ecrt_master_sync_slave_clocks(master); > > ecrt_domain_queue(domain1); > ecrt_master_send(master); > > // cycle ends, wait for next cycle > > However, as the "lot of stuff" takes different amounts of time, this seems to > be not good, as this means a few hundred microseconds jitter as to when the > application time is set in our (1 ms long) cycle.
While it's true that this produces jitter in terms of when the packets actually go through, with the code above it won't adversely affect the slave clocks (or at least not much worse than the accuracy of CLOCK_REALTIME). Technically speaking, the "best" (most accurate you can) time to call ecrt_master_application_time is immediately prior to ecrt_master_send; this is the call that actually kicks off the datagram transmission and actually sends the values to the slaves. (All of the prior methods, including ecrt_master_sync_reference_clock, merely request that the datagram be sent on the next ecrt_master_send, without actually capturing the specific data.) Thus in most cases it makes sense to use the above pattern (perhaps moving your ecrt_master_application_time call to make the time accuracy slightly less dependent on your domain size), since as you pointed out in the rest of your message the minimum delay between ecrt_master_send and ecrt_master_receive is unknown, and you might as well let the CPU relax and do other work during this time. For especially fast RT cycles or for slaves that are highly sensitive to output jitter it can sometimes make sense to use an altered cycle pattern like you suggested, although this has the caveat of either busy-waiting or imprecise waiting between the two calls. _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
