Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Otto Fowler]

 the MSPEC is supposed to be multi-language, so I don’t think java specific
types would go into the file definition, but there might be another way to
do something and have it generated correctly

On September 11, 2020 at 17:05:06, Ben Hutcheson (ben.hut...@gmail.com)
wrote:

Hi,

After creating a PR for the modbus data types and moving the max/min checks
and data conversion tasks to the individual PLCValue classes, the
ModbusFieldHandler class has been reduced to a bunch of cases which map a
Java Datatype to a PLC Datatype. Looking at the S7FieldHandler class it
seems to be doing the same.

What are your thoughts on creating a new section within the mspec file to
allow mapping Java datatypes to PlcValue types and then automatically
creating the FieldHander class for each protocol? The mspec section would
list all the Fields available for the protocol as well as datatypes e.g.
Modbus would have the coil/discrete/input/holding/extended fields and map
the Java Integer to INT,UINT,DINT,REAL, map Floats to REAL types, etc..

This would allow protocols to override mappings to PLCValue classes when
needed as well.

Kind Regards

Ben

On Tue, Sep 8, 2020 at 7:52 PM Ben Hutcheson  wrote:

> Hi Chris,
>
> I'm not sure I follow your last email,
>
> I have pushed a commit to *hutcheb:Feature/ModbusDataType
> , *which
> includes some of the changes I've proposed.
>
> 1) Within
>
build-utils/language-java/src/main/resources/templates/java/data-io-template.ftlh,

> I've added a cast to the PLCValue so that we can use methods specific to
> the PLCValue types to decode input from th PLC not just the methods
defined
> in the interface.
> 2) I've added the initial framework for adding Modbus datatypes within
the
> address string. This is able to support the INT (r/w) and UINT (w)
> datatypes when parsing a Java String (I have to clean it up and fix up
> handling of PLCList types)
> 3) I've updated the Modbus.mspec to include the INT datatype within the
> dataio section, I would have to add the rest of the datatypes in the same
> section.
> 4) I've added PlcINT and PlcUINT classes and have moved the handling of
> parsing different Java Datatypes into these, as well as some handling of
> decoding within the PlcINT classes. Along with the last point this allows
> us to decode the INT datatype within the DataItemIO.java file.
>
> Let me know what you think?
>
> Kind Regards
>
> Ben
>
> On Tue, Sep 8, 2020 at 11:44 AM Christofer Dutz 

> wrote:
>
>> Hi Ben,
>>
>> well the PlcValue types are based on the types used in the language they
>> are used in. In PLC4C, which supports signed and unsigned types, I
>> implemented them differently.
>> Initially I thought that if the PlcValues would simply have a byte-array
>> and a type, then it would be universal ... but I thought accessing the
>> values would require more cpu and memory.
>>
>> But given the fact that if we had such generic PlcValues, we could use
>> them in all drivers ... sort of makes them more interesting.
>>
>> We could have multiple implementations of them ... so we could have
these
>> DefaultPlcValue implementation for the normal 61131 datatypes but give
>> drivers the opportunity to provide customizations for special types.
>>
>> What do you think?
>>
>> Chris
>>
>>
>>
>> Am 08.09.20, 14:44 schrieb "Ben Hutcheson" :
>>
>> Hi Chris,
>>
>> The case where PLC data types are mapped to 16 bit registers isn't a
>> special case, as the Modbus protocol only supports 16 bit registers
>> but it
>> doesn't specify what format the data should be in,any PLC data type
>> can be
>> mapped to these and then passed over Modbus. It would definitely be
>> handy
>> to be able to convert any of the PLC datatypes back from Modbus 16-bit
>> registers to whatever datatype they should be. I've done some work
>> already
>> on the specific case of mapping a Java String to the
>> PLCInteger/PLCShort
>> classes and can expand it basing it off the S7 functions that do the
>> same.
>> We can then look at the differences and consolidate them if possible?
>>
>> However it would be great to be able to add unambiguous classes to
>> plc4j/api/src/main/java/org/apache/plc4x/java/api/value for each of
>> the IEC
>> datatypes instead of these being based off Java types.
>>
>> Using the same format as the S7 protocol the address string would be
>> holding-register:1000:REAL[10] instead though, I don't think this will
>> cause issues if we make it optional and default to INT or BOOL as
>> required.
>>
>> Kind Regards
>>
>> Ben
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz <
>> christofer.d...@c-ware.de>
>> wrote:
>>
>> > Hi Ben ...
>> >
>> > Sorry for my email... I should really finish reading before
>> replying :-(
>> >
>> > About your suggestion to add it to the type to the ModbusField ... I
>> > agree. But I would simply extend the Address string the same way
>> the TIA
>> > addresses were extended.
>> > Cause the 

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Ben Hutcheson]

