Hi Andreas, thanks for reporting that issue ... I just resolved it. The problem was that bit datatypes (BOOL, BYTE, WORD, ...) Seem to add an additional 0-byte after each item. I updated that and now I no longer got the errors you reported.
Please re-check ... but in my test PLC4X47Test (in the api-refactoring branch) the result was as expected. Now I have to find out why my S7 1200 tells me SINT is an unsupported datatype ... (A new API level error code, I just added) Chris Am 11.09.18, 17:40 schrieb "Uschold Andreas" <[email protected]>: Hi Chris and Julian, I'm glad to hear that pooling and caching are not out of scope. This topic is pretty complex and one of our most disruptive obstacles. Regarding fragmentation of too big ReadRequests I didn't dig too deep through the source. Instead I did some simple test, just reading the first byte of 30 different data blocks. I filed two issues, PLC4X-47 and PLC4X-48 (a NPE thrown when parsing the read response when multiple items are included in one ReadRequest). May be the second issue is the cause of the first one. With hierarchic namespaces I simply mean structured, nestable container with a unique and qualifying name for data points. Since S7 does not provide a lot of information via the S7 protocol about this aspect, this feature is not very powerful. OPC on the other hand makes heavy use of this concept. Our product is used by people with a minor technical background. If we can offer a UI which provides all the data points available in a human understandable way, we provide a valuable assistance to our users and enable them to work without the need to inspect the PLC software to find out where which information is located. A very basic approach might even be to just plain SEQ files with symbolic information. I agree that a namespace feature has nothing to do with the native communication and should be realized in a superordinate layer. Best regards Andreas -----Ursprüngliche Nachricht----- 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" <[email protected]>: 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" <[email protected]>: 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" <[email protected]>: 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" <[email protected]>: 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
