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
