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.182.96.161 with SMTP id dt1mr9048905obb.24.1415360678869; Fri, 07 Nov 2014 03:44:38 -0800 (PST) X-Received: by 10.140.36.231 with SMTP id p94mr10758qgp.13.1415360678840; Fri, 07 Nov 2014 03:44:38 -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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!r10no5061387igi.0!news-out.google.com!u5ni26qab.1!nntp.google.com!u7no3076816qaz.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 7 Nov 2014 03:44:38 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=193.251.73.50; posting-account=O3LyFwoAAACc1uh60ZcOUmAGdDmGsEcV NNTP-Posting-Host: 193.251.73.50 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <78b6c566-66a4-4275-ace0-be2f3553bc12@googlegroups.com> Subject: Re: Ada for Automation From: slos Injection-Date: Fri, 07 Nov 2014 11:44:38 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 8923 X-Received-Body-CRC: 1419417400 Xref: news.eternal-september.org comp.lang.ada:23056 Date: 2014-11-07T03:44:38-08:00 List-Id: Le vendredi 7 novembre 2014 09:29:38 UTC+1, Dmitry A. Kazakov a =E9crit=A0: > On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote: >=20 > > Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a =E9crit=A0= : > >> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote: > >>=20 > >> Don't you find it strange that you'd need a special hardware to commun= icate > >> devices designed to be Ethernet-compatible? Why don't you need a board= to > >> communicate ModBus? Telnet? HTTP? > > Determinism ? High data throughput ? Synchronization ? What else ? >=20 > I don't see why any of this requires a board, which is nothing but anothe= r > computer. If it can do this, why the target system cannot? >=20 > >>> Yes, that's true. Industrial protocols tend to be more and more compl= ex > >>> because the world is getting more and more complex. > >>=20 > >> Not really. All of them except very few are quite poorly designed. The= re is > >> nothing in the world that can justify the enormous complexity of Ether= CAT. > >> It is simply wrong design all way up from the lowest transport level, = which > >> itself is nice and elegant. It looks like EtherCAT was designed by > >> different people. The rest of EtherCAT layers is garbage with anything= done > >> wrong, what could be done wrong. It complicates everything, slaves, > >> masters. It does not support auto-configuration as proclaimed. It has = a > >> huge and absolutely unnecessary initialization delay. Distributed cloc= k is > >> broken. There is no diagnostics whatsoever and so on. > >>=20 > > That's strange. It seems to me that you are putting down the technology > > you have implemented in your solution. >=20 > Why? Our solution is all about hardware integration. Its philosophy is th= at > we don't dictate customer hardware choices. He decides what hardware to > buy. We integrate that hardware into the automation system. >=20 > There is a lot of EtherCAT hardware around. This does not make EtherCAT > design good. Furthermore, EtherCAT is only inexpensive solution that > manages cycles under 1ms. Customers love short cycles and gigabytes of > useless data blowing up hard drives, therefore we support it. >=20 > Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendo= r, > ModBus is clear favorite. Building a system that uses ModBus terminals is > in order magnitude simpler and far more maintainable than a system based = on > EtherCAT. The advantage of EtherCAT is much shorter cycles (50us vs. 5ms) > and slightly lower price. All else is disadvantages. >=20 > > So, over EtherCAT, the application layer is mainly CANopen like for POW= ERLINK. >=20 > Yes. >=20 > > CANopen allows to select in the object dictionary of each devices the d= ata > > 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 master > does is gathering information scattered across different sources on the > terminal (EEPROM, object dictionary, address space), fixing > inconsistencies, filling missing parts. >=20 > > This you cannot do with, let's say, Modbus. >=20 > Of course you can. There is no problem to query only data you needed over > ModBus. We do this all the time. No, that's not the same thing. With today field buses you are able to select what will be exchanged cyclic= ally in a PDO (CANopen / EtherCAT / POWERLINK) or Assembly (Ethernet/IP). T= he device will prepare its answer accordingly. With Modbus, you can access of course the whole data set but you end up rea= ding more data and filter out the one you don't need or make several reques= ts to pick up only the data needed. Of course, performance wise, the former is better. >=20 > All this CANOpen stuff borrowed by EtherCAT is nonsense, because like > ModBus the EtherCAT's transport is pure *client-server*, while CANOpen is > running on CAN which is *bus*. So the upper EtherCAT layers simply do not > fit to the transport and are useless at best. >=20 > >> ... or National Instruments, or Siemens, or Vector AG, or ETAS etc. I = don't > >> believe you could gather much interest in that. Hobbyists won't go int= o a > >> vendor lock. Professionals will stick to paid services and complete > >> solutions. > > Well, if someone is willing to spend some time in binding their API, > > everyone could then use those boards as well. >=20 > Which would be more work than supporting stacks natively, and far more wo= rk > in the future spent on maintenance. Protocols are more or less standardis= ed > and stable. Vendor API's are a volatile havoc. Furthermore the high > abstraction level will prevent seamless board integration anyway. It is > classic abstraction inversion, you add a full-blown system in order to > sample few low-level data channels. >=20 > >> Monolithic design. It is all OK for an embedded system, but barely > >> acceptable for a medium-scale automation subsystem running on a PC wit= h > >> components being independent processes. Protected objects cannot cross > >> process borders. You don't want to have it in single process for many > >> reasons. > > It works fine this way. I don't want to put in too much complexity, no > > more than needed. May be your applications need that. > > I have learned about PolyORB and DSA and thought that I could have one > > partition managing the GUI while another managing the process for examp= le > > but for the moment I want to keep it quite simple. >=20 > It will be difficult to add distribution services later. They must be a > part of the middleware, too much coupling needed. >=20 > >>>> That > >>>> is not a good idea, generally. It is better to keep them separate. W= hich is > >>>> a serious architectural problem how to communicate between the middl= eware > >>>> dealing with the hardware, providing publisher-subscriber services a= nd > >>>> various clients. GUI is only one of them. Inter-process communicatio= n, DLLs > >>>> are all system-dependent. No solution is scalable and portable, meet= s > >>>> real-time requirements. It is a very difficult problem to resolve. > >>>> =20 > >>>>> It works rather nicely but it would be fantastic if some experience= d > >>>>> person would review the code and give me some feedback on the desig= n, the > >>>>> bindings, the code quality... I'm a lonely Ada programmer, and I mi= ss > >>>>> feedback. > >>>>>=20 > >>>>> Of course, I am interested in any collaboration around this matter. > >>>>> So, do not hesitate to get in touch when you have some real case. > >>>>=20 > >>>> We do the same stuff, but it is a commercial product. So I cannot do= that > >>>> on ethical and contractual grounds, sorry. > >>> There are plenty of commercial solutions already available like WinAC= , > >>> CoDeSys, PROCONOS, ISaGRAF... to create automation solutions, none in= Ada. > >>=20 > >> Ours (its embeddable variant) is all in Ada. (:-)) > > Who is developing the application ? Automation engineers or your team ? >=20 > Usually engineers and usually not in Ada. Since the middleware is nativel= y > distributed, applications can be written in other languages, the ones > people prefer, something as horrific as C# or MATLAB. >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de