Re: [DISCUSS] Add Wrappers to PLC4X Project
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
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
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
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
Re: [DISCUSS] Add Wrappers to PLC4X Project
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 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. > >> > >>
Re: [DISCUSS] Add Wrappers to PLC4X Project
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 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
Re: [DISCUSS] Add Wrappers to PLC4X Project
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: [DISCUSS] Add Wrappers to PLC4X Project
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
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
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
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
