Re: [DISCUSS] Add Wrappers to PLC4X Project

[Cesar Garcia]

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 ()
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"
>  :
>
>
>
> 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
*

Re: Pending threads after connection.close

[Christofer Dutz]

Thanks for that,

I'll look into that ... but it will take a while as I haven't been able to do 
any serious paid work in the last few weeks (Actually almost 2 months).

So I'll be concentrating on finishing the next part of my PLC4C project in 
order to get re-financed by the EU.
Free community support will come back after that's done. I am always offering 
commercial support it it's time-critical.

If anyone else here wants to pick up the ball, or if you want to do it 
yourself, I'd be very happy about that.

Chris


Am 09.09.20, 20:51 schrieb "Sebastian Voss" :

Hi Chris,

Thanks for you instant feedback! I created a ticket 
https://issues.apache.org/jira/browse/PLC4X-249 
 and attached a thread dump. 
Hopefully this helps to  trace it down.

Best regards,
Sebastian

> On 9. Sep 2020, at 19:27, Christofer Dutz  
wrote:
> 
> HI Sebastian,
> 
> this is definitely something that I have seen happen.
> If you can help us track down the issue, we would be extremely thankful.
> 
> Chris
> 
> 
> Am 09.09.20, 19:16 schrieb "Sebastian Voss" :
> 
>Hi guys,
> 
>I’m facing some issue when I try to quit my application. It seems 
connection.close() is not stopping all pending threads. Is this a known issue 
or am I doing something wrong?
> 
>String url = "s7://...";
>PlcDriverManager manager = new PlcDriverManager();
>PlcConnection connection = manager.getConnection(url);
>connection.close();
>System.out.println("closed”);  // gets printed
> 
>Best regards,
>Sebastian
> 

Re: Pending threads after connection.close

[Sebastian Voss]

Hi Chris,

Thanks for you instant feedback! I created a ticket 
https://issues.apache.org/jira/browse/PLC4X-249 
 and attached a thread dump. 
Hopefully this helps to  trace it down.

Best regards,
Sebastian

> On 9. Sep 2020, at 19:27, Christofer Dutz  wrote:
> 
> HI Sebastian,
> 
> this is definitely something that I have seen happen.
> If you can help us track down the issue, we would be extremely thankful.
> 
> Chris
> 
> 
> Am 09.09.20, 19:16 schrieb "Sebastian Voss" :
> 
>Hi guys,
> 
>I’m facing some issue when I try to quit my application. It seems 
> connection.close() is not stopping all pending threads. Is this a known issue 
> or am I doing something wrong?
> 
>String url = "s7://...";
>PlcDriverManager manager = new PlcDriverManager();
>PlcConnection connection = manager.getConnection(url);
>connection.close();
>System.out.println("closed”);  // gets printed
> 
>Best regards,
>Sebastian
> 

[jira] [Created] (PLC4X-249) Pending threads after connection.close

[Sebastian Voss (Jira)]

Sebastian Voss created PLC4X-249:


 Summary: Pending threads after connection.close
 Key: PLC4X-249
 URL: https://issues.apache.org/jira/browse/PLC4X-249
 Project: Apache PLC4X
  Issue Type: Bug
  Components: Driver-S7
Affects Versions: 0.7.0, 0.8.0
Reporter: Sebastian Voss
 Attachments: thread_dump.txt

I’m facing some issue when I try to quit my application. It seems 
connection.close() is not stopping all pending threads. Is this a known issue 
or am I doing something wrong?


{code:java}
String url = "s7://...";
PlcDriverManager manager = new PlcDriverManager();
PlcConnection connection = manager.getConnection(url);
connection.close();
System.out.println("closed”);  // gets printed but hangs afterwards{code}
I created a thread dump which is attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

RE: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

[Dominik Riemer]

Hi,

+1 (non-binding)

[OK] Download all staged artifacts under the url specified in the release vote 
email
[OK] Verify the signature is correct and references an Apache Email address
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[OK] Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES files in 
the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files in 
the extracted source bundle.
[OK] Can build from source via "mvn clean install" under Windows 10 (Java 8) 
and W10 WSL2 (Java 11)

Looks good!

Dominik

-Original Message-
From: Lukas Ott  
Sent: Wednesday, September 9, 2020 6:34 PM
To: dev@plc4x.apache.org
Subject: Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

+1 (binding)

[OK] Download all staged artifacts under the url specified in the release vote 
email [OK] Verify the signature is correct and references an Apache Email 
address [OK] Verify the SHA512 hashes [OK] Unzip the archive [OK] Verify the 
existence of LICENSE, NOTICE, README and RELEASE_NOTES files in the extracted 
source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files in 
the extracted source bundle.

Can build from Source via "mvn install"
OS: Ubuntu 20.04.1 LTS

No further remarks.

Am Mi., 9. Sept. 2020 um 18:10 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> +1 (binding)
>
> Chris
>
> [OK] Download all staged artifacts under the url specified in the 
> release vote email [OK] Verify the signature is correct and references 
> an Apache Email address [OK] Verify the SHA512 hashes [OK] Unzip the 
> archive [OK] Verify the existence of LICENSE, NOTICE, README and 
> RELEASE_NOTES files in the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES 
> files in the extracted source bundle.
> [OK] Run RAT externally to ensure there are no surprises.
> [OK] Search for SNAPSHOT references
> [OK] Search for Copyright references, and if they are in headers, make 
> sure these files containing them are mentioned in the LICENSE file.
> [MINOR] Build the project according to the Maven defaults
>
> Remarks:
>
> The script "mvnw" seems to not be executable.
>
>
>
> Am 08.09.20, 13:46 schrieb "Christofer Dutz" :
>
>Apache PLC4X Build-Tools Code-Generation 1.3.0 has been staged 
> under [2]
>and it’s time to vote on accepting it for release.
>
>All Maven artifacts are available under [1]. Voting will be 
> open for 72hr.
>
>A minimum of 3 binding +1 votes and more binding +1 than binding -1
>are required to pass.
>
>Repository:
> https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
>Release tag: releases/code-generation/1.3.0
>Hash for the release tag: 
> 7f2fab83d6cd0ccba41b8622d6abe4f8995748bd
>
>Per [3] "Before voting +1 PMC members are required to download
>the signed source code package, compile it as provided, and test
>the resulting executable on their own platform, along with also
>verifying that the package meets the requirements of the ASF policy
>on releases."
>
>You can achieve the above by following [4].
>
>[ ]  +1 accept (indicate what you validated - e.g. performed 
> the non-RM items in [4])
>[ ]  -1 reject (explanation required)
>
>
> [1]
> https://repository.apache.org/content/repositories/orgapacheplc4x-1029
> [2]
> https://dist.apache.org/repos/dist/dev/plc4x/build-tools/code-generation/1.3.0/rc1/
> [3]
> https://www.apache.org/dev/release/validation.html#approving-a-release
> [4] https://plc4x.apache.org/developers/release/validation.html
>
>
>
>
>

Re: Pending threads after connection.close

[Christofer Dutz]

HI Sebastian,

this is definitely something that I have seen happen.
If you can help us track down the issue, we would be extremely thankful.

Chris


Am 09.09.20, 19:16 schrieb "Sebastian Voss" :

Hi guys,

I’m facing some issue when I try to quit my application. It seems 
connection.close() is not stopping all pending threads. Is this a known issue 
or am I doing something wrong?

String url = "s7://...";
PlcDriverManager manager = new PlcDriverManager();
PlcConnection connection = manager.getConnection(url);
connection.close();
System.out.println("closed”);  // gets printed

Best regards,
Sebastian

Pending threads after connection.close

[Sebastian Voss]

Hi guys,

I’m facing some issue when I try to quit my application. It seems 
connection.close() is not stopping all pending threads. Is this a known issue 
or am I doing something wrong?

String url = "s7://...";
PlcDriverManager manager = new PlcDriverManager();
PlcConnection connection = manager.getConnection(url);
connection.close();
System.out.println("closed”);  // gets printed

Best regards,
Sebastian

Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

[Lukas Ott]

+1 (binding)

[OK] Download all staged artifacts under the url specified in the release
vote email
[OK] Verify the signature is correct and references an Apache Email address
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[OK] Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES
files in the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files
in the extracted source bundle.

Can build from Source via "mvn install"
OS: Ubuntu 20.04.1 LTS

No further remarks.

Am Mi., 9. Sept. 2020 um 18:10 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> +1 (binding)
>
> Chris
>
> [OK] Download all staged artifacts under the url specified in the release
> vote email
> [OK] Verify the signature is correct and references an Apache Email address
> [OK] Verify the SHA512 hashes
> [OK] Unzip the archive
> [OK] Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES
> files in the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files
> in the extracted source bundle.
> [OK] Run RAT externally to ensure there are no surprises.
> [OK] Search for SNAPSHOT references
> [OK] Search for Copyright references, and if they are in headers, make
> sure these files containing them are mentioned in the LICENSE file.
> [MINOR] Build the project according to the Maven defaults
>
> Remarks:
>
> The script "mvnw" seems to not be executable.
>
>
>
> Am 08.09.20, 13:46 schrieb "Christofer Dutz" :
>
>Apache PLC4X Build-Tools Code-Generation 1.3.0 has been staged
> under [2]
>and it’s time to vote on accepting it for release.
>
>All Maven artifacts are available under [1]. Voting will be open
> for 72hr.
>
>A minimum of 3 binding +1 votes and more binding +1 than binding -1
>are required to pass.
>
>Repository:
> https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
>Release tag: releases/code-generation/1.3.0
>Hash for the release tag: 7f2fab83d6cd0ccba41b8622d6abe4f8995748bd
>
>Per [3] "Before voting +1 PMC members are required to download
>the signed source code package, compile it as provided, and test
>the resulting executable on their own platform, along with also
>verifying that the package meets the requirements of the ASF policy
>on releases."
>
>You can achieve the above by following [4].
>
>[ ]  +1 accept (indicate what you validated - e.g. performed the
> non-RM items in [4])
>[ ]  -1 reject (explanation required)
>
>
> [1]
> https://repository.apache.org/content/repositories/orgapacheplc4x-1029
> [2]
> https://dist.apache.org/repos/dist/dev/plc4x/build-tools/code-generation/1.3.0/rc1/
> [3]
> https://www.apache.org/dev/release/validation.html#approving-a-release
> [4] https://plc4x.apache.org/developers/release/validation.html
>
>
>
>
>

Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

[Christofer Dutz]

+1 (binding) 

Chris

[OK] Download all staged artifacts under the url specified in the release vote 
email
[OK] Verify the signature is correct and references an Apache Email address
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[OK] Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES files in 
the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES files in 
the extracted source bundle.
[OK] Run RAT externally to ensure there are no surprises.
[OK] Search for SNAPSHOT references
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[MINOR] Build the project according to the Maven defaults

Remarks:

The script "mvnw" seems to not be executable.



Am 08.09.20, 13:46 schrieb "Christofer Dutz" :

   Apache PLC4X Build-Tools Code-Generation 1.3.0 has been staged under [2]
   and it’s time to vote on accepting it for release.

   All Maven artifacts are available under [1]. Voting will be open for 
72hr.

   A minimum of 3 binding +1 votes and more binding +1 than binding -1
   are required to pass.

   Repository: https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
   Release tag: releases/code-generation/1.3.0
   Hash for the release tag: 7f2fab83d6cd0ccba41b8622d6abe4f8995748bd

   Per [3] "Before voting +1 PMC members are required to download
   the signed source code package, compile it as provided, and test
   the resulting executable on their own platform, along with also
   verifying that the package meets the requirements of the ASF policy
   on releases."

   You can achieve the above by following [4].

   [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
items in [4])
   [ ]  -1 reject (explanation required)


[1] https://repository.apache.org/content/repositories/orgapacheplc4x-1029
[2] 
https://dist.apache.org/repos/dist/dev/plc4x/build-tools/code-generation/1.3.0/rc1/
[3] https://www.apache.org/dev/release/validation.html#approving-a-release
[4] https://plc4x.apache.org/developers/release/validation.html

[BUILD-STABLE]: Job 'PLC4X/PLC4X/develop [develop] [71]'

[Apache Jenkins Server]

BUILD-STABLE: Job 'PLC4X/PLC4X/develop [develop] [71]':

Is back to normal.

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [70]'

[Apache Jenkins Server]

BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [70]':

Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/70/;>PLC4X/PLC4X/develop
 [develop] [70]"

Re: [DISCUSS] Add Wrappers to PLC4X Project

[Otto Fowler]

 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"
 :



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

Re: [DISCUSS] Add Wrappers to PLC4X Project

[Stefano Bossi]

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" :
>
> 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
>



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Add Wrappers to PLC4X Project

[Christofer Dutz]

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" :

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

[DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

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