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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: silly ravenscar question Date: Fri, 27 Feb 2015 09:58:53 +0100 Organization: cbb software GmbH Message-ID: <1p3tujcfe2x5b$.njfp7g1kpm79$.dlg@40tude.net> References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> <647ebb7f-61fd-4e36-b047-3207ea789807@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: OpkKbm9QwHUq0Y4SxjI2mw.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: news.eternal-september.org comp.lang.ada:25051 Date: 2015-02-27T09:58:53+01:00 List-Id: On Thu, 26 Feb 2015 11:09:02 -0800 (PST), jan.de.kruyf@gmail.com wrote: > On Thursday, February 26, 2015 at 11:47:31 AM UTC+2, Dmitry A. Kazakov wrote: > >> We are using a proprietary TCP/IP based protocol (LabNet) for distribution >> between the nodes. > > is not -fast- > bare E-frames is better, i would think. Just repeat the poll/response > cycle when no good data arrives. And 3 tries is death. (or whatever) But TCP/IP is more flexible. Furthermore, 1Gbaud Ethernet is fast enough to outperform anything we could do at the nodes. It is not the bottleneck, so far. E.g. practically all field bus couplers are 100Kbaud. You will easily beat them with TCP/IP + NO_DELAY by going 1GBaud. >> It is a design question about the field bus network topology, in particular >> switch vs. chained nodes (like in EtherCAT). Real-time crowd will try to >> convince us that the only way is chained nodes, but I honestly believe that >> normal networks will eventually win. > > How do you do IEEE1588 ? this way around the loop or that way? We don't. Time synchronization is integrated into the middleware protocol we are using. > The whole scheme becomes dependent on the jitter tolerance of the pc > because the pc is part of the delay loop. We collect statistics of round trip times. It is filtered for artifacts and does weighted average of good samples with a floating window (for the cases when the network performance fluctuates). So jitter is eliminated. > while if one of the outstations takes the syncer role then the pc can be > as floppy as it likes, we dont care. But you still have to translate the clock of that terminal into the PC clock. The schema of dedicated clock master does not work. > It will only show up in the inter-poll gaps. > But the terminals all run in perfect step and have one sense of time. 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. > Further when 1 station is down its is a major upheaval, if you look > carefully at an etherCAT mac / phy you will know why. And that structure > is not readily emulated. Yes, they have a mode when the cable goes back to the master. But there is no way to use distributed clock in that mode, so we don't use it anyway. > While in a star one can unplug a box, which then will be declared dead by > the software, until the time that a new box announces itself. Yes, though to keep it balanced, one still could argue that the switch is the new weak point then, and that wiring is more complicated. Nevertheless star topology will win as it did when going from 10BNC to twisted pair. >> OK. However, it is not much an issue to reduce latencies in time >> synchronization as to actually to use it to compensate clock drift (not >> necessarily by tuning the clocks) in order to allow the subscriber to get >> data stamped by the *subscriber's* clock. The problem with actual protocols >> is that they do it by the *publishe's* clock. > > Your wishes have been fulfilled, there is drift correction incorporated in > the hardware, that is controlled via software from IEEE1588. If it consistently manipulates all time sources on the board, then OK. From our experience, it is better to leave clocks alone (and have no problem with negative adjustments) and only translate time stamps. >> The best ADC we ever had had 0.040ms conversion time. > > Those were wonderful ADC's then. but now how about this: > ADC conversion rate with 12 bit resolution is up to: > 2.4 M.sample/s in single ADC mode, > 4.5 M.sample/s in dual interleaved ADC mode, > 7.2 M.sample/s in triple interleaved ADC mode. M = mega? Wow! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de