Re: Ada for Automation

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

Le vendredi 7 novembre 2014 18:16:34 UTC+1, Dmitry A. Kazakov a écrit :
> On Fri, 7 Nov 2014 07:23:20 -0800 (PST), slos wrote:
> 
> > Le vendredi 7 novembre 2014 14:44:13 UTC+1, Dmitry A. Kazakov a écrit :
> 
> >> You cannot do that on an ARM board anyway. And if you could, what for? If
> >> the data are to be processed on the PC via network which has jitter nowhere
> >> close to ns?
> > Of course we can ! Not an ARM board but a netX powered one with what's
> > needed to achieve that.
> 
> Just what I said. This is a one or two generation outdated architecture,
> before standardized terminals came. Pack the stuff into plastic box add
> Beckhoff's piggy back chip, here you are, a new EtherCAT slave. No boards
> ever needed.
> 
> >> If these data are not automation process data, then what are we talking
> >> about?
> >> 
> >> Such high speed data are processed in the terminals which provide integral
> >> measures which in turn don't require meaningless ns jitter. As an example
> >> take frequency measurements. They require ns clocking and pulse counting,
> >> which is done by the hardware, not by the board. Here the computed result
> >> is frequency, a pretty normal data with pretty no extraordinary jitter
> >> requirements.
> > I agree totally for this kind of data and you could say the same for let's
> > say a drive with an encoder connected to ; the loop is closed in the drive
> > and that would be the easiest architecture. But some customers want to
> > have the loop closed in the controller so that they can write the control
> > algorithm they need.
> 
> Yes, that is an outdated architecture with a closed-source PLC programmed
> in some garbage language like STEP 7. This is what we want to get rid of,
> replace it with open source portable controllers programmed in Ada. For
> this native stacks are needed. And because Ada is so scalable and portable
> I see no reason why automation and controller software cannot share the
> same middleware core!
> 
> >>> Because an ad hoc OS gives better performance than a general one ?
> >> 
> >> I doubt it much. The board must support some network protocol where all
> >> performance ends. Either it will run in several threads which would make it
> >> not better than general OS, or it will use some multiple buffering
> >> techniques with have *worse* performance being time-triggered.
> >
> > Don't doubt. Experiment with it.
> 
> Actually we do much performance measurements for various stacks.  
> 
> >>> 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.
> >> 
> >> Our customers require multiple channel 100ľs.
> > That's not what is needed even by motion control applications.
> 
> It is required in combustion motor R&D and drilling engines. At least the
> customers say so. I am not a physicist to argue with them.
> 
> > Curves show if there is some outstanding values.
> 
> How are you supposed to watch hundreds of curves sampled at 10ms rate for
> many months, in some cases? It does not work, but nobody admits that.
> 
> > No problem for him, he can analyse the data he captures.
> > 
> >> Alas, it is impossible to convince customers to invest into on-line
> >> diagnostics. Because that would cost time and money. 
> >> 
> >> With the data simply stored away, they believe they would be able to
> >> analyse them later, for nothing, using Excel to read 4Gb files... (:-))
> > One can filter out normal data to get only interesting one.
> 
> Better do that before storing them...
> 
> >>>> 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.
> >> 
> >> I doubt it. E.g. WAGO ModBus incremental encoders are no worse or better
> >> than EtherCAT ones. Actually ModBus encoders are simpler to use because the
> >> vendor does not try to pack all possible modes into single terminal
> >> requiring the automation system to configure dozens of parameters nobody
> >> needs. Less flexibility safer and simpler usage.
> > In drives applications, you have much more data to choose from, depending
> > on the working mode.
> 
> And where is any problem? We are communicating to multiple SPS controlling
> a whole drilling platform machine, a lot of data in each, all goes over
> ModBus. ModBus performance is only limited by the other side. E.g. WAGO
> ModBus is limited to 5ms because the internal bus cycle is 3ms and because
> the coupler is 100Base.
> 
> >>>>> 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.
> >> 
> >> You don't seriously suggest PCs to communicate over EtherCAT?
> > They can since Ethernet over EtherCAT allows this but I am mostly talking
> > about motion control and drives since those technologies have been
> > specifically developed for that particular need
> 
> All EtherCAT interfaced drivers we dealt with were quite normal EtherCAT
> terminals, nothing special.
> 
> >> There is
> >> nothing but terminals which is needed. For anything else there is data
> >> distribution protocols which has nothing to do with EtherCAT or any other
> >> field protocol. And in our designs we always physically separate filed and
> >> automation networks.
> > Since Ethernet based real time protocols were designed to provide both
> > kind of communications a single path, you have missed the point.
> > Of course, if your customer can afford two networks...
> 
> Anybody can, dual Ethernet ports cost nothing.
> 
> All our customers want it separate for safety and bureaucratic reasons.
> They often have different cabling requirements (the field network is
> usually in the machine hall, dusty, dirty, a lot of EM, LEMO jacks needed
> etc). HMI network is clean, but alas, hijacked by internal IT guys (we
> never let them into the field with their Windows-updates mess and
> firewalls).
> 
> >>> Seems rather simple in fact.
> >> 
> >> Right. And if the board can talk this protocol, why terminal cannot? See?
> >> You don't need dedicated boards in the end.
> > Please design a drive, an encoder, an IO module, what ever you want, and
> > then try to address the market.
> > Then you have to implement each protocol on your design. Good luck.
> 
> This is exactly what Beckhoff does in the case of EtherCAT slaves:
> 
> http://www.beckhoff.de/english/ethercat/fb1111_fb1122_fb1130.htm
> 
> or others do for ProfiNet, e.g.
> 
> http://am.renesas.com/products/soc/assp/fa_lsi/ethernet/tps1/index.jsp
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

And what about Ada and the project itself ?

BR,
Stéphane