Hi,

After creating a PR for the modbus data types and moving the max/min checks
and data conversion tasks to the individual PLCValue classes, the
ModbusFieldHandler class has been reduced to a bunch of cases which map a
Java Datatype to a PLC Datatype. Looking at the S7FieldHandler class it
seems to be doing the same.

What are your thoughts on creating a new section within the mspec file to
allow mapping Java datatypes to PlcValue types and then automatically
creating the FieldHander class for each protocol? The mspec section would
list all the Fields available for the protocol as well as datatypes e.g.
Modbus would have the coil/discrete/input/holding/extended fields and map
the Java Integer to INT,UINT,DINT,REAL, map Floats to REAL types, etc..

This would allow protocols to override mappings to PLCValue classes when
needed as well.

Kind Regards

Ben

On Tue, Sep 8, 2020 at 7:52 PM Ben Hutcheson  wrote:

> Hi Chris,
>
> I'm not sure I follow your last email,
>
> I have pushed a commit to *hutcheb:Feature/ModbusDataType
> , *which
> includes some of the changes I've proposed.
>
> 1) Within
> build-utils/language-java/src/main/resources/templates/java/data-io-template.ftlh,
> I've added a cast to the PLCValue so that we can use methods specific to
> the PLCValue types to decode input from th PLC not just the methods defined
> in the interface.
> 2) I've added the initial framework for adding Modbus datatypes within the
> address string. This is able to support the INT (r/w) and UINT (w)
> datatypes when parsing a Java String (I have to clean it up and fix up
> handling of PLCList types)
> 3) I've updated the Modbus.mspec to include the INT datatype within the
> dataio section, I would have to add the rest of the datatypes in the same
> section.
> 4) I've added PlcINT and PlcUINT classes and have moved the handling of
> parsing different Java Datatypes into these, as well as some handling of
> decoding within the PlcINT classes. Along with the last point this allows
> us to decode the INT datatype within the DataItemIO.java file.
>
> Let me know what you think?
>
> Kind Regards
>
> Ben
>
> On Tue, Sep 8, 2020 at 11:44 AM Christofer Dutz 
> wrote:
>
>> Hi Ben,
>>
>> well the PlcValue types are based on the types used in the language they
>> are used in. In PLC4C, which supports signed and unsigned types, I
>> implemented them differently.
>> Initially I thought that if the PlcValues would simply have a byte-array
>> and a type, then it would be universal ... but I thought accessing the
>> values would require more cpu and memory.
>>
>> But given the fact that if we had such generic PlcValues, we could use
>> them in all drivers ... sort of makes them more interesting.
>>
>> We could have multiple implementations of them ... so we could have these
>> DefaultPlcValue implementation for the normal 61131 datatypes but give
>> drivers the opportunity to provide customizations for special types.
>>
>> What do you think?
>>
>> Chris
>>
>>
>>
>> Am 08.09.20, 14:44 schrieb "Ben Hutcheson" :
>>
>> Hi Chris,
>>
>> The case where PLC data types are mapped to 16 bit registers isn't a
>> special case, as the Modbus protocol only supports 16 bit registers
>> but it
>> doesn't specify what format the data should be in,any PLC data type
>> can be
>> mapped to these and then passed over Modbus. It would definitely be
>> handy
>> to be able to convert any of the PLC datatypes back from Modbus 16-bit
>> registers to whatever datatype they should be. I've done some work
>> already
>> on the specific case of mapping a Java String to the
>> PLCInteger/PLCShort
>> classes and can expand it basing it off the S7 functions that do the
>> same.
>> We can then look at the differences and consolidate them if possible?
>>
>> However it would be great to be able to add unambiguous classes to
>> plc4j/api/src/main/java/org/apache/plc4x/java/api/value for each of
>> the IEC
>> datatypes instead of these being based off Java types.
>>
>> Using the same format as the S7 protocol the address string would be
>> holding-register:1000:REAL[10] instead though, I don't think this will
>> cause issues if we make it optional and default to INT or BOOL as
>> required.
>>
>> Kind Regards
>>
>> Ben
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz <
>> christofer.d...@c-ware.de>
>> wrote:
>>
>> > Hi Ben ...
>> >
>> > Sorry for my email... I should really finish reading before
>> replying :-(
>> >
>> > About your suggestion to add it to the type to the ModbusField ... I
>> > agree. But I would simply extend the Address string the same way
>> the TIA
>> > addresses were extended.
>> > Cause the problem I'm seeing is that for the 61131 datatypes we can
>> > provide an enum, but not for any custom types the driver might be
>> > supporting. With a String 

[GitHub] [plc4x] hutcheb commented on pull request #186: Feature/modbus data type

[GitBox]

hutcheb commented on pull request #186:
URL: https://github.com/apache/plc4x/pull/186#issuecomment-691032464


   Hi Niclas,
   
   The plan is to add support for as many IEC 61131 data types as possible. 
I've added DINT as an example for what it would take to add additional data 
types but will wait for more feedback before adding more.
   
   Ben
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Add Wrappers to PLC4X Project

[Christofer Dutz]

Hmm ... I usually always hit reply ... but I have seen some times the email 
just goes to the sender ... strange ...

This time it didn't ...

Am 11.09.20, 09:30 schrieb "Julian Feinauer" :

Forwarding it tot he list (i think chris simply hit reply...) : )

