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?
> 
> >>> 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.
> 
> 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.
> 
> 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.
> 
> > 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.
> 
> > 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.
No, that's not the same thing.
With today field buses you are able to select what will be exchanged cyclically in a PDO (CANopen / EtherCAT / POWERLINK) or Assembly (Ethernet/IP). The device will prepare its answer accordingly.
With Modbus, you can access of course the whole data set but you end up reading more data and filter out the one you don't need or make several requests to pick up only the data needed.
Of course, performance wise, the former is better.

> 
> 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.
> 
> >> ... 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.
> 
> >> 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.
> 
> >>>> 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.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de