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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.117.203 with SMTP id kg11mr17556730pab.25.1425153421417; Sat, 28 Feb 2015 11:57:01 -0800 (PST) X-Received: by 10.140.98.7 with SMTP id n7mr276239qge.13.1425153420159; Sat, 28 Feb 2015 11:57:00 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!hl2no1223785igb.0!news-out.google.com!c1ni203qar.1!nntp.google.com!i13no10366779qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 28 Feb 2015 11:57:00 -0800 (PST) In-Reply-To: <1p3tujcfe2x5b$.njfp7g1kpm79$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.236.12.239; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.236.12.239 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4d288aff-66c7-49d8-8ffd-8fc80e9355c5@googlegroups.com> Subject: Re: silly ravenscar question From: jan.de.kruyf@gmail.com Injection-Date: Sat, 28 Feb 2015 19:57:00 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:25066 Date: 2015-02-28T11:57:00-08:00 List-Id: On Friday, February 27, 2015 at 10:58:30 AM UTC+2, Dmitry A. Kazakov wrote: > 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, s= o > far. E.g. practically all field bus couplers are 100Kbaud. You will easil= y > beat them with TCP/IP + NO_DELAY by going 1GBaud. Yes, on bigger systems, but on cheap and not so nasty embedded stuff we mig= ht still have 100M ethernet for a while. So I do see the need still to limi= t my verbosity in the software (and in the frame size). Otherwise I will be= back at the bandwidth you quoted from the measurements you did. >=20 > 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. >=20 > 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. >=20 > As another example take a synchronous case with triggered AD conversions = in > multiple terminals. This does not work with EtherCAT either. It only look= s > synchronous, because you need to distribute the trigger signal to all > terminals. Since the signal's frame arrives at the terminals with differe= nt > latencies you must have time stamp (of some near future) in it. So, in > fact, this is also asynchronous. >=20 I seem to smell some contradiction in you reasoning but nevermind that. (I am a bit tired)=20 On my side of things I need perfectly synchronized slaves for fast motion c= ontrol. The hard real time is less important, so that is how I got to my la= st 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. So I did some more research on the ieee protocol, it looks as if it can han= dle it without a great investment in design time, etc. There are 2 good linux stacks around, together with a hardware-time-stampin= g network card it would work well to sync the whole caboudle to hard real t= ime. And in the case the master drops, one of the other boxes in the networ= k becomes master. There can be some voting process every now and again. > > 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. Nevertheles= s > star topology will win as it did when going from 10BNC to twisted pair. Probably double the wiring cost. That is a great killer with the junior pro= ject managers. (my son is one, so I hear these noises on and off)=20 I do not feel that a switch is a weak point. Only if you try to get away wi= th office quality RJ45 without bolting down the cables right next to the sw= itch, as you aught to do in any case, for grounding purposes. >=20 > If it consistently manipulates all time sources on the board, then OK. Fr= om > our experience, it is better to leave clocks alone (and have no problem > with negative adjustments) and only translate time stamps. Before I got deeply into this fieldbus thing I set up a small model on the = laptop to demonstrate some motordriver idea. I did have a jitter averaging = design in there that worked quite well. It was basically the same as what i= s in the ieee circuitry in the STM controller. It works as a PI controller = on the drift correction. Except my algorithm locked a lot faster than basic= PI. But that I did on the basis of a sync pulse every scan period like powerlin= k. Ettercat has not got that I believe. In any case that still only gives network time that then must be translate= d 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 ha= s been determined. > M =3D mega? Wow! Yes, but in my experience you might have to stop the processor clock for a = bit while you measure. Especially on cheap 2 layer boards. cheers, and thanks for your time. I highly appreciate your feedback. j.