Am 11.09.20, 09:27 schrieb "Christofer Dutz" :

And my only concern about native-drivers is that I want to prevent us 
from becoming lazy.

I know we had the EIP and Modbus drivers by using external libs and 
that wasn't very pleasant (At least not for me)
We were relying on libs we had no control over. It got us to the point 
where we could support these protocols,
But looking back it cost us (mainly me) way more time in supporting 
them than it would have cost me if we had implemented the parts we needed.

So I would generally say:
- If it’s a technical problem preventing us from implementing it fully 
in plc4x (CAN, Profibus, ...) then this is the way to go ...
- If it's a protocol problem (want to avoid implementing the protocol 
in order to save time) ... then we should put it in the sandbox

Chris



Am 11.09.20, 09:01 schrieb "Julian Feinauer" 
:

Hi folks,

thanks for all the replies and the controversy in here shows that 
ist good to discuss the matter, indeed : )

I like Cesars way of putting it (which is pretty close to mine) 
that PLC4X is a unified API.
This is the Killer thing here.

And what we currently do and mostly did was "PLC4X native". Because 
we get all these nice benefits of controlling everyhting and doing code for all 
languages.

But, we may end up in situations where there i seither no 
possiblity to do a native implementation (profinet, profibus, CAN, ...) where 
we need some kind of special hardware where I would like to still have it in 
the project.
This would mean that there is some special setup instruction how to 
setup the "native" part and then there is some glue code (could easily again be 
plattform independent) like a PLC4X generic driver (@Christofer Dutz a bit like 
what we reasoned about with PLCnext) which "binds" them together.

As we are really small on man-power and maintainers I think it is a 
good and reasonable way to go with a "integrate whats already there" instead of 
a "try to find the single silver bullet and die in beatuy".

So my reasoning at the moment is to place something like this 
wrapper as native code in a generic section somewhere in the "PLC4X native" 
part, that it can be integrated. But then host install instructions fort he 
"agent" or proprietary part somewhere else in an "integration" part (not like 
integration into other downstream systems but integration of other 
communication layers).

Is this something which sounds acceptable for the community are 
there feelings against it?

Julian

Am 11.09.20, 02:20 schrieb "Ben Hutcheson" :

Hi,

I agree with Chris, having new drivers in a contrib section 
would be a good
idea to make it clear that it hasn't been developed as much as 
other
protocols or that there is some constraint excluding it from 
the main
driver section. The worst that could happen is that it gets 
culled
eventually because it isn't maintained and no one else shows 
interest.

