Hello, I think the concept of the project is clear:
"PLC4X is a set of libraries for communicating with industrial programmable logic controllers (PLCs) using a variety of protocols but with a shared API." If your client allows you to publish the project in PLC4X, it is a very important opportunity for this project to increase and share knowledge. As for DCOM, it is a reality that will be with us no less than 20 years in the future due to its installed base [1]. We need to live with the Windows and Linux environment for years to come, and that is a reality. As for solutions with DCOM we have [2], in my case which allows using OPC-DA from Java, as in [3]. My grain of sand 1. https://opcfoundation.org/wp-content/uploads/2018/02/ARC-Report-OPC-Installed-Base-Insights.pdf 2. http://j-interop.org/ 3. https://www.eclipse.org/eclipsescada/ El mié., 9 sept. 2020 a las 8:31, Otto Fowler (<ottobackwa...@gmail.com>) escribió: > I think this should be hosted and more importantly _maintained_ outside > the project. If you want to add reference to it to the project site or > something, that would be something to talk about. > > > On September 9, 2020 at 08:28:12, Stefano Bossi (stefano.bo...@gmail.com) > wrote: > > Hi, > > personally I think this kind of approach will limit the usability of the > library in a very narrow subset of uses do to the windows operating system > dependency. > > I think you guys put a lot of effort in portability and small footprint of > the library and this is a great think in the industrial world where > typically there are small PC or embedded one. > > Using the library in a small PC like a Rasperry Pi with a linux distro and > a lot of attention for the security and hardening of the environment I > think is a pro for any industrial project > (e.g. Selinux, Firewall, minimal service installation, OSCAP security > profile compliance, etc ). > > Evaluating the effort required in reversing the DCOM protocol is something > to be taken into consideration before integrating a windows library in the > plc4x code. > > Maybe this could be a transient solution or a way to validate a full open > source solution. > > Regards, > Stefano > > > > On 09/09/2020 13:35, Christofer Dutz wrote: > > Hi Julian, > > > > the issue I see here is that it will make the build more complex (the > part using the wrapper will only be runnable on windows and not sure > if the license of the wrapped DLLs would allow including them). > > > It will also eliminate the ability to auto-port the driver to other > languages. > > > And, beyond that, it would limit these drivers to only work on a > subset of platforms (Aka ... a Java Driver that only works on Windows > Systems with installed subsystem for the PLC) > > > > I wouldn't want to make such a solution a first class citizen (aka > live in plc4j/drivers) ... we could sort of start providing some sort > of "plc4j/contrib" modules, if we have to go this path. > > > > But personally I would opt for at least having a look at the path I > described in slack: > > > > - Use the native libs and build an application that does the basic > interaction with the Windows DLLs > > - Use WireShark to record the communication > > - Have a look if it's not just a very small subset of DCOM that is used > > > > Perhaps it would sort of be like using some mspec types with a lot of > const fields to allow communication without any intermediate DLL .... > this would make it runnable on all target platforms and auto-portable > to all target languages of PLC4X. > > > > > > Chris > > > > Am 09.09.20, 09:50 schrieb "Julian Feinauer" > <j.feina...@pragmaticminds.de> <j.feina...@pragmaticminds.de>: > > > > Hi all, > > > > wanted to bring it tot he list as we already had a discussion in > the slack channel. > > We have a project where we consider integrating machinery in our > system. > > The machinery offers an SDK for communication which is windows > only and based on DCOM. > > Thus, the integration would be a wrapper around the SDK with > „only“ a PLC4X „frontend“. > > > > Personally, I consider this viable as our aim ist o have one > interface for „everything“. > > Nonetheless, I also agree with everybody saying that its not as > nice as having the complete stack in our hands. > > > > What do others think, should this be part oft he PLC4X project or > should we just do it separately. > > Personally idk that much but think it would be nice to have > maximum support in plc4x, if possible. > > > > Best > > Julian > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com <support.aan.automat...@siemens.com>*
