Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Christofer Dutz]

Sounds like a good plan ...

:thumbsup:

:)

Chris

Am 14.09.20, 13:58 schrieb "Ben Hutcheson" :

Hi Chris,

If it's ok, I would feel better about splitting the FieldHandler changes
into a separate PR. It looks as though that would be a decent PR in itself
as well as probably a change to the build utils package.

For this PR I'll update the Big Integer issue and add additional PLCValue
types. As well as add documentation to the Modbus section. this should take
me about a week or so.
I should also have the extended register write code ready as well in the
next week.

Kind Regards

Ben

On Mon, Sep 14, 2020 at 5:45 AM Christofer Dutz 
wrote:

> Hi Ben,
>
> as long as we keep everything as open as possible (not tie it to Java or
> any other specific language) and it simplifies things: I'm all +1 to that.
>
> I guess you have a concrete idea ... how about you update your PR and then
> we'll merge all in one go as soon as we have your ICLA on file.
>
> Then we could even get this in for the 0.8.0 release which we will be
> doing soon.
>
> Chris
>
>
>
>
> Am 14.09.20, 11:36 schrieb "Ben Hutcheson" :
>
> Hi,
>
> Thanks for the feedback Chris, means a lot. :)
>
> Otto, I hadn't put that together that the mspec was language
> independent
> definitely makes sense. We could use the pseudo types like we do in 
the
> spec already, uint 16, int 32, etc...?
>
> Chris, the aim of having the FileHandler class automatically built was
> to
> minimize the work needed to create the encodeBoolean, encodeInteger,
> encodeFloat methods as all of these are going to have the same format,
> which works out what datatype it is and whether it is a list or not.
>
> @Override
> public PlcValue encodeInteger(PlcField field, Object[] values) {
> ModbusField modbusField = (ModbusField) field;
> switch (modbusField.getDataType()) {
> case "INT":
>   if(values.length == 1) {
>   return new PlcINT((Integer) values[0]);
>   } else {
> List plcINTValues = new LinkedList<>();
> for (int i = 0; i < values.length; i++) {
>   plcINTValues.add(new PlcINT((Integer) values[i]));
> }
> return new PlcList(plcINTValues);
>   }
> case "UINT":
>   if(values.length == 1) {
>   return new PlcUINT((Integer) values[0]);
>   } else {
>   List plcUINTValues = new LinkedList<>();
>   for (int i = 0; i < values.length; i++) {
> plcUINTValues.add(new PlcUINT((Integer)
> values[i]));
>   }
>   return new PlcList(plcUINTValues);
>   }
>  case "REAL" etc.
>
> The only difference is going to be from what language datatype we
> allow to
> be mapped to what PLCValue class. Having this in the mspec document
> something like:-
>
> [field uint 8 'ModbusFieldHandler' [array uint 8 'plcType']
> ['00' Integer ['INT', 'UINT', 'REAL']]
> ['01' Float ['REAL']]
> ['02' Short ['INT', 'UINT', 'REAL']]
>
> Another option is to make the encodeInteger type functions more
> generic,
> possibly having a single encode method that handles this but I'm not
> sure
> how we could handle that across multiple languages.
>
> I signed and sent away the ICLA just then, having PLC4X notified.
>
> Kind Regards
>
> Ben
>
>
>
> On Mon, Sep 14, 2020 at 4:36 AM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > And @Ben,
> >
> > I am not sure if you have already done that, but if you haven't it
> would
> > be cool if you could fill out, sign and send to secret...@apache.org
> your
> > ICLA.
> > Cause your PR is a little more than I would consider a minor
> contribution.
> >
> > https://www.apache.org/licenses/icla.pdf
> >
> > Chris
> >
> > Am 14.09.20, 09:53 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> > Hi Ben,
> >
> > thanks for that PR ... Just had a look at it and it looks really
> good
> > to me.
> >
> > I think this way we would simplify the whole PlcValue handling
> quite a
> > bit and we'll reduce the risk of having it right in one driver and
> wrong 

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Ben Hutcheson]

Hi Chris,

If it's ok, I would feel better about splitting the FieldHandler changes
into a separate PR. It looks as though that would be a decent PR in itself
as well as probably a change to the build utils package.

For this PR I'll update the Big Integer issue and add additional PLCValue
types. As well as add documentation to the Modbus section. this should take
me about a week or so.
I should also have the extended register write code ready as well in the
next week.

Kind Regards

Ben

On Mon, Sep 14, 2020 at 5:45 AM Christofer Dutz 
wrote:

> Hi Ben,
>
> as long as we keep everything as open as possible (not tie it to Java or
> any other specific language) and it simplifies things: I'm all +1 to that.
>
> I guess you have a concrete idea ... how about you update your PR and then
> we'll merge all in one go as soon as we have your ICLA on file.
>
> Then we could even get this in for the 0.8.0 release which we will be
> doing soon.
>
> Chris
>
>
>
>
> Am 14.09.20, 11:36 schrieb "Ben Hutcheson" :
>
> Hi,
>
> Thanks for the feedback Chris, means a lot. :)
>
> Otto, I hadn't put that together that the mspec was language
> independent
> definitely makes sense. We could use the pseudo types like we do in the
> spec already, uint 16, int 32, etc...?
>
> Chris, the aim of having the FileHandler class automatically built was
> to
> minimize the work needed to create the encodeBoolean, encodeInteger,
> encodeFloat methods as all of these are going to have the same format,
> which works out what datatype it is and whether it is a list or not.
>
> @Override
> public PlcValue encodeInteger(PlcField field, Object[] values) {
> ModbusField modbusField = (ModbusField) field;
> switch (modbusField.getDataType()) {
> case "INT":
>   if(values.length == 1) {
>   return new PlcINT((Integer) values[0]);
>   } else {
> List plcINTValues = new LinkedList<>();
> for (int i = 0; i < values.length; i++) {
>   plcINTValues.add(new PlcINT((Integer) values[i]));
> }
> return new PlcList(plcINTValues);
>   }
> case "UINT":
>   if(values.length == 1) {
>   return new PlcUINT((Integer) values[0]);
>   } else {
>   List plcUINTValues = new LinkedList<>();
>   for (int i = 0; i < values.length; i++) {
> plcUINTValues.add(new PlcUINT((Integer)
> values[i]));
>   }
>   return new PlcList(plcUINTValues);
>   }
>  case "REAL" etc.
>
> The only difference is going to be from what language datatype we
> allow to
> be mapped to what PLCValue class. Having this in the mspec document
> something like:-
>
> [field uint 8 'ModbusFieldHandler' [array uint 8 'plcType']
> ['00' Integer ['INT', 'UINT', 'REAL']]
> ['01' Float ['REAL']]
> ['02' Short ['INT', 'UINT', 'REAL']]
>
> Another option is to make the encodeInteger type functions more
> generic,
> possibly having a single encode method that handles this but I'm not
> sure
> how we could handle that across multiple languages.
>
> I signed and sent away the ICLA just then, having PLC4X notified.
>
> Kind Regards
>
> Ben
>
>
>
> On Mon, Sep 14, 2020 at 4:36 AM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > And @Ben,
> >
> > I am not sure if you have already done that, but if you haven't it
> would
> > be cool if you could fill out, sign and send to secret...@apache.org
> your
> > ICLA.
> > Cause your PR is a little more than I would consider a minor
> contribution.
> >
> > https://www.apache.org/licenses/icla.pdf
> >
> > Chris
> >
> > Am 14.09.20, 09:53 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
> >
> > Hi Ben,
> >
> > thanks for that PR ... Just had a look at it and it looks really
> good
> > to me.
> >
> > I think this way we would simplify the whole PlcValue handling
> quite a
> > bit and we'll reduce the risk of having it right in one driver and
> wrong in
> > another.
> >
> > But I have to admit that I don't quite understand your question
> about
> > the Java datatypes ... don't the PlcValues have accessors that map
> the
> > PlcValue to a given Java type? Why would we need such an extension.
> >
> > Please excuse if this is a stupid question ... I'm currently
> running
> > my brain in C-mode ...
> >
> > Chris
> >
> >
> >
> > Am 11.09.20, 23:05 schrieb "Ben Hutcheson"  >:
> >
> > Hi,
> >
> > After creating a PR for the modbus data types and moving 

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Christofer Dutz]

Hi Ben,

as long as we keep everything as open as possible (not tie it to Java or any 
other specific language) and it simplifies things: I'm all +1 to that.

I guess you have a concrete idea ... how about you update your PR and then 
we'll merge all in one go as soon as we have your ICLA on file.

Then we could even get this in for the 0.8.0 release which we will be doing 
soon.

Chris




Am 14.09.20, 11:36 schrieb "Ben Hutcheson" :

Hi,

Thanks for the feedback Chris, means a lot. :)

Otto, I hadn't put that together that the mspec was language independent
definitely makes sense. We could use the pseudo types like we do in the
spec already, uint 16, int 32, etc...?

Chris, the aim of having the FileHandler class automatically built was to
minimize the work needed to create the encodeBoolean, encodeInteger,
encodeFloat methods as all of these are going to have the same format,
which works out what datatype it is and whether it is a list or not.

@Override
public PlcValue encodeInteger(PlcField field, Object[] values) {
ModbusField modbusField = (ModbusField) field;
switch (modbusField.getDataType()) {
case "INT":
  if(values.length == 1) {
  return new PlcINT((Integer) values[0]);
  } else {
List plcINTValues = new LinkedList<>();
for (int i = 0; i < values.length; i++) {
  plcINTValues.add(new PlcINT((Integer) values[i]));
}
return new PlcList(plcINTValues);
  }
case "UINT":
  if(values.length == 1) {
  return new PlcUINT((Integer) values[0]);
  } else {
  List plcUINTValues = new LinkedList<>();
  for (int i = 0; i < values.length; i++) {
plcUINTValues.add(new PlcUINT((Integer) values[i]));
  }
  return new PlcList(plcUINTValues);
  }
 case "REAL" etc.

The only difference is going to be from what language datatype we allow to
be mapped to what PLCValue class. Having this in the mspec document
something like:-

[field uint 8 'ModbusFieldHandler' [array uint 8 'plcType']
['00' Integer ['INT', 'UINT', 'REAL']]
['01' Float ['REAL']]
['02' Short ['INT', 'UINT', 'REAL']]

Another option is to make the encodeInteger type functions more generic,
possibly having a single encode method that handles this but I'm not sure
how we could handle that across multiple languages.

I signed and sent away the ICLA just then, having PLC4X notified.

Kind Regards

Ben



On Mon, Sep 14, 2020 at 4:36 AM Christofer Dutz 
wrote:

> And @Ben,
>
> I am not sure if you have already done that, but if you haven't it would
> be cool if you could fill out, sign and send to secret...@apache.org your
> ICLA.
> Cause your PR is a little more than I would consider a minor contribution.
>
> https://www.apache.org/licenses/icla.pdf
>
> Chris
>
> Am 14.09.20, 09:53 schrieb "Christofer Dutz" :
>
> Hi Ben,
>
> thanks for that PR ... Just had a look at it and it looks really good
> to me.
>
> I think this way we would simplify the whole PlcValue handling quite a
> bit and we'll reduce the risk of having it right in one driver and wrong 
in
> another.
>
> But I have to admit that I don't quite understand your question about
> the Java datatypes ... don't the PlcValues have accessors that map the
> PlcValue to a given Java type? Why would we need such an extension.
>
> Please excuse if this is a stupid question ... I'm currently running
> my brain in C-mode ...
>
> Chris
>
>
>
> Am 11.09.20, 23:05 schrieb "Ben Hutcheson" :
>
> Hi,
>
> After creating a PR for the modbus data types and moving the
> max/min checks
> and data conversion tasks to the individual PLCValue classes, the
> ModbusFieldHandler class has been reduced to a bunch of cases
> which map a
> Java Datatype to a PLC Datatype. Looking at the S7FieldHandler
> class it
> seems to be doing the same.
>
> What are your thoughts on creating a new section within the mspec
> file to
> allow mapping Java datatypes to PlcValue types and then
> automatically
> creating the FieldHander class for each protocol? The mspec
> section would
> list all the Fields available for the protocol as well as
> datatypes e.g.
> Modbus would have the coil/discrete/input/holding/extended fields
> and map
> the Java Integer to 

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Ben Hutcheson]

Hi,

Thanks for the feedback Chris, means a lot. :)

Otto, I hadn't put that together that the mspec was language independent
definitely makes sense. We could use the pseudo types like we do in the
spec already, uint 16, int 32, etc...?

Chris, the aim of having the FileHandler class automatically built was to
minimize the work needed to create the encodeBoolean, encodeInteger,
encodeFloat methods as all of these are going to have the same format,
which works out what datatype it is and whether it is a list or not.

@Override
public PlcValue encodeInteger(PlcField field, Object[] values) {
ModbusField modbusField = (ModbusField) field;
switch (modbusField.getDataType()) {
case "INT":
  if(values.length == 1) {
  return new PlcINT((Integer) values[0]);
  } else {
List plcINTValues = new LinkedList<>();
for (int i = 0; i < values.length; i++) {
  plcINTValues.add(new PlcINT((Integer) values[i]));
}
return new PlcList(plcINTValues);
  }
case "UINT":
  if(values.length == 1) {
  return new PlcUINT((Integer) values[0]);
  } else {
  List plcUINTValues = new LinkedList<>();
  for (int i = 0; i < values.length; i++) {
plcUINTValues.add(new PlcUINT((Integer) values[i]));
  }
  return new PlcList(plcUINTValues);
  }
 case "REAL" etc.

The only difference is going to be from what language datatype we allow to
be mapped to what PLCValue class. Having this in the mspec document
something like:-

[field uint 8 'ModbusFieldHandler' [array uint 8 'plcType']
['00' Integer ['INT', 'UINT', 'REAL']]
['01' Float ['REAL']]
['02' Short ['INT', 'UINT', 'REAL']]

Another option is to make the encodeInteger type functions more generic,
possibly having a single encode method that handles this but I'm not sure
how we could handle that across multiple languages.

I signed and sent away the ICLA just then, having PLC4X notified.

Kind Regards

Ben



On Mon, Sep 14, 2020 at 4:36 AM Christofer Dutz 
wrote:

> And @Ben,
>
> I am not sure if you have already done that, but if you haven't it would
> be cool if you could fill out, sign and send to secret...@apache.org your
> ICLA.
> Cause your PR is a little more than I would consider a minor contribution.
>
> https://www.apache.org/licenses/icla.pdf
>
> Chris
>
> Am 14.09.20, 09:53 schrieb "Christofer Dutz" :
>
> Hi Ben,
>
> thanks for that PR ... Just had a look at it and it looks really good
> to me.
>
> I think this way we would simplify the whole PlcValue handling quite a
> bit and we'll reduce the risk of having it right in one driver and wrong in
> another.
>
> But I have to admit that I don't quite understand your question about
> the Java datatypes ... don't the PlcValues have accessors that map the
> PlcValue to a given Java type? Why would we need such an extension.
>
> Please excuse if this is a stupid question ... I'm currently running
> my brain in C-mode ...
>
> Chris
>
>
>
> Am 11.09.20, 23:05 schrieb "Ben Hutcheson" :
>
> Hi,
>
> After creating a PR for the modbus data types and moving the
> max/min checks
> and data conversion tasks to the individual PLCValue classes, the
> ModbusFieldHandler class has been reduced to a bunch of cases
> which map a
> Java Datatype to a PLC Datatype. Looking at the S7FieldHandler
> class it
> seems to be doing the same.
>
> What are your thoughts on creating a new section within the mspec
> file to
> allow mapping Java datatypes to PlcValue types and then
> automatically
> creating the FieldHander class for each protocol? The mspec
> section would
> list all the Fields available for the protocol as well as
> datatypes e.g.
> Modbus would have the coil/discrete/input/holding/extended fields
> and map
> the Java Integer to INT,UINT,DINT,REAL, map Floats to REAL types,
> etc..
>
> This would allow protocols to override mappings to PLCValue
> classes when
> needed as well.
>
> Kind Regards
>
> Ben
>
> On Tue, Sep 8, 2020 at 7:52 PM Ben Hutcheson 
> wrote:
>
> > Hi Chris,
> >
> > I'm not sure I follow your last email,
> >
> > I have pushed a commit to *hutcheb:Feature/ModbusDataType
> > ,
> *which
> > includes some of the changes I've proposed.
> >
> > 1) Within
> >
> build-utils/language-java/src/main/resources/templates/java/data-io-template.ftlh,
> > I've added a cast to the PLCValue so that we can use methods
> specific to
> > the PLCValue types to decode input from th PLC not just the
> 

[GitHub] [plc4x] ottlukas merged pull request #187: add initial class and test

[GitBox]

ottlukas merged pull request #187:
URL: https://github.com/apache/plc4x/pull/187


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [plc4x] chrisdutz commented on pull request #187: add initial class and test

[GitBox]

chrisdutz commented on pull request #187:
URL: https://github.com/apache/plc4x/pull/187#issuecomment-691908870


   As I have almost no Python skills, I'm not sure my review would be worth 
much ...



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Christofer Dutz]

And @Ben,

I am not sure if you have already done that, but if you haven't it would be 
cool if you could fill out, sign and send to secret...@apache.org your ICLA.
Cause your PR is a little more than I would consider a minor contribution.

https://www.apache.org/licenses/icla.pdf

Chris

Am 14.09.20, 09:53 schrieb "Christofer Dutz" :

Hi Ben,

thanks for that PR ... Just had a look at it and it looks really good to me.

I think this way we would simplify the whole PlcValue handling quite a bit 
and we'll reduce the risk of having it right in one driver and wrong in another.

But I have to admit that I don't quite understand your question about the 
Java datatypes ... don't the PlcValues have accessors that map the PlcValue to 
a given Java type? Why would we need such an extension.

Please excuse if this is a stupid question ... I'm currently running my 
brain in C-mode ... 

Chris



Am 11.09.20, 23:05 schrieb "Ben Hutcheson" :

Hi,

After creating a PR for the modbus data types and moving the max/min 
checks
and data conversion tasks to the individual PLCValue classes, the
ModbusFieldHandler class has been reduced to a bunch of cases which map 
a
Java Datatype to a PLC Datatype. Looking at the S7FieldHandler class it
seems to be doing the same.

What are your thoughts on creating a new section within the mspec file 
to
allow mapping Java datatypes to PlcValue types and then automatically
creating the FieldHander class for each protocol? The mspec section 
would
list all the Fields available for the protocol as well as datatypes e.g.
Modbus would have the coil/discrete/input/holding/extended fields and 
map
the Java Integer to INT,UINT,DINT,REAL, map Floats to REAL types, etc..

This would allow protocols to override mappings to PLCValue classes when
needed as well.

Kind Regards

Ben

On Tue, Sep 8, 2020 at 7:52 PM Ben Hutcheson  
wrote:

> Hi Chris,
>
> I'm not sure I follow your last email,
>
> I have pushed a commit to *hutcheb:Feature/ModbusDataType
> , *which
> includes some of the changes I've proposed.
>
> 1) Within
> 
build-utils/language-java/src/main/resources/templates/java/data-io-template.ftlh,
> I've added a cast to the PLCValue so that we can use methods specific 
to
> the PLCValue types to decode input from th PLC not just the methods 
defined
> in the interface.
> 2) I've added the initial framework for adding Modbus datatypes 
within the
> address string. This is able to support the INT (r/w) and UINT (w)
> datatypes when parsing a Java String (I have to clean it up and fix up
> handling of PLCList types)
> 3) I've updated the Modbus.mspec to include the INT datatype within 
the
> dataio section, I would have to add the rest of the datatypes in the 
same
> section.
> 4) I've added PlcINT and PlcUINT classes and have moved the handling 
of
> parsing different Java Datatypes into these, as well as some handling 
of
> decoding within the PlcINT classes. Along with the last point this 
allows
> us to decode the INT datatype within the DataItemIO.java file.
>
> Let me know what you think?
>
> Kind Regards
>
> Ben
>
> On Tue, Sep 8, 2020 at 11:44 AM Christofer Dutz 