What protocol is it?

I'm assuming you've already set your mind on developing it, but 
something
to consider. Is anybody else likely to want to use it to 
warrant spending
time on it? Is there a spec that is published? Does the 
manufacturer change
the protocol often? Can they provide information on the 
protocol?

Kind Regards

Ben

On Thu, Sep 10, 2020 at 5:03 PM Łukasz Dywicki 
 wrote:

> It is pretty good question to answer. Given that Julien 
proposal
> includes native binary I can also add that socketcan stuff I 
am working
> on .. is bound only to Linux due to native dependency in 
JavaCAN transport.
>
> From my perspective I can tell that it really depends on 
budget you
> have. Our CAN journey started from CAN over Ethernet (UDP) 
and ended up
> in dark corner which some of you could observe over past 
weeks. We had
> to do it, because that was customer requirement (skip vendor 
gateway).
> If you don't have such requirement then I would say there is 
quite weak
> case to invest in it.
> My point comes from observations. I wrote couple of MSpec 
files and it
> was indeed fun. Both profinet and lldp took me a little bit, 
but
> structures I 

FW: [DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

Forwarding it tot he list (i think chris simply hit reply...) : )

Am 11.09.20, 09:27 schrieb "Christofer Dutz" :

And my only concern about native-drivers is that I want to prevent us from 
becoming lazy.

I know we had the EIP and Modbus drivers by using external libs and that 
wasn't very pleasant (At least not for me)
We were relying on libs we had no control over. It got us to the point 
where we could support these protocols,
But looking back it cost us (mainly me) way more time in supporting them 
than it would have cost me if we had implemented the parts we needed.

So I would generally say:
- If it’s a technical problem preventing us from implementing it fully in 
plc4x (CAN, Profibus, ...) then this is the way to go ...
- If it's a protocol problem (want to avoid implementing the protocol in 
order to save time) ... then we should put it in the sandbox

Chris



Am 11.09.20, 09:01 schrieb "Julian Feinauer" :

Hi folks,

thanks for all the replies and the controversy in here shows that ist 
good to discuss the matter, indeed : )

I like Cesars way of putting it (which is pretty close to mine) that 
PLC4X is a unified API.
This is the Killer thing here.

And what we currently do and mostly did was "PLC4X native". Because we 
get all these nice benefits of controlling everyhting and doing code for all 
languages.

But, we may end up in situations where there i seither no possiblity to 
do a native implementation (profinet, profibus, CAN, ...) where we need some 
kind of special hardware where I would like to still have it in the project.
This would mean that there is some special setup instruction how to 
setup the "native" part and then there is some glue code (could easily again be 
plattform independent) like a PLC4X generic driver (@Christofer Dutz a bit like 
what we reasoned about with PLCnext) which "binds" them together.

As we are really small on man-power and maintainers I think it is a 
good and reasonable way to go with a "integrate whats already there" instead of 
a "try to find the single silver bullet and die in beatuy".

So my reasoning at the moment is to place something like this wrapper 
as native code in a generic section somewhere in the "PLC4X native" part, that 
it can be integrated. But then host install instructions fort he "agent" or 
proprietary part somewhere else in an "integration" part (not like integration 
into other downstream systems but integration of other communication layers).

Is this something which sounds acceptable for the community are there 
feelings against it?

Julian

Am 11.09.20, 02:20 schrieb "Ben Hutcheson" :

Hi,

I agree with Chris, having new drivers in a contrib section would 
be a good
idea to make it clear that it hasn't been developed as much as other
protocols or that there is some constraint excluding it from the 
main
driver section. The worst that could happen is that it gets culled
eventually because it isn't maintained and no one else shows 
interest.

What protocol is it?

I'm assuming you've already set your mind on developing it, but 
something
to consider. Is anybody else likely to want to use it to warrant 
spending
time on it? Is there a spec that is published? Does the 
manufacturer change
the protocol often? Can they provide information on the protocol?

Kind Regards

Ben

On Thu, Sep 10, 2020 at 5:03 PM Łukasz Dywicki 
 wrote:

