plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Feinauer <j.feina...@pragmaticminds.de>
Subject Re: Feature prospect of project plc4x
Date Tue, 11 Sep 2018 14:41:54 GMT
Hey,

this is also what I thought about, but I would suggest to use a syntax like Apache Calcite
uses it fort he jdbc connecton [1]:

    s7://10.10.64.20/1/1;symbolicAddressFile=/some/path/to/a/file;..

Julian

[1] https://calcite.apache.org/avatica/docs/client_reference.html

´╗┐Am 11.09.18, 16:36 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:

    Hi Julian and Andreas,
    
    one way to provide such lists to a connection manually would be to have that information
in a file and to pass that in as option to the driverManager
    
    s7://10.10.64.20/1/1?symbolicAddressFile=/some/path/to/a/file
    
    The Drivers and Dirver Manager can already process such options ... these could be used
to override some defaults (Want a smaller PDU-Size, Longer-Timeouts, Specified-Freshness-Factor
for all requests, or the just mentioned address-files)
    
    Chris
    
    Am 11.09.18, 16:28 schrieb "Julian Feinauer" <j.feinauer@pragmaticminds.de>:
    
        Hi Andreas,
        
        a warm welcome also from my side!
        
        Regarding your second aspect, I agree with chris and the interface where one could
integrate arbitrary complex logic.
        
        Regarding your first aspect, I am not sure what you mean with the "hierarchical" interface.
I mean, it is surely possible to define a generic datamodel where all PLCs can be integrated
somehow but the question is how useful it will be at the end. 
        Considering S7 I agree with you that there is something missing (except you like the
raw byte arrays from DBs then SZL is sufficient).
        I spent some time looking at TIAs ap14 files to be able to extract all type information
from there (not there, yet) and I would totally agree with you to define a format where one
can extract its DB layouts from TIA which can then be read in.
        This would mainly solve the addressing Issues with S7 and give some "Symbolic" Addressing
features.
        But I agree with Chris that this should be one layer on top of the "PlcConnection"
Layer (but should be part of the project, I think).
        
        Regarding the suggestion with the event collapsing, this is something very interesting
which we also thought about. Currently we are implementing and testing a ConnectionPool for
PlcConnetions which is very useful when many threads want to communicate with very few PLCs.
As this pool gets all requests from all threads this could be used for more advanced features
like Request Pooling and Caching (just return cached results if the value is not older than
X).
        We have use cases where we want to use such a feature but we have also use cases where
we have scrape rates of some ms so we want our values as fresh as possible.
        
        I'm looking forward to hear your thoughts on this and I like that more and more "use
cases" join the discussion.
        
        Best
        Julian
        
        Am 11.09.18, 16:18 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:
        
            Hi Andreas,
            
            first of all welcome here :-)
            
            It makes me very happy to hear that you are thinking about eventually joining
forces. We can definitely use every helping hand and gladly welcome new contributors.
            
            Regarding the two aspects:
            
            I initially defined the PlcLister interface as I thought it was important. However
I had no usable information on how to implement this for the S7 devices and as no other driver
implementation had such functionality implemented, I even recently removed it in the API refactoring.
If you could help us with implementing this functionality, I would be more than happy to have
that included as it does simplify things quite a bit. Don't know if PlcLister is a good name,
but we can name it whatever seems fit.
            
            Regarding the second aspect. I am a little surprised as I have implemented exactly
the functionality of the PDU splitting. If you have a look at the S7Driver the code itself
doesn't do any splitting up. I outsourced this to the S7MessageProcessor. This was mainly
due to the fact that I knew that this optimization can become quite complex, and I wanted
to be able to exchange optimization strategies. Here the DefaultS7MessageProcessor keeps tracks
of the sizes and splits them up. When having a look at the DefaultS7MessageProcessorTest you
should see it doing its magic.
            
            In parallel I am trying to convince a good friend of mine - a mathematician specialized
