From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada for Automation Date: Tue, 18 Nov 2014 12:03:21 +0100 Organization: cbb software GmbH Message-ID: <1uhe64g68og8k.16z0icy3wfdhu.dlg@40tude.net> References: <3e877e3f-c9ad-48a5-941d-08a7f5c3f317@googlegroups.com> <18cxzhton11yu.1s3cu5zea772b.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: nyHeW7QjJmC1odUjK4LkDA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:23517 Date: 2014-11-18T12:03:21+01:00 List-Id: 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