plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cesar Garcia <cesar.gar...@ceos.com.ve>
Subject Re: [DISCUSS] Add Wrappers to PLC4X Project
Date Wed, 09 Sep 2020 22:32:00 GMT
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 (<ottobackwards@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.bossi@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.feinauer@pragmaticminds.de> <j.feinauer@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.automation@siemens.com
<support.aan.automation@siemens.com>*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message