> wrote:
>
>> Hi Ben,
>>
>> well the PlcValue types are based on the types used in the language 
they
>> are used in. In PLC4C, which supports signed and unsigned types, I
>> implemented them differently.
>> Initially I thought that if the PlcValues would simply have a 
byte-array
>> and a type, then it would be universal ... but I thought accessing 
the
>> values would require more cpu and memory.
>>
>> But given the fact that if we had such generic PlcValues, we could 
use
>> them in all drivers ... sort of makes them more interesting.
>>
>> We could have multiple implementations of them ... so we could have 
these
>> DefaultPlcValue implementation for the normal 61131 datatypes but 
give
>> drivers the opportunity to provide customizations for special types.
>>
>> What do you think?
>>
>> Chris
>>
>>
>>
>> Am 08.09.20, 14:44 schrieb "Ben Hutcheson" :
>>
>> Hi Chris,
>>
>> The case where PLC data types are mapped to 16 bit registers 
isn't a
>> special case, as the Modbus protocol only supports 16 bit 
registers
>> but it
>> doesn't specify what format the data should be in,any PLC 

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

[Christofer Dutz]

Hi Ben,

thanks for that PR ... Just had a look at it and it looks really good to me.

I think this way we would simplify the whole PlcValue handling quite a bit and 
we'll reduce the risk of having it right in one driver and wrong in another.

