Hi Chris, I'm definetly for an OPC UA server and also think that this will bring us more towards people simply wanting to use plc4x. I'm no OPC UA expert so I don’t know if we need Milo to define the scheme upfront, as this would mean that you need to supply a mapping file to the plc-opc-ua server for mapping the node tree to PLC stuff and so on.
My idea in contrast was meant to be able to play around the same way we do. But I agree that an OPC UA Server would be a better first step as it opens plc4x even to non developers (and my approach would only open it for developers in other languages). Perhaps in the end we can have a server serving multiple endpoints with different features each (OPC UA, Rest (everybody likes rest, I guess???), thrift, ...). Julian PS.: Should we open a Jira for that to collect some specs there and some ideas so that someone can start hacking into it? @Matthias: Wouldn’t this be a good project for your students? Am 02.11.18, 17:44 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, Wouldn't a rudimentary OPC-UA Server also do this? A PLC4X OPC-UA Server application is one of the most asked for features from outside the community. If we built an application that for example uses Milo build a stand-alone application which offers an OPC-UA Server interface and uses PLC4X internally to communicate with other devices, wouldn't we immediately offer such support for other languages? I'm a little worried about adjusting the build to build all the different types of clients. Thrift could generate the code, but it could be challenging to build the concrete driver implementations. In the end we'll have to deal with this problem, but I think the OPC-UA Bridge would be the quickest solution which is integratable into our build and would bring the biggest benefit. Chris Am 02.11.18, 17:10 schrieb "Julian Feinauer" <[email protected]>: Hey all, I thought of our problem to currently only have support for one language (Java). For usage scenarios on “regular” devices (not embedded ones) one “simple” and “easy” way to bootstrap our current Java Implementation to other languages would be created by using Thrift or protobuf. In short, the idea is to have a Java “Server” (call it proxy or bridge) which interacts with the PLCs via our Java Implementation. Furthermore, the Java Application hosts a Server where “thin clients” in other Languages can connect and issue commands. Basically we could have Python < ------ > C++ < ------ > PlcGatewayServer < ------ > PLC C# < ------ > … (Sorry for the bad ASCII Art). Pro’s of this approach: * Is doable in “few” Time and other languags can be connected with “no effort”, even langauges like Delphi are supported (or we can use it from VBA via C# I guess). * Support for many (many) languages Cons: * Implementation not native (overhead) * Not usable on embedded devices * Separate process has to be running Overall, I think it could be worth the effort, as we would create a possibility for non JVM guys to join us and play around. What do you think? Julian
