You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Julian Feinauer <j....@pragmaticminds.de> on 2018/07/29 11:37:09 UTC
Datatypes in Plc4j
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
Re: Datatypes in Plc4j
Posted by Christofer Dutz <ch...@c-ware.de>.
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....@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" <ch...@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....@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
Re: Datatypes in Plc4j
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Sorry for the typo, I actually meant Julian (I blame the MBP 13’’ keyboard for that ;)
> Am 02.08.2018 um 09:54 schrieb Sebastian Rühl <se...@googlemail.com>:
>
> Hi Julia,
Re: Datatypes in Plc4j
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Hi Julia,
+1 for a JPA style on top addition on plc4x .
In addition to the comments from Chris:
We had a discussion on this topic a while ago here https://lists.apache.org/thread.html/dfca30f6c3319e592c4a6412924edc9a31f2e18844204dc373eebc5d@%3Cdev.plc4x.apache.org%3E <https://lists.apache.org/thread.html/dfca30f6c3319e592c4a6412924edc9a31f2e18844204dc373eebc5d@%3Cdev.plc4x.apache.org%3E>
Sebastian
PS: FYI: here is a good search point (mailinglist web search) in case you didn’t knew: https://lists.apache.org/list.html?dev@plc4x.apache.org:lte=1y:jpa <https://lists.apache.org/list.html?dev@plc4x.apache.org:lte=1y:jpa> :)
> Am 31.07.2018 um 12:42 schrieb Julian Feinauer <j....@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" <ch...@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....@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
>
>
>
>
>
>
>
>
>
>
>
>
Re: Datatypes in Plc4j
Posted by Julian Feinauer <j....@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" <ch...@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....@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
Re: Datatypes in Plc4j
Posted by Christofer Dutz <ch...@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....@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