But I have to admit that I don't quite understand your question about the Java 
datatypes ... don't the PlcValues have accessors that map the PlcValue to a 
given Java type? Why would we need such an extension.

Please excuse if this is a stupid question ... I'm currently running my brain 
in C-mode ... 

Chris



Am 11.09.20, 23:05 schrieb "Ben Hutcheson" :

Hi,

After creating a PR for the modbus data types and moving the max/min checks
and data conversion tasks to the individual PLCValue classes, the
ModbusFieldHandler class has been reduced to a bunch of cases which map a
Java Datatype to a PLC Datatype. Looking at the S7FieldHandler class it
seems to be doing the same.

What are your thoughts on creating a new section within the mspec file to
allow mapping Java datatypes to PlcValue types and then automatically
creating the FieldHander class for each protocol? The mspec section would
list all the Fields available for the protocol as well as datatypes e.g.
Modbus would have the coil/discrete/input/holding/extended fields and map
the Java Integer to INT,UINT,DINT,REAL, map Floats to REAL types, etc..

This would allow protocols to override mappings to PLCValue classes when
needed as well.

Kind Regards

Ben

On Tue, Sep 8, 2020 at 7:52 PM Ben Hutcheson  wrote:

> Hi Chris,
>
> I'm not sure I follow your last email,
>
> I have pushed a commit to *hutcheb:Feature/ModbusDataType
> , *which
> includes some of the changes I've proposed.
>
> 1) Within
> 
build-utils/language-java/src/main/resources/templates/java/data-io-template.ftlh,
> I've added a cast to the PLCValue so that we can use methods specific to
> the PLCValue types to decode input from th PLC not just the methods 
defined
> in the interface.
> 2) I've added the initial framework for adding Modbus datatypes within the
> address string. This is able to support the INT (r/w) and UINT (w)
> datatypes when parsing a Java String (I have to clean it up and fix up
> handling of PLCList types)
> 3) I've updated the Modbus.mspec to include the INT datatype within the
> dataio section, I would have to add the rest of the datatypes in the same
> section.
> 4) I've added PlcINT and PlcUINT classes and have moved the handling of
> parsing different Java Datatypes into these, as well as some handling of
> decoding within the PlcINT classes. Along with the last point this allows
> us to decode the INT datatype within the DataItemIO.java file.
>
> Let me know what you think?
>
> Kind Regards
>
> Ben
>
> On Tue, Sep 8, 2020 at 11:44 AM Christofer Dutz 