> It is pretty good question to answer. Given that Julien proposal
> includes native binary I can also add that socketcan stuff I am 
working
> on .. is bound only to Linux due to native dependency in JavaCAN 
transport.
>
> From my perspective I can tell that it really depends on budget 
you
> have. Our CAN journey started from CAN over Ethernet (UDP) and 
ended up
> in dark corner which some of you could observe over past weeks. 
We had
> to do it, because that was customer requirement (skip vendor 
gateway).
> If you don't have such requirement then I would say there is 
quite weak
> case to invest in it.
> My point comes from observations. I wrote couple of MSpec files 
and it
> was indeed fun. Both profinet and lldp took me a little bit, but
> structures I got structures and I was able to parse real traffic. 
What I
> skipped in my earlier attempts was implementation of driver api 
where
> you actually start implementing necessary conversation logic. 
Having a
> fresh look from CANopen perspective - it is quite big effort which
> requires time.
>
> My point outlining above is 

FW: [DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

Forwarding it tot he list (i think chris simply hit reply...) : )

Am 11.09.20, 09:22 schrieb "Christofer Dutz" :

Hi Julian,

I think a "native-drivers" might be a good approach. But if they should 
live outside of the sandbox, I would have to insist that who adds something 
like that, to make sure the build works on all platforms.
And with "work" I mean: "Not break the rest". My greatest nightmare would 
be having to maintain a build that's highly platform dependent.

And we would need documentation for each of them. How to set them up, how 
to build them. 
I know documentation hasn't been what we are best at, but especially for 
these types of drivers they would be essential.

I do agree that some drivers require special hardware transports. CAN and 
Profibus would fit for this. However Profinet and the protocol you are talking 
about is not really a transport problem, but a protocol problem. 
I know we could pretty directly implement Profinet with mspec ... it's 
probably just a pretty big protocol - specification-wise. Or does that PLC you 
want to talk to use anything else than Ethernet as transport? 
You mentioned DCOM ... so I wouldn't call it a technical problem.

We could do one thing: 
- Add them in a native drivers section first
- Migrate them into the drivers section by porting them to mspec as far as 
possible later

How about that?

Chris





Am 11.09.20, 09:01 schrieb "Julian Feinauer" :

Hi folks,

thanks for all the replies and the controversy in here shows that ist 
good to discuss the matter, indeed : )

I like Cesars way of putting it (which is pretty close to mine) that 
PLC4X is a unified API.
This is the Killer thing here.

And what we currently do and mostly did was "PLC4X native". Because we 
get all these nice benefits of controlling everyhting and doing code for all 
languages.

But, we may end up in situations where there i seither no possiblity to 
do a native implementation (profinet, profibus, CAN, ...) where we need some 
kind of special hardware where I would like to still have it in the project.
This would mean that there is some special setup instruction how to 
setup the "native" part and then there is some glue code (could easily again be 
plattform independent) like a PLC4X generic driver (@Christofer Dutz a bit like 
what we reasoned about with PLCnext) which "binds" them together.

As we are really small on man-power and maintainers I think it is a 
good and reasonable way to go with a "integrate whats already there" instead of 
a "try to find the single silver bullet and die in beatuy".

So my reasoning at the moment is to place something like this wrapper 
as native code in a generic section somewhere in the "PLC4X native" part, that 
it can be integrated. But then host install instructions fort he "agent" or 
proprietary part somewhere else in an "integration" part (not like integration 
into other downstream systems but integration of other communication layers).

Is this something which sounds acceptable for the community are there 
feelings against it?

Julian

Am 11.09.20, 02:20 schrieb "Ben Hutcheson" :

Hi,

I agree with Chris, having new drivers in a contrib section would 
be a good
idea to make it clear that it hasn't been developed as much as other
protocols or that there is some constraint excluding it from the 
main
driver section. The worst that could happen is that it gets culled
eventually because it isn't maintained and no one else shows 
interest.

What protocol is it?

I'm assuming you've already set your mind on developing it, but 
something
to consider. Is anybody else likely to want to use it to warrant 
spending
time on it? Is there a spec that is published? Does the 
manufacturer change
the protocol often? Can they provide information on the protocol?

Kind Regards

Ben

On Thu, Sep 10, 2020 at 5:03 PM Łukasz Dywicki 
 wrote:

