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
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
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,
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
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
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
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
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
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
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.
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
11 matches
Mail list logo
