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.42.192.131 with SMTP id dq3mr14611888icb.3.1415353880108; Fri, 07 Nov 2014 01:51:20 -0800 (PST) X-Received: by 10.140.37.83 with SMTP id q77mr15503qgq.7.1415353880076; Fri, 07 Nov 2014 01:51:20 -0800 (PST) Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!h15no7404309igd.0!news-out.google.com!u5ni27qab.1!nntp.google.com!i13no1897636qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 7 Nov 2014 01:51:19 -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: <6141de44-8919-493c-b6b7-10545a7cc2c3@googlegroups.com> Subject: Re: Ada for Automation From: slos Injection-Date: Fri, 07 Nov 2014 09:51:20 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:190361 Date: 2014-11-07T01:51:19-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? Because for some specialized features like synchronisation with jitter in t= he nanosecond range require ad hoc hardware ? Because an ad hoc OS gives better performance than a general one ? >=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. Yes, it's all about choice. Hilscher and others offer that choice. >=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. It may be useless or not. I am not the customer and I don't know why he nee= ds so much data but if he needs it he gets it. I have some examples where it makes sense like this one : Our customer is building robots arms and need to know if they are moving as= expected. So he is moving the arm and records position and couple at 1 ms rate. Then, analysing the data he can detect whether there is a mechanical proble= m that has to be adjusted. Anyway, in motion control, such features are mandatory these days, not for = recording them but for very accurate motion of many axes. >=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. On a field bus you will find some other devices like encoders or drives for= example where Modbus will not suffice. Having also terminals with digital = / analog I/Os just make sense because you don't want to have several networ= ks. And of course, when you need high rate data acquisition like for test bench= es it's just mandatory. >=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. Again terminals are not the only things you will find on a network. No technology is perfect and developers are humans and there are bugs like = every where else. And yes, integration is creating working applications with components which= have some bugs and you have to get them updated / corrected or find some w= orkaround. And that's where open source shines. >=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. >=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. Woah ! are you sure ? I cannot tell. But I can see it working everyday. >=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. Well, since protocols are standardized, what would prevent to create some h= ardware abstraction layer over boards drivers bindings ? Let's say there is a CANopen interface that allows the application to send = an SDO read / write request. Then depending on some configuration step, thi= s layer would call the corresponding function in the selected board interfa= ce. Seems rather simple in fact. >=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. Well, let's see if "Ada for Automation" can do the work for not so simple a= pplications and how it is perceived. >=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. People use what they know or are directed to use. "Ada for Automation" wants them to learn Ada and use it for their applicati= ons. We could continue this discussion about field buses but I am here to let th= e Ada community know about this project and get some feedback on my beginne= r's job. I am quite sure your Ada skills are far more developed than mines and that = I could learn a lot from you and others on this list. >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Best Regards, St=E9phane http://slo-ist.fr/