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