> It is pretty good question to answer. Given that Julien proposal
> includes native binary I can also add that socketcan stuff I am 
working
> on .. is bound only to Linux due to native dependency in JavaCAN 
transport.
>
> From my perspective I can tell that it really depends on budget 
you
> have. Our CAN journey started from CAN over Ethernet (UDP) and 
ended up
> in dark corner which some of you could observe over past weeks. 
We had
> to do it, because that was customer requirement (skip vendor 
gateway).
> If you don't have such requirement then I would say there is 
quite weak
> case to invest in it.
> My point comes from observations. I wrote couple of MSpec files 

Re: [DISCUSS] Add Wrappers to PLC4X Project

[Julian Feinauer]

Hi folks,

thanks for all the replies and the controversy in here shows that ist good to 
discuss the matter, indeed : )

I like Cesars way of putting it (which is pretty close to mine) that PLC4X is a 
unified API.
This is the Killer thing here.

And what we currently do and mostly did was "PLC4X native". Because we get all 
these nice benefits of controlling everyhting and doing code for all languages.

But, we may end up in situations where there i seither no possiblity to do a 
native implementation (profinet, profibus, CAN, ...) where we need some kind of 
special hardware where I would like to still have it in the project.
This would mean that there is some special setup instruction how to setup the 
"native" part and then there is some glue code (could easily again be plattform 
independent) like a PLC4X generic driver (@Christofer Dutz a bit like what we 
reasoned about with PLCnext) which "binds" them together.

As we are really small on man-power and maintainers I think it is a good and 
reasonable way to go with a "integrate whats already there" instead of a "try 
to find the single silver bullet and die in beatuy".

So my reasoning at the moment is to place something like this wrapper as native 
code in a generic section somewhere in the "PLC4X native" part, that it can be 
integrated. But then host install instructions fort he "agent" or proprietary 
part somewhere else in an "integration" part (not like integration into other 
downstream systems but integration of other communication layers).

Is this something which sounds acceptable for the community are there feelings 
against it?

Julian

Am 11.09.20, 02:20 schrieb "Ben Hutcheson" :

Hi,

I agree with Chris, having new drivers in a contrib section would be a good
idea to make it clear that it hasn't been developed as much as other
protocols or that there is some constraint excluding it from the main
driver section. The worst that could happen is that it gets culled
eventually because it isn't maintained and no one else shows interest.

What protocol is it?

I'm assuming you've already set your mind on developing it, but something
to consider. Is anybody else likely to want to use it to warrant spending
time on it? Is there a spec that is published? Does the manufacturer change
the protocol often? Can they provide information on the protocol?

Kind Regards

Ben

On Thu, Sep 10, 2020 at 5:03 PM Łukasz Dywicki  wrote:

> It is pretty good question to answer. Given that Julien proposal
> includes native binary I can also add that socketcan stuff I am working
> on .. is bound only to Linux due to native dependency in JavaCAN 
transport.
>
> From my perspective I can tell that it really depends on budget you
> have. Our CAN journey started from CAN over Ethernet (UDP) and ended up
> in dark corner which some of you could observe over past weeks. We had
> to do it, because that was customer requirement (skip vendor gateway).
> If you don't have such requirement then I would say there is quite weak
> case to invest in it.
> My point comes from observations. I wrote couple of MSpec files and it
> was indeed fun. Both profinet and lldp took me a little bit, but
> structures I got structures and I was able to parse real traffic. What I
> skipped in my earlier attempts was implementation of driver api where
> you actually start implementing necessary conversation logic. Having a
> fresh look from CANopen perspective - it is quite big effort which
> requires time.
>
> My point outlining above is simple - as long as we have just one
> dominant language as we have and we fail to attract more diverse pool of
> people to start writing conversation logic for other languages does not
> give big benefit. I agree it is important, but it is much more necessary
> now to support wider pool of end devices. Once we will build big enough
> pool of people who have commercial interest in moving stuff between
> operating systems and platforms we will be able to start joint
> investment together. There is no better explanation than savings on
> hardware when it comes to large scale deployments.
>
> From my point of view - I would welcome your stuff anywhere, even in
> sandbox. Just remember to unify DLL loading logic. ;-)
>
> Best regards,
> Łukasz
>
> On 10.09.2020 00:32, Cesar Garcia wrote:
> > 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