on optimization problems - to contribute in this sector. Especially rewriting queries as you
suggested are on my to-do list.
            
            Right now only the S7 Driver contains such optimizations but I would really like
to come up with a strategy to generally allow a lot of these optimizations no matter what
protocol is being used. 
            
            I would consider your "reasonably fresh" optimization as something different however.
I agree it makes sense to implement something like this. However I would probably add that
as a driver independent layer within PLC4X.
            
            You can see ... we have achieved quite a bit in our first year, we're still on
it, but there's still a lot to do. So if you want to join in the team, you're more than welcome.
            
            Chris 
            
            
            
            Am 11.09.18, 15:26 schrieb "Uschold Andreas" <Andreas.Uschold@tgw-group.com>:
            
                Hi all,
                
                In early 2017 we started the development of a Java based visualization / SCADA
in the context of ware houses and logistic centers. One design goal was (and still is) to
be able to use the system in a transparent way with any kind of data source, not only PLCs,
but also network equipment, embedded systems, building technology, IT hardware and high level
IT processes (e.g. ERP). So we developed a modular platform very similar to what is available
in PLC4X now. We already implemented PlugIns for the S7 and Beckhoff AMS communication from
scratch, Allen Bradleys CIP and SNMP are next in line.
                The goals and the design of PLC4X seem to be pretty similar to ours. We want
to evaluate whether we can expect mid-term or long-term benefits by switching over to plc4x
and participate in its develoment process.
                
                Until now i identified two functional aspects plc4x doesn't seem to address
which are very important to us.
                
                The first aspect is a normalized, hierarchic, human readable namespace, just
like a table of contents for any device.
                Each variable on a PLC can be represented as a "data point" and provides information
on how to gather the real data from a data source (e.g. just a mapping to an address (s7://...)
or even more complex transformations). In case of AMS or OPC it is straight forward to read
the namespace information from a device. With S7 you still can make use of the information
provided by the SZL and offer "raw namespaces", representing I/Q/F/T/C/DB as big byte arrays
/ word arrays. Import the information from a Step7 project is also no witch craft.
                Mostly frontends benefit from this concept.
                I know about the PlcLister-Interface, but it is just empty and even the AdsTcpPlcConnection
doesn't provide an implementation. Are namespaces the way described above on the road map
or at least in scope?
                
                The second aspect is throughput optimization and request reorganization.
                Protocols like S7 and CIP have very strong restrictions on the the amount
of data which can be fetched with one telegram. If one request addresses to much information,
it should be up to the connection to split the request transparently and join the partial
responses. The current state of PLC4Js s7-driver just cuts of after 19 items in one telegram.
All surplus items are silently ignored. Thus a user must know about the limitations of the
underlying protocol and must design requests accordingly.
                On the other hand most requests are probably very small (ints, words, even
only a bit). Reading only those individually each with one call renders bandwith to nearly
zero.
                Often fetched data is adjacent to another relevant information. Requests could
be merged so effectively more data can be fetched within one telegram.
                In most of our scenarios it is not important to have the "fresh" read value,
but to have a _recent_ value. A value read up to three seconds ago is sufficient for most
our use cases, especially since most values can be considered as volatile on the PLC side.
We have a bunch of independent systems which need to gather a lot of information from one
PLC. Some information is gathered only by one system, some information by all systems. Sometimes
relevant information is accumulated in one memory area, sometimes it is fragmented over the
entire PLC.
                With a central component coordinating and optimizing all current requests,
it is possible to take the burden of taking care about through put from the user of the library,
optimize the throughput for everyone and eliminate duplicate reads from different systems
by sharing data.
                Right now i don't see any efforts regarding this in PLC4J.
                
                I would like to hear your optinions on these two aspects and whether it is
relevant for the PLC4X project.
                
                
                Best regards
                Andreas
                
                
            
            
        
        
    
    

Mime
View raw message