> wrote:
>
>> Hi Ben,
>>
>> well the PlcValue types are based on the types used in the language they
>> are used in. In PLC4C, which supports signed and unsigned types, I
>> implemented them differently.
>> Initially I thought that if the PlcValues would simply have a byte-array
>> and a type, then it would be universal ... but I thought accessing the
>> values would require more cpu and memory.
>>
>> But given the fact that if we had such generic PlcValues, we could use
>> them in all drivers ... sort of makes them more interesting.
>>
>> We could have multiple implementations of them ... so we could have these
>> DefaultPlcValue implementation for the normal 61131 datatypes but give
>> drivers the opportunity to provide customizations for special types.
>>
>> What do you think?
>>
>> Chris
>>
>>
>>
>> Am 08.09.20, 14:44 schrieb "Ben Hutcheson" :
>>
>> Hi Chris,
>>
>> The case where PLC data types are mapped to 16 bit registers isn't a
>> special case, as the Modbus protocol only supports 16 bit registers
>> but it
>> doesn't specify what format the data should be in,any PLC data type
>> can be
>> mapped to these and then passed over Modbus. It would definitely be
>> handy
>> to be able to convert any of the PLC datatypes back from Modbus 
16-bit
>> registers to whatever datatype they should be. I've done some work
>> already
>> on the specific case of mapping a Java String to the
>> PLCInteger/PLCShort
>> classes and can expand it basing it off the S7 functions that do the
>> same.
>> We can then look at the differences and consolidate them if possible?
>>
>> However it would be great to be able to add unambiguous classes to
>> plc4j/api/src/main/java/org/apache/plc4x/java/api/value for 

