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: Thu, 6 Nov 2014 14:31:12 +0100 Organization: cbb software GmbH Message-ID: <3wgqzq98u7gx$.17hpf52b2gd7l.dlg@40tude.net> References: <3e877e3f-c9ad-48a5-941d-08a7f5c3f317@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: J8B/Z5QBLnsGuljexy5Hxw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:23043 Date: 2014-11-06T14:31:12+01:00 List-Id: On Thu, 6 Nov 2014 03:14:43 -0800 (PST), slos wrote: First of all, congratulate and thank for the efforts. Don't mind a little bit critique which follows. > "Ada for Automation" (A4A in short) is a framework, for designing > industrial automation applications using the Ada language. It uses the > libmodbus library to allow building a Modbus TCP client or server, or a > Modbus RTU master. > It can also use Hilscher communication boards allowing > to communicate on field buses like AS-Interface, CANopen, CC-Link, > DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos > III, POWERLINK, or VARAN. In other words it does not implement the corresponding stacks? E.g. EtherCAT master. Regarding communication boards, they are not very useful. I can guarantee you that the same EtherCAT would be impossible to talk to using such a board. The protocol requires a very complicated initialization to talk even with relatively simple slaves. You might be able to connect a simple analogue I/O terminal, but nothing beyond that. Even TwinCAT, which is vendor's tool does not support everything. Our EtherCAT master does, almost (:-)). So, my advice would be to implement these stacks natively. Yes, it is a huge amount of work and you will need community support. Even CANOpen master is many thousands times more complex than ModBus + support of various CAN controllers under various OSes. EtherCAT master is thousands times more complex than CANOpen + raw Ethernet drivers needed for Windows. This is not one-man job. > Thanks to GtkAda it can be built with a GUI. > It can be built without of course. Do you mix data acquisition and distribution middleware with the GUI? That is not a good idea, generally. It is better to keep them separate. Which is a serious architectural problem how to communicate between the middleware dealing with the hardware, providing publisher-subscriber services and various clients. GUI is only one of them. Inter-process communication, DLLs are all system-dependent. No solution is scalable and portable, meets real-time requirements. It is a very difficult problem to resolve. > It works rather nicely but it would be fantastic if some experienced > person would review the code and give me some feedback on the design, the > bindings, the code quality... I'm a lonely Ada programmer, and I miss > feedback. > > Of course, I am interested in any collaboration around this matter. > So, do not hesitate to get in touch when you have some real case. We do the same stuff, but it is a commercial product. So I cannot do that on ethical and contractual grounds, sorry. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de