Re: Ada for Automation

[slos <new.stephane.los@gmail.com>]

Le jeudi 6 novembre 2014 18:22:19 UTC+1, Dmitry A. Kazakov a écrit :
> On Thu, 6 Nov 2014 06:43:03 -0800 (PST), slos wrote:
> 
> > Le jeudi 6 novembre 2014 14:31:15 UTC+1, Dmitry A. Kazakov a écrit :
> >> On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote:
> >> 
> >> Regarding communication boards, they are not very useful.
> > Of course, since I am the support guy in France for the Hilscher company,
> > I cannot let you say such a thing without reaction.
> > 
> > Hilscher is on this market since 1986, let's say since the birth of field
> > buses, and has been very successful doing that.
> > 
> > Hilscher products are used by major players in the automation field and
> > their products are found everywhere from encoders to drives, PLCs to HMIs.
> 
> 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 for
> 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, technique comes at last since often any protocol is ok.
Hilscher offers a wide choice, embedded to PC, most protocols, master or slave, a single API, several drivers and the toolkit.
May be you Dmitry can design a protocol to rule them all but then you'll have to market it and, if it becomes successful, we will implement it.

> 
> Don't you find it strange that you'd need a special hardware to communicate
> 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 special hardware only when you need other protocols to communicate with devices you have selected.

And what about standardized profiles that allow a customer to pick among different manufacturers the one who provide the right functionality at the right 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.

> 
> >> 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, almost
> >> (:-)).
> >> 
> > Yes, that's true. Industrial protocols tend to be more and more complex
> > because the world is getting more and more complex.
> 
> 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, 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 clock is
> broken. There is no diagnostics whatsoever and so on.
> 
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 POWERLINK.
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, Modbus.

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 not 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.
> 
> 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 working
> 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 communication units of our own. And since no one is willing to develop for free on those boards all those poorly designed protocols, drivers, and configuration tools, we have work for a while.
 
> 
> 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 the clamps need to bite the cable.

> 
> >> Yes, it is a huge amount of work and you will need community support.
> > Or an Hilscher board.
> 
> ... 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, everyone 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 offer an Ada possibility. The choice is theirs again.

> 
> > There was once an open source stack but it is not available because one
> > need buying a licence from ETG.
> 
> 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.
> 
> The purpose of such stacks is to use them as a starting point for a
> customized single-purpose system.
> 
> 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 of customers. If it was that easy, we would do something else.

> 
> >> 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 embedded
> > market using modules with same API.
> 
> Same here. Less people, though.
> 
> >>> Thanks to GtkAda it can be built with a GUI.
> >>> It can be built without of course.
> >> 
> >> 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 they
> > are interfaced using protected types.
> 
> 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 partition managing the GUI while another managing the process for example but for the moment I want to keep it quite simple.

> 
> >> That
> >> is not a good idea, generally. It is better to keep them separate. Which is
> >> a serious architectural problem how to communicate between the middleware
> >> 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.
> >>  
> >>> 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.
> >>> 
> >>> 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.
> >> 
> >> 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.
> 
> Ours (its embeddable variant) is all in Ada. (:-))
Who is developing the application ? Automation engineers or your team ?

> 
> > 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 not
> > easy to master for automation engineers. And we know what happens when
> > one does not master the tool he uses.
> > 
> > Ada seems to fit perfectly here to me.
> 
> 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.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Best Regards,
Stéphane
http://slo-ist.fr/