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.43.80.66 with SMTP id zt2mr16130941icb.8.1415392676008; Fri, 07 Nov 2014 12:37:56 -0800 (PST) X-Received: by 10.140.41.147 with SMTP id z19mr217282qgz.1.1415392675871; Fri, 07 Nov 2014 12:37:55 -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!h15no7722583igd.0!news-out.google.com!u5ni26qab.1!nntp.google.com!u7no3177917qaz.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 7 Nov 2014 12:37:55 -0800 (PST) In-Reply-To: <17acezb4wwf86$.k08v3ppyvdol.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=84.100.130.181; posting-account=O3LyFwoAAACc1uh60ZcOUmAGdDmGsEcV NNTP-Posting-Host: 84.100.130.181 References: <3e877e3f-c9ad-48a5-941d-08a7f5c3f317@googlegroups.com> <3wgqzq98u7gx$.17hpf52b2gd7l.dlg@40tude.net> <38980827-610e-42fc-a8bf-59a99bbdeee7@googlegroups.com> <1bbqo878nvb2p$.1n3uysmo360g3.dlg@40tude.net> <6141de44-8919-493c-b6b7-10545a7cc2c3@googlegroups.com> <1tj1e7v4n10mw$.4aybiuivl4f4$.dlg@40tude.net> <17acezb4wwf86$.k08v3ppyvdol.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada for Automation From: slos Injection-Date: Fri, 07 Nov 2014 20:37:55 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:23071 Date: 2014-11-07T12:37:55-08:00 List-Id: Le vendredi 7 novembre 2014 18:16:34 UTC+1, Dmitry A. Kazakov a =C3=A9crit= =C2=A0: > On Fri, 7 Nov 2014 07:23:20 -0800 (PST), slos wrote: >=20 > > Le vendredi 7 novembre 2014 14:44:13 UTC+1, Dmitry A. Kazakov a =C3=A9c= rit=C2=A0: >=20 > >> You cannot do that on an ARM board anyway. And if you could, what for?= If > >> the data are to be processed on the PC via network which has jitter no= where > >> close to ns? > > Of course we can ! Not an ARM board but a netX powered one with what's > > needed to achieve that. >=20 > Just what I said. This is a one or two generation outdated architecture, > before standardized terminals came. Pack the stuff into plastic box add > Beckhoff's piggy back chip, here you are, a new EtherCAT slave. No boards > ever needed. >=20 > >> If these data are not automation process data, then what are we talkin= g > >> about? > >>=20 > >> Such high speed data are processed in the terminals which provide inte= gral > >> measures which in turn don't require meaningless ns jitter. As an exam= ple > >> take frequency measurements. They require ns clocking and pulse counti= ng, > >> which is done by the hardware, not by the board. Here the computed res= ult > >> is frequency, a pretty normal data with pretty no extraordinary jitter > >> requirements. > > I agree totally for this kind of data and you could say the same for le= t's > > say a drive with an encoder connected to ; the loop is closed in the dr= ive > > and that would be the easiest architecture. But some customers want to > > have the loop closed in the controller so that they can write the contr= ol > > algorithm they need. >=20 > Yes, that is an outdated architecture with a closed-source PLC programmed > in some garbage language like STEP 7. This is what we want to get rid of, > replace it with open source portable controllers programmed in Ada. For > this native stacks are needed. And because Ada is so scalable and portabl= e > I see no reason why automation and controller software cannot share the > same middleware core! >=20 > >>> Because an ad hoc OS gives better performance than a general one ? > >>=20 > >> I doubt it much. The board must support some network protocol where al= l > >> performance ends. Either it will run in several threads which would ma= ke it > >> not better than general OS, or it will use some multiple buffering > >> techniques with have *worse* performance being time-triggered. > > > > Don't doubt. Experiment with it. >=20 > Actually we do much performance measurements for various stacks. =20 >=20 > >>> I have some examples where it makes sense like this one : > >>> Our customer is building robots arms and need to know if they are mov= ing > >>> as expected. > >>>=20 > >>> So he is moving the arm and records position and couple at 1 ms rate. > >>=20 > >> Our customers require multiple channel 100=C4=BEs. > > That's not what is needed even by motion control applications. >=20 > It is required in combustion motor R&D and drilling engines. At least the > customers say so. I am not a physicist to argue with them. >=20 > > Curves show if there is some outstanding values. >=20 > How are you supposed to watch hundreds of curves sampled at 10ms rate for > many months, in some cases? It does not work, but nobody admits that. >=20 > > No problem for him, he can analyse the data he captures. > >=20 > >> Alas, it is impossible to convince customers to invest into on-line > >> diagnostics. Because that would cost time and money.=20 > >>=20 > >> With the data simply stored away, they believe they would be able to > >> analyse them later, for nothing, using Excel to read 4Gb files... (:-)= ) > > One can filter out normal data to get only interesting one. >=20 > Better do that before storing them... >=20 > >>>> Given a choice between Beckhoff EtherCAT and ModBus terminals, same = vendor, > >>>> ModBus is clear favorite. Building a system that uses ModBus termina= ls is > >>>> in order magnitude simpler and far more maintainable than a system b= ased on > >>>> EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs.= 5ms) > >>>> and slightly lower price. All else is disadvantages. > >>> On a field bus you will find some other devices like encoders or driv= es > >>> for example where Modbus will not suffice. > >>=20 > >> I doubt it. E.g. WAGO ModBus incremental encoders are no worse or bett= er > >> than EtherCAT ones. Actually ModBus encoders are simpler to use becaus= e the > >> vendor does not try to pack all possible modes into single terminal > >> requiring the automation system to configure dozens of parameters nobo= dy > >> needs. Less flexibility safer and simpler usage. > > In drives applications, you have much more data to choose from, dependi= ng > > on the working mode. >=20 > And where is any problem? We are communicating to multiple SPS controllin= g > a whole drilling platform machine, a lot of data in each, all goes over > ModBus. ModBus performance is only limited by the other side. E.g. WAGO > ModBus is limited to 5ms because the internal bus cycle is 3ms and becaus= e > the coupler is 100Base. >=20 > >>>>> CANopen allows to select in the object dictionary of each devices t= he data > >>>>> that has to be cyclically exchanged. > >>>>=20 > >>>> Most of EtherCAT terminals cannot this (e.g. selection of PDOs, free > >>>> configuration of sync buffers). Many of them don't even have object > >>>> dictionary, others have it incomplete or broken. Much of work our ma= ster > >>>> does is gathering information scattered across different sources on = the > >>>> terminal (EEPROM, object dictionary, address space), fixing > >>>> inconsistencies, filling missing parts. > >>> Again terminals are not the only things you will find on a network. > >>=20 > >> You don't seriously suggest PCs to communicate over EtherCAT? > > They can since Ethernet over EtherCAT allows this but I am mostly talki= ng > > about motion control and drives since those technologies have been > > specifically developed for that particular need >=20 > All EtherCAT interfaced drivers we dealt with were quite normal EtherCAT > terminals, nothing special. >=20 > >> There is > >> nothing but terminals which is needed. For anything else there is data > >> distribution protocols which has nothing to do with EtherCAT or any ot= her > >> field protocol. And in our designs we always physically separate filed= and > >> automation networks. > > Since Ethernet based real time protocols were designed to provide both > > kind of communications a single path, you have missed the point. > > Of course, if your customer can afford two networks... >=20 > Anybody can, dual Ethernet ports cost nothing. >=20 > All our customers want it separate for safety and bureaucratic reasons. > They often have different cabling requirements (the field network is > usually in the machine hall, dusty, dirty, a lot of EM, LEMO jacks needed > etc). HMI network is clean, but alas, hijacked by internal IT guys (we > never let them into the field with their Windows-updates mess and > firewalls). >=20 > >>> Seems rather simple in fact. > >>=20 > >> Right. And if the board can talk this protocol, why terminal cannot? S= ee? > >> You don't need dedicated boards in the end. > > Please design a drive, an encoder, an IO module, what ever you want, an= d > > then try to address the market. > > Then you have to implement each protocol on your design. Good luck. >=20 > This is exactly what Beckhoff does in the case of EtherCAT slaves: >=20 > http://www.beckhoff.de/english/ethercat/fb1111_fb1122_fb1130.htm >=20 > or others do for ProfiNet, e.g. >=20 > http://am.renesas.com/products/soc/assp/fa_lsi/ethernet/tps1/index.jsp >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de And what about Ada and the project itself ? BR, St=C3=A9phane