Re: Ada for Automation

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

Le vendredi 7 novembre 2014 09:29:38 UTC+1, Dmitry A. Kazakov a écrit :
> On Thu, 6 Nov 2014 13:58:11 -0800 (PST), slos wrote:
> 
> > 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:
> >> 
> >> 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 ?
> 
> I don't see why any of this requires a board, which is nothing but another
> computer. If it can do this, why the target system cannot?
Because for some specialized features like synchronisation with jitter in the nanosecond range require ad hoc hardware ?
Because an ad hoc OS gives better performance than a general one ?

> 
> >>> 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.
> 
> Why? Our solution is all about hardware integration. Its philosophy is that
> 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.

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

> 
> Given a choice between Beckhoff EtherCAT and ModBus terminals, same vendor,
> 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 networks.
And of course, when you need high rate data acquisition like for test benches it's just mandatory.

> 
> > So, over EtherCAT, the application layer is mainly CANopen like for POWERLINK.
> 
> Yes.
> 
> > CANopen allows to select in the object dictionary of each devices the data
> > that has to be cyclically exchanged.
> 
> 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 workaround. And that's where open source shines.

> 
> > This you cannot do with, let's say, Modbus.
> 
> Of course you can. There is no problem to query only data you needed over
> ModBus. We do this all the time.
> 
> 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.

> 
> >> ... 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.
> 
> Which would be more work than supporting stacks natively, and far more work
> in the future spent on maintenance. Protocols are more or less standardised
> 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 hardware 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, this layer would call the corresponding function in the selected board interface.
Seems rather simple in fact.

> 
> >> 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.
> 
> 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 applications and how it is perceived.

> 
> >>>> 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 ?
> 
> Usually engineers and usually not in Ada. Since the middleware is natively
> 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 applications.

We could continue this discussion about field buses but I am here to let the Ada community know about this project and get some feedback on my beginner'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.

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

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