Re: Ada for Automation

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

Le vendredi 7 novembre 2014 14:44:13 UTC+1, Dmitry A. Kazakov a écrit :
> On Fri, 7 Nov 2014 01:51:19 -0800 (PST), slos wrote:
> 
> > 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 ?
> 
> 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.
The jitter relates to the synchronisation signal. Data is delivered by the communication but it is applied on power stage only when the synchronisation happens.

Our customers may use FPGA / DSP / Micro-controllers... and PCs sometimes.

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

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

> 
> > 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.
"Ada for Automation" target applications are those in the millisecond range, that is most of automation ones.

> 
> >Then, analysing the data he can detect whether there is a mechanical
> > problem that has to be adjusted.
> 
> Yes, this is a typical line of the argument. The problem is that it is too
> much data to analyse later or ever.
This customer has to provide some evidence of the quality of its arm.
Curves show if there is some outstanding values.
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.

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

> 
> >>> 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, remember CANopen and Sercos.

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

> 
> >>>> ... 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 ?
> 
> Because vendors want to keep customers locked.
This is the general case.
But if there is a kind of HAL, you will be able to chose the best alternative.

> 
> > 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.
> 
> This what middleware distribution protocol is for.
> 
> > 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.

Or, you design your own super cool protocol and your own controller and all those devices that automation need. Welcome to the jungle.

> 
> > "Ada for Automation" wants them to learn Ada and use it for their
> > applications.
> 
> Yes, ideally.
>  
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

BR,
Stéphane