Re: Ada for Automation

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

On Tue, 18 Nov 2014 11:43:12 +0100, Björn Lundin wrote:

> On 2014-11-18 10:28, Dmitry A. Kazakov wrote:
>> On Tue, 18 Nov 2014 09:52:13 +0100, Björn Lundin wrote:
>> 
>>> Very few sites use OPC, which was believed to be THE way of
>>> communicating in the early 2000s
>> 
>> Huh.
> 
> Sorry. I'm talking about communication between a host system (WCS) and
> a PLC with the purpose of moving pallets on a conveyor.
> OPC was something most vendor talked about, but
> not to many implemented it. As a transportation layer.
> The actual data being passed is different between most if not all vnedors.

Because OPC was totally unsuitable for the purpose. It was extremely slow,
hugely difficult to configure and had to run on the same host. Some of the
problems were lifted by the OPC UA, but it is still a monstrosity.

>>> Talking modbus directly would be nice, but in my field, I don't see
>>> any of the vendors preferring that to TCP/IP.
>> 
>> ModBus TCP is actually far more wide spread than ModBus RTU.
>> 
>> The design of middleware should support easy developing on new interfaces.
>> That is the idea of middleware, to decouple the application from the
>> hardware.
> 
> Yes, that is why I think Ada for Automation is interesting.
> But in practice, i still see the dominating way of this kind of
> communication to be TCP/IP with vendor-specific data content.
> 
> The standard question, with each new vendor we meet, is
> 'Can you do this'? and then they hand over a protocol specification -
> TCP/IP and a propriatary data content, with a small variation of
> * who is server?
> * one or two sockets?
> * protocol level acks
> * re-transmissions (if no nak, timeout and re-send)

Not very frequently, but it happens time to time. Unfortunately, fewer than
before, because hardware vendors tend to use "standard" industrial
protocols like EtherCAT, PROFIBUS etc, which are horrific mess and
extremely difficult to implement and no less difficult to configure and
maintain. Implementing a custom TCP/IP based protocol is usually hugely
simpler.

I don't understand "but". In our middleware (which is in Ada) there is a
well defined interface to design new device interfaces. In fact there is a
ready-to use base device type for a custom TCP/IP connection based client.
You would simply override Read and Write abstract operations. All automatic
connection and reconnection stuff is handled by the base type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de