Hey Chris,
I get your point regarding reading "basic" types and I agree.
And the idea with the mapping I had was indeed meant not directly on the plc
level but as you outlined one level above where plc4j takes care of generating
a suitable set of requests and assembles the struct for the result.
The description for the result structure should be given with plc4j addresses
and then everything would stay the same for the requests.
Should I create a Ticket for this or do you want to?
Then we can conserve our discussion there until someone really plans to
implement this.
Best Julian
Am 30.07.18, 13:46 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Julian,
Well the reason for this was to allow explicit generic handling of the
responses.
There had been quite a lot of refactoring regarding this in the early times
of PLC4X.
I do agree that it limits the extensibility but I remember in the beginning
we even had hard coded types so there were IntegerReadRequests and
LongWriteRequests.
The idea behind this was to be able to have explicit control over the set
of types used. We loosened things a little by using generics.
The main idea behind this is, that in Java we use different datatypes as in
the different types of PLCs. Therefore we are expecting each driver to be able
to map certain Java types to the ones used in that particular protocol. It
makes things a lot more complicated when allowing complex types, because every
driver then has to know how to deal with this. In the end I was afraid to have
PLC4X support some features on one driver and others on another. After all I
haven't come across a single protocol, that natively supports Lists for
example. Usually Arrays is the only thing supported. I know that OPC-UA seems
to support datastructures as well as Beckhoff ADS (I think). So how could you
change your code from Beckhoff to Siemens for example?
Even if no work has been done on this yet, I was always thinking of having
some sort of mechanism on top of PLC4X that supports Datastructures and acts
similar to how JPA does on top of JDBC. These mechanisms - which could be part
of the PLC4X project - could for example map POJOs into Request with multiple
items and handle the marshalling and unmarshalling transparently. Eventually
PLC4X could also allow skipping the marshalling and unmarshalling, if the
corresponding protocol supports complex datatypes.
What do you think?
Chris
Am 29.07.18, 13:37 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Hi all,
After going through the code I have one question about the “Typesystem”.
From what I see, currently the java class(-name) is used as type
parameter.
Is there a specific reason for this?
I am asking because this limits, in my eyes, the extensibility of the
typesystem massively, e.g., for defining nullability or later on extending the
typesystem to lists, arrays, maps or structs.
A concrete use case would be to map a struct, e.g., in a S7 program
directly to a struct with a shema definition given, e.g., in avro or json.
I think this could be a pretty cool use case later on, especially when
communication with PLCs becomes more common and TIA programmers start to
incorporates special structs for communication.
My suggestion would be to use a typesystem, e.g., similar to the one
used in Apache Calcite
(https://calcite.apache.org/apidocs/org/apache/calcite/rel/type/RelDataType.html
) and to add a static util class to convert between Java Classes and internal
types to keep the public API’s “as is”.
What do you think of this suggestion or what drawbacks do you see?
Best
Julian
