Re: Ada for Automation

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

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