[etherlab-users] Where, in the application cycle, should I call ecrt_master_64bit_reference_clock_time/queue?
Gavin Lambert
gavin.lambert at tomra.com
Thu Oct 25 23:29:03 CEST 2018
ecrt_master_64bit_reference_clock_time_queue must be called at any point prior to calling ecrt_master_send.
ecrt_master_64bit_reference_clock_time must be called following some previous calls to ecrt_master_64bit_reference_clock_time_queue, ecrt_master_send, and ecrt_master_recv (in that order), and before calling ecrt_master_64bit_reference_clock_time_queue a second time. (It doesn’t have to be on the immediately subsequent cycle, but that usually makes the most sense.) Interleaved calls to other functions are irrelevant (apart from closing the master, of course).
This should be fairly obvious, if you think about it. (And it’s documented.)
As for how often to call them, that’s entirely up to how often you want the answer, either for internal diagnostics or to look at the datagram in the network trace. It is purely informational and does not affect slave clock synchronisation. If you’re not interested in the answer, then you don’t need to call it at all.
From: Mohsen Alizadeh Noghani <m.alizad3h at gmail.com>
Sent: Thursday, 25 October 2018 20:28
To: etherlab-users at etherlab.org; Gavin Lambert <gavin.lambert at tomra.com>; Graeme.Foot at touchcut.com
Subject: Where, in the application cycle, should I call ecrt_master_64bit_reference_clock_time/queue?
Hello everyone.
I would like to know where should I call
ecrt_master_64bit_reference_clock_time_queue()
and
ecrt_master_64bit_reference_clock_time()
1- with respect to each other (does it matter which one is called first?)
2- with respect the distributed clock function calls? i.e.
ecrt_master_application_time()
ecrt_master_sync_reference_clock()
ecrt_master_sync_slave_clocks()
3- with respect to
ecrt_domain_queue()
and
ecrt_master_send()
Best,
Mohsen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20181025/c35ea339/attachment-0004.htm>
More information about the Etherlab-users
mailing list