From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: silly ravenscar question Date: Sun, 1 Mar 2015 10:27:45 +0100 Organization: cbb software GmbH Message-ID: References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> <647ebb7f-61fd-4e36-b047-3207ea789807@googlegroups.com> <1p3tujcfe2x5b$.njfp7g1kpm79$.dlg@40tude.net> <4d288aff-66c7-49d8-8ffd-8fc80e9355c5@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: w2sqUGEBZqsVBYNL7Ky3Kg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.giganews.com comp.lang.ada:192375 Date: 2015-03-01T10:27:45+01:00 List-Id: On Sat, 28 Feb 2015 11:57:00 -0800 (PST), jan.de.kruyf@gmail.com wrote: > On Friday, February 27, 2015 at 10:58:30 AM UTC+2, Dmitry A. Kazakov wrote: > >> Right, but the problem is that in most cases the terminals run some >> asynchronous tasks which must be time stamped. For this they would use >> internal counters and you have the problem of translation these counters >> into the master clock and then into the PC clock. This is what does not >> work in EtherCAT. >> >> Consider as an example an analogue input. You should be able to latch the >> clock at the end of a conversion and convert it into the PC clock. This >> would be "free run" mode. >> >> As another example take a synchronous case with triggered AD conversions in >> multiple terminals. This does not work with EtherCAT either. It only looks >> synchronous, because you need to distribute the trigger signal to all >> terminals. Since the signal's frame arrives at the terminals with different >> latencies you must have time stamp (of some near future) in it. So, in >> fact, this is also asynchronous. > > I seem to smell some contradiction in you reasoning but nevermind that. > (I am a bit tired) > On my side of things I need perfectly synchronized slaves for fast motion > control. The hard real time is less important, so that is how I got to my > last opinion. > then if I am ever in a position that I have to split the work over 2 pc's > (and that might be closer as what I wish) I might just be very pleased > when both the slave groups have the same sense of time. > On your side you need to be able to stamp your measurements with hard real > time I understand. Or at least deduct the hard real time in some way. But the point is you cannot have it well synchronized over Ethernet without time stamping. Synchronized slaves is the second scenario I described, which apply even more for 100BASE. In the core it is triggering synchronous actions by a *local* timer derived from incoming protocol packets/frames rather than directly from the frames. And from the software perspective, the idea that you could enforce real-time/synchronicity per real-time protocol is flawed. More complex the software running on top of the protocol less chances you have to keep synchronicity up to the application level because you need time to propagate the signal though levels of hardware and software. > But that I did on the basis of a sync pulse every scan period like > powerlink. Ettercat has not got that I believe. > In any case that still only gives network time that then must be > translated for data gathering. > > So with ieee you slowly walk past all stations once every 2 seconds or > even slower and measure the cable delay. and add or subtract 1 bit to/from > the drift register as needed. that is, as soon as the course time > correction has been determined. When it is only cable delay without in-terminal(s) delay, it is useless. And you still need to adjust terminal time sources or translate their readings to and from master clock. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de