plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [DISCUSS] The State and Future of PLC4X
Date Wed, 17 Apr 2019 07:54:53 GMT
Hi Julian and all others ...

I would like to add another thing:
It would be great if we could also provide something I would call "Agents". Currently PLC4X
support talking to PLCs in a protocol they already support. Yesterday I had a chat with guys
from Phoenix Contact which also have an AppStore-like system, where customers can install
modules to the PLCs. These modules can have full access to the PLCs shared memory. I would
like to try out creating a native C++ based App for the PLCNext PLCs which communicates via
Thrift to send "native PLC4X" requests over the wire. The counterpart on the client side would
be a "plc4x" driver ... I would also like to call that protocol "plc4x", "agent" or "plc4x-agent".
All sorts of PLC4X agents would use the same driver as client. 

At least I know the Codesys PLCs also support this installation of modules, however I think
there are windows and Linux versions ... so a little more difficult.

Here I guess we could get the maximum performance and the maximum integration into PLC4X.

Chris




Am 17.04.19, 09:06 schrieb "Julian Feinauer" <j.feinauer@pragmaticminds.de>:

    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
    

Mime
View raw message