[GitHub] [plc4x] chrisdutz commented on a change in pull request #186: Feature/modbus data type

[GitBox]

chrisdutz commented on a change in pull request #186:
URL: https://github.com/apache/plc4x/pull/186#discussion_r487711822



##
File path: plc4j/api/src/main/java/org/apache/plc4x/java/api/value/PlcDINT.java
##
@@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.plc4x.java.api.value;
+
+import com.fasterxml.jackson.annotation.JsonCreator;
+import com.fasterxml.jackson.annotation.JsonIgnore;
+import com.fasterxml.jackson.annotation.JsonProperty;
+import com.fasterxml.jackson.annotation.JsonTypeInfo;
+import org.apache.plc4x.java.api.exceptions.PlcIncompatibleDatatypeException;
+
+import org.apache.plc4x.java.api.value.*;
+
+import java.math.BigDecimal;
+import java.math.BigInteger;
+import java.util.LinkedList;
+import java.util.List;
+
+@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, property = "className")
+public class PlcDINT extends PlcIECValue {
+
+BigInteger minValue = BigInteger.valueOf((long) Integer.MIN_VALUE);
+BigInteger maxValue = BigInteger.valueOf((long) Integer.MAX_VALUE);

Review comment:
   Same as with PlcBOOL (And probably all others) 

##
File path: plc4j/api/src/main/java/org/apache/plc4x/java/api/value/PlcBOOL.java
##
@@ -0,0 +1,214 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.plc4x.java.api.value;
+
+import com.fasterxml.jackson.annotation.JsonCreator;
+import com.fasterxml.jackson.annotation.JsonIgnore;
+import com.fasterxml.jackson.annotation.JsonProperty;
+import com.fasterxml.jackson.annotation.JsonTypeInfo;
+import org.apache.plc4x.java.api.exceptions.PlcInvalidFieldException;
+
+import org.apache.plc4x.java.api.value.*;
+
+import java.math.BigDecimal;
+import java.math.BigInteger;
+
+@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, property = "className")
+public class PlcBOOL extends PlcIECValue {
+
+BigInteger minValue = BigInteger.valueOf(0);
+BigInteger maxValue = BigInteger.valueOf(1);

Review comment:
   Could we perhaps make these static ... A BigInteger is a pretty big type 
and creating these for every boolean PlcValue seems wasting memory and CPU time 
for cleaning up.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[DISCUSS] Doing a release of PLC4X 0.8.0 soon?

[Christofer Dutz]

Hi all,

I think in the version 0.8.0 so-far we have a huge amount of bugfixes and I 
would be happy if we would initiate the release process for this soon.

Are there any initiatives on the way that we should get into this 0.8.0? I’ll 
immediately continue the discussion on the PlcValues as soon as I’ve finished 
updating the build to the new build tools (Mainly just finishing the build).

Chris

[RESULT] [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

[Christofer Dutz]

Hi all,

so the vote passes with:

1 binding +1 and 1 non-binding +1

I'll finish the release steps and update the main repo to the new released 
version.

Chris

Am 12.09.20, 21:38 schrieb "Julian Feinauer" :

Hi,

sorry, a bit late to the party but my vote is

+1 (binding)

- Downloaded all artefacts
- checked signatures and hash code
- unzipped archive
- verified existence and content of LINCENSE, NOTICE, README and 
RELEASE_NOTES
- build from sources via "mvn clean install" under OS X 10.14.6

Julian

Am 09.09.20, 20:21 schrieb "Dominik Riemer" :

Hi,

+1 (non-binding)

[OK] Download all staged artifacts under the url specified in the 
release vote email
[OK] Verify the signature is correct and references an Apache Email 
address
[OK] Verify the SHA512 hashes
[OK] Unzip the archive
[OK] Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES 
files in the extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES 
files in the extracted source bundle.
[OK] Can build from source via "mvn clean install" under Windows 10 
(Java 8) and W10 WSL2 (Java 11)

Looks good!

Dominik

-Original Message-
From: Lukas Ott  
Sent: Wednesday, September 9, 2020 6:34 PM
To: dev@plc4x.apache.org
Subject: Re: [VOTE] Apache PLC4X Build-Tools Code-Generation 1.3.0 RC1

+1 (binding)

[OK] Download all staged artifacts under the url specified in the 
release vote email [OK] Verify the signature is correct and references an 
Apache Email address [OK] Verify the SHA512 hashes [OK] Unzip the archive [OK] 
Verify the existence of LICENSE, NOTICE, README and RELEASE_NOTES files in the 
extracted source bundle.
[OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES 
files in the extracted source bundle.

Can build from Source via "mvn install"
OS: Ubuntu 20.04.1 LTS

No further remarks.

Am Mi., 9. Sept. 2020 um 18:10 Uhr schrieb Christofer Dutz <
christofer.d...@c-ware.de>:

> +1 (binding)
>
> Chris
>
> [OK] Download all staged artifacts under the url specified in the 
> release vote email [OK] Verify the signature is correct and 
references 
> an Apache Email address [OK] Verify the SHA512 hashes [OK] Unzip the 
> archive [OK] Verify the existence of LICENSE, NOTICE, README and 
> RELEASE_NOTES files in the extracted source bundle.
> [OK] Verify the content of LICENSE, NOTICE, README and RELEASE_NOTES 
> files in the extracted source bundle.
> [OK] Run RAT externally to ensure there are no surprises.
> [OK] Search for SNAPSHOT references
> [OK] Search for Copyright references, and if they are in headers, 
make 
> sure these files containing them are mentioned in the LICENSE file.
> [MINOR] Build the project according to the Maven defaults
>
> Remarks:
>
> The script "mvnw" seems to not be executable.
>
>
>
> Am 08.09.20, 13:46 schrieb "Christofer Dutz" 
:
>
>Apache PLC4X Build-Tools Code-Generation 1.3.0 has been staged 
> under [2]
>and it’s time to vote on accepting it for release.
>
>All Maven artifacts are available under [1]. Voting will be 
> open for 72hr.
>
>A minimum of 3 binding +1 votes and more binding +1 than 
binding -1
>are required to pass.
>
>Repository:
> https://gitbox.apache.org/repos/asf/plc4x-build-tools.git
>Release tag: releases/code-generation/1.3.0
>Hash for the release tag: 
> 7f2fab83d6cd0ccba41b8622d6abe4f8995748bd
>
>Per [3] "Before voting +1 PMC members are required to download
>the signed source code package, compile it as provided, and 
test
>the resulting executable on their own platform, along with also
>verifying that the package meets the requirements of the ASF 
policy
>on releases."
>
>You can achieve the above by following [4].
>
>[ ]  +1 accept (indicate what you validated - e.g. performed 
> the non-RM items in [4])
>[ ]  -1 reject (explanation required)
>
>
> [1]
> https://repository.apache.org/content/repositories/orgapacheplc4x-1029
> [2]
> 
https://dist.apache.org/repos/dist/dev/plc4x/build-tools/code-generation/1.3.0/rc1/
> [3]
> https://www.apache.org/dev/release/validation.html#approving-a-release
> [4] https://plc4x.apache.org/developers/release/validation.html