Re: Ada for Automation

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

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:
> 
> First of all, congratulate and thank for the efforts.
Thanks Dmitry. You have been inspirational.

> 
> Don't mind a little bit critique which follows.
I am fine with critique, I can stand it and even appreciate it.

> 
> > "Ada for Automation" (A4A in short) is a framework, for designing
> > industrial automation applications using the Ada language. It uses the
> > libmodbus library to allow building a Modbus TCP client or server, or a
> > Modbus RTU master.
> 
> > It can also use Hilscher communication boards allowing
> > to communicate on field buses like AS-Interface, CANopen, CC-Link,
> > DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos
> > III, POWERLINK, or VARAN.
> 
> In other words it does not implement the corresponding stacks? E.g.
> EtherCAT master.
No, as you say later on, "Ada for Automation" being for the moment a one-person project, I cannot even think about not using what is available or reinventing the wheel.
So it uses libmodbus and Hilscher communication boards.
I can even imagine writing a binding for OpenPOWERLINK but it won't be soon I am afraid.
And of course, if someone cares about other solutions, it's an open source project and I will be glad to include any contribution.

> 
> 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 can guarantee you that the same EtherCAT would be impossible to talk to
> using such a board.
Well, it happens everyday though.

> 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.

> So, my advice would be to implement these stacks natively.
That is surprising after reading what you have said just above.

> Yes, it is a huge amount of work and you will need community support.
Or an Hilscher board.

> 
> Even CANOpen master is many thousands times more complex than ModBus +
> support of various CAN controllers under various OSes.
I know.

> 
> EtherCAT master is thousands times more complex than CANOpen + raw Ethernet
> drivers needed for Windows.
Yes I know.
There was once an open source stack but it is not available because one need buying a licence from ETG.
When buying an Hilscher board, the stack is running on the board, under Hilscher's RT OS rcX, and we provide drivers for several OSes and a C Toolkit as source code for your not supported OS.
And of course Hilscher provides the Configuration Tool SYCON.net.

> 
> 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.

> 
> > 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.

> 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.

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.

>  
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de


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