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.63.199 with SMTP id a47mr5874954yhd.6.1415311091741; Thu, 06 Nov 2014 13:58:11 -0800 (PST) X-Received: by 10.140.94.212 with SMTP id g78mr119094qge.0.1415311091721; Thu, 06 Nov 2014 13:58:11 -0800 (PST) Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!u7no2973435qaz.1!news-out.google.com!u5ni26qab.1!nntp.google.com!u7no2973434qaz.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 6 Nov 2014 13:58:11 -0800 (PST) In-Reply-To: <1bbqo878nvb2p$.1n3uysmo360g3.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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada for Automation From: slos Injection-Date: Thu, 06 Nov 2014 21:58:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:190352 Date: 2014-11-06T13:58:11-08:00 List-Id: 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 > > Le jeudi 6 novembre 2014 14:31:15 UTC+1, Dmitry A. Kazakov a =E9crit=A0= : > >> On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote: > >>=20 > >> Regarding communication boards, they are not very useful. > > Of course, since I am the support guy in France for the Hilscher compan= y, > > I cannot let you say such a thing without reaction. > >=20 > > Hilscher is on this market since 1986, let's say since the birth of fie= ld > > buses, and has been very successful doing that. > >=20 > > Hilscher products are used by major players in the automation field and > > their products are found everywhere from encoders to drives, PLCs to HM= Is. >=20 > I know Hilscher. It is not specific to their product. In my view such > boards is a wrong solution, designed mainly for vendor lock reasons not f= or > technical reasons. I can't agree here either. Each protocol has pros and cons. Choice is in customer's hands and is about strategy, economics, market, tec= hnique comes at last since often any protocol is ok. Hilscher offers a wide choice, embedded to PC, most protocols, master or sl= ave, a single API, several drivers and the toolkit. May be you Dmitry can design a protocol to rule them all but then you'll ha= ve to market it and, if it becomes successful, we will implement it. >=20 > Don't you find it strange that you'd need a special hardware to communica= te > 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 ? "Ada for Automation" is Modbus capable thanks to libmodbus. So you need spe= cial hardware only when you need other protocols to communicate with device= s you have selected. And what about standardized profiles that allow a customer to pick among di= fferent manufacturers the one who provide the right functionality at the ri= ght price ? Of course you have to stick to the profile to benefit from that= . There are no such profiles in the Modbus world. Anyone is free to lay down = it's own data in the way he likes. >=20 > >> The protocol requires a very complicated initialization to talk even > >> with relatively simple slaves. You might be able to connect a simple > >> analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is > >> vendor's tool does not support everything. Our EtherCAT master does, a= lmost > >> (:-)). > >>=20 > > Yes, that's true. Industrial protocols tend to be more and more complex > > because the world is getting more and more complex. >=20 > Not really. All of them except very few are quite poorly designed. There = is > nothing in the world that can justify the enormous complexity of EtherCAT= . > It is simply wrong design all way up from the lowest transport level, whi= ch > itself is nice and elegant. It looks like EtherCAT was designed by > different people. The rest of EtherCAT layers is garbage with anything do= ne > 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 clock i= s > 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. No technology is perfect but EtherCAT is working quite fine for a number of= manufacturers who have chosen it. As already said, they might have chosen = it for other reasons than purely technical ones but who knows. So, over EtherCAT, the application layer is mainly CANopen like for POWERLI= NK. CANopen allows to select in the object dictionary of each devices the data = that has to be cyclically exchanged. This you cannot do with, let's say, Mo= dbus. I won't argue on the merits of each protocol, one can find "facts" from any= technology vendor. And who am I to tell if such design is broken ? I am no= t an expert but a support and development guy wanting to learn Ada. > >> So, my advice would be to implement these stacks natively. > > That is surprising after reading what you have said just above. >=20 > There is no other way putting it into a small board, e.g. an ARM-based > board. And, IMO, you will not attract much community support if special, > expensive, proprietary hardware will be required. People expect it workin= g > on a $100 board with no extra costs. Excellent, this is what Hilscher communication solutions are : small boards= with a home designed system on chip netX with ARM CPU and special communic= ation units of our own. And since no one is willing to develop for free on = those boards all those poorly designed protocols, drivers, and configuratio= n tools, we have work for a while. =20 >=20 > We can safely project that next generations of sensors and actuators will > be much smaller than Beckhoff terminals and fully Ethernet-capable which > will bring death to GPIO. In this context pure Ada solutions have bright > future, IMO. Those terminals are that big because someone has to tighten the screws or t= he clamps need to bite the cable. >=20 > >> Yes, it is a huge amount of work and you will need community support. > > Or an Hilscher board. >=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 into 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, everyo= ne could then use those boards as well. Hobbyists can still use Modbus TCP or RTU, that's available for nothing. Professionals are using IEC 61131-3 PLCs or C/C++. I am just trying to offe= r an Ada possibility. The choice is theirs again. >=20 > > There was once an open source stack but it is not available because one > > need buying a licence from ETG. >=20 > These stacks are unusable as they implement less than 5% of what is > actually needed to handle complex EtherCAT slaves like oversampling > analogue inputs or incremental encoders. >=20 > The purpose of such stacks is to use them as a starting point for a > customized single-purpose system. >=20 > That is not the case for a "universal" automation system. You need to go > all way up to the application level leaving it configurable for each > combination of slaves, for each operation mode etc. You must support > interaction between hardware of different origin, e.g. signaling EtherCAT > frames by CAN telegrams etc. It is a different world. You know I know, and that's why Hilscher products are useful for a number o= f customers. If it was that easy, we would do something else. >=20 > >> This is not one-man job. > > More than two hundred people are working at Hilscher, creating the > > communication solutions that "Ada for Automation" users would need. > > Right now, you can start on a PC with any format and down to the embedd= ed > > market using modules with same API. >=20 > Same here. Less people, though. >=20 > >>> Thanks to GtkAda it can be built with a GUI. > >>> It can be built without of course. > >>=20 > >> Do you mix data acquisition and distribution middleware with the GUI? > > No, this is not mixed. > > Tasks are employed dealing with acquisition, processing, and GUI but th= ey > > are interfaced using protected types. >=20 > Monolithic design. It is all OK for an embedded system, but barely > acceptable for a medium-scale automation subsystem running on a PC with > 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 part= ition managing the GUI while another managing the process for example but f= or the moment I want to keep it quite simple. >=20 > >> That > >> is not a good idea, generally. It is better to keep them separate. Whi= ch is > >> a serious architectural problem how to communicate between the middlew= are > >> dealing with the hardware, providing publisher-subscriber services and > >> various clients. GUI is only one of them. Inter-process communication,= DLLs > >> are all system-dependent. No solution is scalable and portable, meets > >> real-time requirements. It is a very difficult problem to resolve. > >> =20 > >>> It works rather nicely but it would be fantastic if some experienced > >>> person would review the code and give me some feedback on the design,= the > >>> bindings, the code quality... I'm a lonely Ada programmer, and I miss > >>> 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 t= hat > >> 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 A= da. >=20 > Ours (its embeddable variant) is all in Ada. (:-)) Who is developing the application ? Automation engineers or your team ? >=20 > > I think there is some room left between automation and industrial > > computing where the languages used in automation (IEC 61131-3) make it > > hard to create evolved applications and where the C/C++ languages are n= ot > > easy to master for automation engineers. And we know what happens when > > one does not master the tool he uses. > >=20 > > Ada seems to fit perfectly here to me. >=20 > Yes, but not perfect. Issues of distribution and modularity are addressed > in a way that is not very suitable for automation systems. Not that there > exists any language that does it better, but still. >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Best Regards, St=E9phane http://slo-ist.fr/