Re: Ada for Automation

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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?

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.

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

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

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

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... (:-))

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

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

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

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

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