You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Julian Feinauer <j....@pragmaticminds.de> on 2019/05/06 13:06:54 UTC

[PLC4X-113] Add Complex Types to the API

Hey,

Just started a new thread for this topic, which is basically covered under: https://issues.apache.org/jira/projects/PLC4X/issues/PLC4X-113?filter=allopenissues
There is already some discussion for that in the JIRA.

Julian

Am 06.05.19, 14:38 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:

    +1 for complex types 😊
    
    Matthias Strljic, M.Sc.
    
    Universität Stuttgart
    Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW)
    
    Seidenstraße 36
    70174 Stuttgart
    GERMANY
    
    Tel: +49 711 685-84530
    Fax: +49 711 685-74530
    
    E-Mail: matthias.strljic@isw.uni-stuttgart.de
    Web: http://www.isw.uni-stuttgart.de
    
    -----Original Message-----
    From: Julian Feinauer <j....@pragmaticminds.de> 
    Sent: Monday, May 6, 2019 2:12 PM
    To: dev@plc4x.apache.org
    Subject: Re: [DISCUSS] The State and Future of PLC4X
    
    Hi Matthias,
    
    first, +1 for OPC UA Integration (Both ways, Driver and Bridge) and another +1 for bringing it to the list : ) As I recall Chris is considering treating the OPC UA Bridge thing as a prioritized Ticket, so its really best if you get in touch.
    
    The other thing which comes along with the OPC UA Driver is that we should extend / change the API a bit to handle Complex fields more natively (or objects, so to say).
    Lukasz also had some nice ideas so perhaps we create a Confluence page for that and you, Matthias could kind of keep that in sync with your work on the Client.
    
    What do others think?
    
    Julian
    
    Am 06.05.19, 13:35 schrieb "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>:
    
        Hi Chris and Rolf, 
        
        i played yesterday a bit with Milo and PLC4X and would make a integration of Milo in the PLC4J version in this week. There u would have to excuse my noobish coding after 8 Months of only PP-Engineering. It would be first limited to the Base-Types and could be later replaced by some nice generated driver??? ❤ #GenDriverHype
        
        @Chris: The EPL of Milo is there in a binary form not a problem in PLC4X or? (https://apache.org/legal/resolved.html )
        
        As Julian earlier mentioned we also playing a bit around with an OPC UA Bridge. It progresses very slowly (just in a design stage) and perhaps we could synch there a bit 😊
        
        Greetings
        Matthias Strljic, M.Sc.
        
        Universität Stuttgart
        Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW)
        
        Seidenstraße 36
        70174 Stuttgart
        GERMANY
        
        Tel: +49 711 685-84530
        Fax: +49 711 685-74530
        
        E-Mail: matthias.strljic@isw.uni-stuttgart.de
        Web: http://www.isw.uni-stuttgart.de
        
        -----Original Message-----
        From: Christofer Dutz <ch...@c-ware.de> 
        Sent: Monday, May 6, 2019 10:25 AM
        To: dev@plc4x.apache.org; Julian Feinauer <j....@pragmaticminds.de>; Rolf Wutzke <r....@sotec.eu>
        Cc: Ralf Kölle <ra...@scitis.io>
        Subject: Re: [DISCUSS] The State and Future of PLC4X
        
        Hi Rolf,
        
        I sort of didn’t see the intermediate emails on the list, so replying to multiple ones here … as I manually had to release this one, I guess you are not all subscribed to the mailing list. Please do so by sending an email to dev-subscribe@plc4x.apache.org<ma...@plc4x.apache.org> … otherwise I will have to manually release every email you send ;)
        
        As Julian mentioned, the meetup date has been set to 24. May 2019 in our codecentric office in Franfurt.
        
        Regarding OPC-UA … I think we have to distinguish between OPC-UA Server and Client functionality. While OPC-UA Client is definitely something we have on our plan (Being able to connect to OPC-UA enabled devices), also an OPC-UA Bridge utility have been discussed (Connect an OPC-UA client to this server and in the backend this uses PLC4X to connect to non-OPC-UA devices) and its implementation might even start earlier (Will be decided in the next few days if this gets prioritized up).
        
        We already have the Specs for Profinet here at codecentric and Ethercat is also on our ToDo list. Howerver for Ethercat we haven’t got the specs yet.
        
        Currently we are working on preparing a new way of creating drivers therefore we haven’t added new protocols for quite some time. But I hope we’ll get that finished soon and be able to start mass-producing new drivers as soon as that’s done (It would have been a nightmare to implement, maintain and sync drivers in currently 4 languages, therefore we are working on a driver specification and generation tooling that will automatically keep all driver implementations in sync).
        
        Regarding OPC-UA: I think we could probably implement quite an efficient OPC-UA driver, if we limit the OPC-UA features we support. So instead of providing all the features, if we concentrate on the Data-Exchange part, I bet this could be quite efficient. But we’ll see how they perform as soon as we have them … but it wouldn’t be the first time we out-perform the insanely expensive industry solutions ;-)
        
        Chris
        
        
        
        
        Von: Rolf Wutzke <r....@sotec.eu>
        Antworten an: "dev@plc4x.apache.org" <de...@plc4x.apache.org>
        Datum: Montag, 6. Mai 2019 um 10:04
        An: Julian Feinauer <j....@pragmaticminds.de>
        Cc: "dev@plc4x.apache.org" <de...@plc4x.apache.org>, Ralf Kölle <ra...@scitis.io>
        Betreff: Re: [DISCUSS] The State and Future of PLC4X
        
        Hi Julian,
        
        thanks for adding us here.
        We are currently not working with PLC4X but the topic looks quite promissing to jump onto. At the moment we have a lot of PLX connection implementations done by our own which is ... work.
        
        Are there any news in regard to the meetup date? I put my availability in the doodle, would be really happy to discuss the topic face-2-face with the rest.
        
        Best,
        Rolf
        
        
        Am Do., 18. Apr. 2019 um 10:29 Uhr schrieb Julian Feinauer <j....@pragmaticminds.de>>:
        Hi all,
        
        Fedlbus is a good Keyword.
        Yesterday I met with Ralf Koelle and Rolf Wutzke from scitis / sotec and they were quite interested in these two.
        
        @Ralf, @Rolf: I took the freedom to take you in CC. Do you already have a working stack for these protocols?
        
        Julian
        
        Am 18.04.19, 10:14 schrieb "Bjoern Hoeper" <ho...@ltsoft.de>>:
        
            Hi erveryone,
            I agree with Markus because OPC UA is somewhat universal. If we want something open source there is a stack which is quite evolved already: https://github.com/open62541/open62541 it is maintained by a bunch of institutes (one of them is the Process Control Institute in Aachen). So we should at least think about an adapter to OPC UA. The thing we would need to prove is that we can really get faster than the vendor OPC UA server.
        
            Another thing that I think is promising and needed is adaptation to field bus systems like Profinet and EtherCAT because they provide good performance and a quite general applicability. And are at least not vendor specific.
        
            Best Regards
            Björn
        
            -----Ursprüngliche Nachricht-----
            Von: Markus Sommer <so...@isb-fn.de>>
            Gesendet: Donnerstag, 18. April 2019 09:06
            An: dev@plc4x.apache.org<ma...@plc4x.apache.org>
            Betreff: AW: [DISCUSS] The State and Future of PLC4X
        
            Hi all,
        
            I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers.
        
            Best regards
        
            Markus
        
            Freundliche Grüße
        
            Markus Sommer
            Geschäftsführer
        
            isb innovative software businesses GmbH
            Otto-Lilienthal-Strasse 2
            D - 88046 Friedrichshafen
        
            Tel.:    +49 (0) 7541 3834-14
            Mob:  +49 (0) 171 537 8437
            Fax:     +49 (0) 7541 3834-20
            E-Mail: sommer@isb-fn.de<ma...@isb-fn.de>
            Web: www.isb-fn.de<http://www.isb-fn.de>
        
            Geschäftsführer: Markus Sommer, Thomas Zeler
            Sitz: Friedrichshafen
        
            Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status.
            Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you.
        
        
            -----Ursprüngliche Nachricht-----
            Von: Julian Feinauer <j....@pragmaticminds.de>>
            Gesendet: Mittwoch, 17. April 2019 09:07
            An: dev@plc4x.apache.org<ma...@plc4x.apache.org>
            Betreff: [DISCUSS] The State and Future of PLC4X
        
            Hi all,
        
            as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit.
            I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective).
        
            Currently, I see several “fronts” or centers of activity (or where I think we should spend it).
        
              *   Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…)
              *   Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes
                 *   Model Generation (currently dfdl and state-xml)
                 *   Templates for many languages (will partially derive from above)
                 *   A build process, to wire both together
                 *   Some kind of Test Suite to check the correct generation of drivers
                 *   Automated Documentation / Spec Generation (!!
              *   Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are
                 *   Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim
                 *   OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also
                 *   We had multiple discussions about tools that “guess” something about locations of variables or their types. Chris brought that up yesterday and plans to do something there, Matthias and I discussed this several times and we plan to also do something with one or two students there
              *   New programming models – As plc4x is open, it allows us to implement new programming models on top of it. The best example I can give is OPM, the JPA equivalent of PLC4X. The idea is to work with POJOs and annotations and EntityManagers (as Beans) and have a “type safe” and Business-esque way to communicate with PLCs.
        
            Here I see a lot of potential and possible next steps could be (discussed by Matthias and me)
        
                 *   “Richer” Typesystem (not just primitives and Arrays as currently) which covers complex objects
                 *   Mapping of complex objects from POJOs to PLC segments (Like structs in S7 or ADS)
                 *   Auto-generation of annotated POJOs from PLC programs (much like JPA or the C# ORM does that based on an existing database). This could be a “killer-feature” as it would really allow type-safe end to end communication with the plc with zero plc specific knowledge
        
            Other Topics in this area that can be named are
        
                 *   A connection pool to share / reuse connections for efficiency (which was implemented by Sebastian and is absolutely crucial for us!)
                 *   A central monitoring component (similar to how a Webserver monitors each side access and the results and latencies and so..), I am currently working on this and hope to provide a PR soon
        
            Of course, all of this is solely based on my personal opinion or things that came out in discussions with other involved people.
            For me, this structure makes sense and perhaps it helps us to “broaden” our scope a bit from the initial focus (drivers, drivers, drivers) to the new picture which evolved over the last to years.
        
            Of course, feel free to agree, disagree or participate with other opinions.
        
            Julian
        
            PS.: I could offer to bring this in a more “presentable” form and prepare a short “overview” talk about this for the next meetup, if interesting
        
        
        
        --
        Rolf Wutzke | SOTEC | r.wutzke@sotec.eu<ma...@sotec.eu> | T +49 7033 5458 56 | M +49 171 286 4514
        
        
        [Inline-Bild 4]<http://sotec.engineering/>  [Inline-Bild 5] <http://xing.to/RolfWutzke>   [Inline-Bild 3] <http://www.linkedin.com/in/rolf-wutzke>   [Inline-Bild 2] <https://plus.google.com/u/0/104125007105235969242>
        
        What's next in industry & automation: https://www.sotec.eu/presenting-the-all-new-cloudplug-edge/
        
        
        www.sotec.eu<http://www.sotec.eu/>
        
        SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG
        
        Calwer Straße 11, D-75395 Ostelsheim
        
        Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, Geschäftsführer: Florian Holz