Hi Julian,
Glad we're on the same page here :-)
feel free to create such a ticket.
Chris
Am 31.07.18, 12:42 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
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
