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.236.26.17 with SMTP id b17mr9259198yha.15.1424977742712; Thu, 26 Feb 2015 11:09:02 -0800 (PST) X-Received: by 10.140.84.213 with SMTP id l79mr152184qgd.41.1424977742645; Thu, 26 Feb 2015 11:09:02 -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!border1.nntp.dca1.giganews.com!nntp.giganews.com!j7no7780195qaq.1!news-out.google.com!n6ni189qar.0!nntp.google.com!i13no8455004qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 26 Feb 2015 11:09:02 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.236.99.178; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.236.99.178 References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> <647ebb7f-61fd-4e36-b047-3207ea789807@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: silly ravenscar question From: jan.de.kruyf@gmail.com Injection-Date: Thu, 26 Feb 2015 19:09:02 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:25046 Date: 2015-02-26T11:09:02-08:00 List-Id: On Thursday, February 26, 2015 at 11:47:31 AM UTC+2, Dmitry A. Kazakov wrot= e: >=20 > [ Switches we measured imposed latencies somewhere between 6 and 15 > microseconds. ] >=20 found some HP boxes with a guaranteed latency, and it has a spy connector all at reasonable price. >=20 > I never worked with it, but from the short description I read, looks like > they try to mimic CANOpen-nonsense and have master/slave architecture. No= t > good. dont. it makes your eyes go squint when you try to read the code. >=20 > We are using a proprietary TCP/IP based protocol (LabNet) for distributio= n > 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) >=20 > It is a design question about the field bus network topology, in particul= ar > 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 th= at > normal networks will eventually win. How do you do IEEE1588 ? this way around the loop or that way? The whole scheme becomes dependent on the jitter tolerance of the pc becaus= e the pc is part of the delay loop. Nah! while if one of the outstations takes the syncer role then the pc can be as= floppy as it likes, we dont care. It will only show up in the inter-poll g= aps. But the terminals all run in perfect step and have one sense of time. So yes, I am agnostic as far as the software writing goes. The changes are = not very big, And yes more traffic is possible, because there is less cruft= . But it involves non standard hardware with 2 phys or a 3way phy. (STM will deal graciously with either that is not the point.) And the timin= g will be less acurate.=20 Further when 1 station is down its is a major upheaval, if you look careful= ly at an etherCAT mac / phy you will know why. And that structure is not re= adily emulated. While in a star one can unplug a box, which then will be declared dead by t= he software, until the time that a new box announces itself. The pc does get offloaded a bit. less cruft in the frames to throw away, Bu= t there are many ways to kill a mocking bird. I just realized to my horror that using a STM terminal connected through --= -- just wait for it --- a parallel card handles the data load easily and ac= ts like a beautiful buffer. and the system will for sure have less jitter, = so can handle more outstations. Crazy hey. (Dont try to sell this to the RT= guys) But then again a micro controller connected via a pci interface on a= plugin card at E400.- will please everybody mightily, and it might do the = same job. > 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 protoco= ls > 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. > > 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. 24 channels split over 3 ADC's (that is where the 'triple interleaved' come= s in) Nice hey, we might do a bit of oversampling now to get the accuracy right. >=20 > Yes. But you know, once you give customers 8 10kHz channels they start > looking forward 16 channels... (:-)) its there, just don't sell it all at once. my uncle would say: "Remember th= e Philips shaver. They full well knew they were eventually going to make a = 3 headed one." (back in 1950 or so, when they still made them with 1 head) >=20 > Maybe, but we must keep a big picture. It does not make sense to sacrific= e > for making latencies 50% shorter. Latencies are not the issue most of the > time, though customers will always tell you otherwise. They lie. The real > problem is having it=20 > configurable, scalable, usable. Tell me more . . . (And remember old Miesel, Dijkstra. I dont know if you have read any of his= notes, all written in beautiful long-hand, and all about computer science. But customer relations was not one of his fortes.) >=20 > Not really. The architecture is usually such that the controlling unit is > physically separate from the logger, or the HMI. E.g. consider an EtherCA= T > installation. There is a controller (an industrial PC) running Linux or > VxWorks with an EtherCAT master. It does all real-time work. It also > samples the high-speed channels and publishes them over the middleware. T= he > data logger is another PC which subscribes to it. >=20 Ok, so we dont need a parallel port, he, I was sweating already. . . . cheers, j.