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
> 

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 

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

[Otto Fowler]

 the MSPEC is supposed to be multi-language, so I don’t think java specific
types would go into the file definition, but there might be another way to
do something and have it generated correctly

On September 11, 2020 at 17:05:06, Ben Hutcheson (ben.hut...@gmail.com)
wrote:

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 each of
>> the IEC
>> datatypes instead of these being based off Java types.
>>
>> Using the same format as the S7 protocol the address string would be
>> holding-register:1000:REAL[10] instead though, I don't think this will
>> cause issues if we make it optional and default to INT or BOOL as
>> required.
>>
>> Kind Regards
>>
>> Ben
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz <
>> christofer.d...@c-ware.de>
>> wrote:
>>
>> > Hi Ben ...
>> >
>> > Sorry for my email... I should really finish reading before
>> replying :-(
>> >
>> > About your suggestion to add it to the type to the ModbusField ... I
>> > agree. But I would simply extend the Address string the same way
>> the TIA
>> > addresses were extended.
>> > Cause the 

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

[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 each of
>> the IEC
>> datatypes instead of these being based off Java types.
>>
>> Using the same format as the S7 protocol the address string would be
>> holding-register:1000:REAL[10] instead though, I don't think this will
>> cause issues if we make it optional and default to INT or BOOL as
>> required.
>>
>> Kind Regards
>>
>> Ben
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz <
>> christofer.d...@c-ware.de>
>> wrote:
>>
>> > Hi Ben ...
>> >
>> > Sorry for my email... I should really finish reading before
>> replying :-(
>> >
>> > About your suggestion to add it to the type to the ModbusField ... I
>> > agree. But I would simply extend the Address string the same way
>> the TIA
>> > addresses were extended.
>> > Cause the problem I'm seeing is that for the 61131 datatypes we can
>> > provide an enum, but not for any custom types the driver might be
>> > supporting. With a String 

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

[Ben Hutcheson]

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 each of
> the IEC
> datatypes instead of these being based off Java types.
>
> Using the same format as the S7 protocol the address string would be
> holding-register:1000:REAL[10] instead though, I don't think this will
> cause issues if we make it optional and default to INT or BOOL as
> required.
>
> Kind Regards
>
> Ben
>
>
>
>
>
>
>
> On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz <
> christofer.d...@c-ware.de>
> wrote:
>
> > Hi Ben ...
> >
> > Sorry for my email... I should really finish reading before replying
> :-(
> >
> > About your suggestion to add it to the type to the ModbusField ... I
> > agree. But I would simply extend the Address string the same way the
> TIA
> > addresses were extended.
> > Cause the problem I'm seeing is that for the 61131 datatypes we can
> > provide an enum, but not for any custom types the driver might be
> > supporting. With a String we can keep it simple ... check if the
> type is a
> > 61131 type -> if yes: do the default handling. If it's not, use some
> driver
> > specific encoding/decoding.
> >
> > In my particular case the Float values were also 4 byte values ... I
> > manually solved it by requesting 2 element arrays for every float
> address
> > (The map of reigsters only used only even register numbers, so that
> > worked). Then I manually converted the 2 x 2bytes into a 4byte float
> with
> > this code:
> >
> > // Decode the first 10 shorts as 32bit floats ...
> > StringBuilder sb = new StringBuilder();
> > for(int i = 0; i < 10; i++) {
> > int short1 = value.getIndex(i * 2).getInteger();
> > int short2 = value.getIndex((i * 2) +
> 1).getInteger();
> > WriteBuffer wb = new WriteBuffer(4);
> > wb.writeInt(16, short1);
> > wb.writeInt(16, short2);
> > final byte[] 

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

[Christofer Dutz]

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 each of the IEC
datatypes instead of these being based off Java types.

Using the same format as the S7 protocol the address string would be
holding-register:1000:REAL[10] instead though, I don't think this will
cause issues if we make it optional and default to INT or BOOL as required.

Kind Regards

Ben







On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz 
wrote:

> Hi Ben ...
>
> Sorry for my email... I should really finish reading before replying :-(
>
> About your suggestion to add it to the type to the ModbusField ... I
> agree. But I would simply extend the Address string the same way the TIA
> addresses were extended.
> Cause the problem I'm seeing is that for the 61131 datatypes we can
> provide an enum, but not for any custom types the driver might be
> supporting. With a String we can keep it simple ... check if the type is a
> 61131 type -> if yes: do the default handling. If it's not, use some 
driver
> specific encoding/decoding.
>
> In my particular case the Float values were also 4 byte values ... I
> manually solved it by requesting 2 element arrays for every float address
> (The map of reigsters only used only even register numbers, so that
> worked). Then I manually converted the 2 x 2bytes into a 4byte float with
> this code:
>
> // Decode the first 10 shorts as 32bit floats ...
> StringBuilder sb = new StringBuilder();
> for(int i = 0; i < 10; i++) {
> int short1 = value.getIndex(i * 2).getInteger();
> int short2 = value.getIndex((i * 2) + 1).getInteger();
> WriteBuffer wb = new WriteBuffer(4);
> wb.writeInt(16, short1);
> wb.writeInt(16, short2);
> final byte[] data = wb.getData();
> int intVal = (data[3] & 0xFF) | ((data[2] & 0xFF) << 8) |
> ((data[1] & 0xFF) << 16) | ((data[0] & 0xFF) << 24);
> final float v1 = Float.intBitsToFloat(intVal);
> sb.append(v1).append(", ");
> }
>
> Ok in this case I read 10 floats by reading an array of 20 registers.
> Guess it should be even simpler with 32bit integers
>
> But I guess it does the job ... not pretty, but it works and I would
> definitely love to have something similar in the drivers to handle this if
> I said "holding-register:1000[10]:REAL"
>
> Chris
>
>
> Am 08.09.20, 13:59 schrieb "Christofer Dutz" :
>
> Hi Ben,
>
> if you have followed the latest discussions here ... currently the
> modbus protocol supports 16bit integer values for registers and Boolean
> values for coils.
> The protocol doesn't directly support anything else. However I have
> seen that vendors use arrays of registers to support higher level types. 
In
> my special case the PLC vendor used two 16bit integers to provide 32bit
> float values.
>
> We will probably start adding support for the basic IEC 61131
> datatypes (https://en.wikipedia.org/wiki/IEC_61131-3) but I think this
> will only apply for the Bool, Bit-String, Signed and Unsigned Integers as
> well as Real values. 

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

[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 each of the IEC
datatypes instead of these being based off Java types.

Using the same format as the S7 protocol the address string would be
holding-register:1000:REAL[10] instead though, I don't think this will
cause issues if we make it optional and default to INT or BOOL as required.

Kind Regards

Ben







On Tue, Sep 8, 2020 at 8:10 AM Christofer Dutz 
wrote:

> Hi Ben ...
>
> Sorry for my email... I should really finish reading before replying :-(
>
> About your suggestion to add it to the type to the ModbusField ... I
> agree. But I would simply extend the Address string the same way the TIA
> addresses were extended.
> Cause the problem I'm seeing is that for the 61131 datatypes we can
> provide an enum, but not for any custom types the driver might be
> supporting. With a String we can keep it simple ... check if the type is a
> 61131 type -> if yes: do the default handling. If it's not, use some driver
> specific encoding/decoding.
>
> In my particular case the Float values were also 4 byte values ... I
> manually solved it by requesting 2 element arrays for every float address
> (The map of reigsters only used only even register numbers, so that
> worked). Then I manually converted the 2 x 2bytes into a 4byte float with
> this code:
>
> // Decode the first 10 shorts as 32bit floats ...
> StringBuilder sb = new StringBuilder();
> for(int i = 0; i < 10; i++) {
> int short1 = value.getIndex(i * 2).getInteger();
> int short2 = value.getIndex((i * 2) + 1).getInteger();
> WriteBuffer wb = new WriteBuffer(4);
> wb.writeInt(16, short1);
> wb.writeInt(16, short2);
> final byte[] data = wb.getData();
> int intVal = (data[3] & 0xFF) | ((data[2] & 0xFF) << 8) |
> ((data[1] & 0xFF) << 16) | ((data[0] & 0xFF) << 24);
> final float v1 = Float.intBitsToFloat(intVal);
> sb.append(v1).append(", ");
> }
>
> Ok in this case I read 10 floats by reading an array of 20 registers.
> Guess it should be even simpler with 32bit integers
>
> But I guess it does the job ... not pretty, but it works and I would
> definitely love to have something similar in the drivers to handle this if
> I said "holding-register:1000[10]:REAL"
>
> Chris
>
>
> Am 08.09.20, 13:59 schrieb "Christofer Dutz" :
>
> Hi Ben,
>
> if you have followed the latest discussions here ... currently the
> modbus protocol supports 16bit integer values for registers and Boolean
> values for coils.
> The protocol doesn't directly support anything else. However I have
> seen that vendors use arrays of registers to support higher level types. In
> my special case the PLC vendor used two 16bit integers to provide 32bit
> float values.
>
> We will probably start adding support for the basic IEC 61131
> datatypes (https://en.wikipedia.org/wiki/IEC_61131-3) but I think this
> will only apply for the Bool, Bit-String, Signed and Unsigned Integers as
> well as Real values. Durations, Times, Dates and especially Strings will be
> problematic as it seems every vendor uses a different encoding of these.
>
> Chris
>
>
> Am 08.09.20, 13:52 schrieb "Ben Hutcheson" :
>
> Hi,
>
> Looking at the example I had with the hello-world-write example
> trying to
> write a String to the Modbus protocol.
>
> ava -jar plc4j-hello-world-plc4x-write-0.8.0-SNAPSHOT-uber-jar.jar
> --connection-string modbus://127.0.0.1:5467 --field-addresses
> 40010
> -field-values 32000
>
> The value 32000 then gets cast as a String and is passed to the
> encodeString function in ModbusFieldHandler. (It doesn't have one
> it gets
> passed to the DefaultFieldHandler). To get this to work properly
> we would
> need to define a datatype to cast the String to, S7 does this
> already and
> with the consensus that IEC 61131 data types be used where
> possible then I
> see no reason we shouldn't add the datatype field to the
> ModbusField. If we
> are doing this for these protocols, then why don't we add the
> 

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

[Christofer Dutz]

Hi Ben ...

Sorry for my email... I should really finish reading before replying :-(

About your suggestion to add it to the type to the ModbusField ... I agree. But 
I would simply extend the Address string the same way the TIA addresses were 
extended. 
Cause the problem I'm seeing is that for the 61131 datatypes we can provide an 
enum, but not for any custom types the driver might be supporting. With a 
String we can keep it simple ... check if the type is a 61131 type -> if yes: 
do the default handling. If it's not, use some driver specific 
encoding/decoding.

In my particular case the Float values were also 4 byte values ... I manually 
solved it by requesting 2 element arrays for every float address (The map of 
reigsters only used only even register numbers, so that worked). Then I 
manually converted the 2 x 2bytes into a 4byte float with this code:

// Decode the first 10 shorts as 32bit floats ...
StringBuilder sb = new StringBuilder();
for(int i = 0; i < 10; i++) {
int short1 = value.getIndex(i * 2).getInteger();
int short2 = value.getIndex((i * 2) + 1).getInteger();
WriteBuffer wb = new WriteBuffer(4);
wb.writeInt(16, short1);
wb.writeInt(16, short2);
final byte[] data = wb.getData();
int intVal = (data[3] & 0xFF) | ((data[2] & 0xFF) << 8) | 
((data[1] & 0xFF) << 16) | ((data[0] & 0xFF) << 24);
final float v1 = Float.intBitsToFloat(intVal);
sb.append(v1).append(", ");
}

Ok in this case I read 10 floats by reading an array of 20 registers. Guess it 
should be even simpler with 32bit integers

But I guess it does the job ... not pretty, but it works and I would definitely 
love to have something similar in the drivers to handle this if I said 
"holding-register:1000[10]:REAL"

Chris


Am 08.09.20, 13:59 schrieb "Christofer Dutz" :

Hi Ben,

if you have followed the latest discussions here ... currently the modbus 
protocol supports 16bit integer values for registers and Boolean values for 
coils.
The protocol doesn't directly support anything else. However I have seen 
that vendors use arrays of registers to support higher level types. In my 
special case the PLC vendor used two 16bit integers to provide 32bit float 
values.

We will probably start adding support for the basic IEC 61131 datatypes 
(https://en.wikipedia.org/wiki/IEC_61131-3) but I think this will only apply 
for the Bool, Bit-String, Signed and Unsigned Integers as well as Real values. 
Durations, Times, Dates and especially Strings will be problematic as it seems 
every vendor uses a different encoding of these.

Chris


Am 08.09.20, 13:52 schrieb "Ben Hutcheson" :

Hi,

Looking at the example I had with the hello-world-write example trying 
to
write a String to the Modbus protocol.

ava -jar plc4j-hello-world-plc4x-write-0.8.0-SNAPSHOT-uber-jar.jar
--connection-string modbus://127.0.0.1:5467 --field-addresses 40010
-field-values 32000

The value 32000 then gets cast as a String and is passed to the
encodeString function in ModbusFieldHandler. (It doesn't have one it 
gets
passed to the DefaultFieldHandler). To get this to work properly we 
would
need to define a datatype to cast the String to, S7 does this already 
and
with the consensus that IEC 61131 data types be used where possible 
then I
see no reason we shouldn't add the datatype field to the ModbusField. 
If we
are doing this for these protocols, then why don't we add the datatype
field to the PLCField interface, this would allow us to use the same
default encodeString (We may have to map the protocol specific 
datatypes to
IEC 61131 here, the same internalEncodeString might be better) functions
for S7 and Modbus by casting the input to a PLCField instead of a 
S7Field
or ModbusField.

When encodeString is then called we can use the datatype that is passed 
to
it to encode it to a PLCInteger/PLCFloat/etc.., the same way the S7
protocol does it. S7 however only allows Strings to be passed as string
related variables (CHAR, WCHAR, STRING and WSTRING), I don't see any 
reason
we can't expand this to be able to pass any PLC datatype from a string.

The next problem I had was to then be able to parse the PLCInteger 
class to
a byte array within the fromPLCValue function. For the UINT datatype for
the Modbus protocol, this is a 2 byte array however the PLCInteger class
contains it as a 4 byte array. in the fromPLCValue function there 
doesn't
seem to be a way to test to see if it is an UINT or a 4 byte integer 
such
as a DINT. If we were to change the classes in
plc4j/api/src/main/java/org/apache/plc4x/java/api/value to 

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

[Christofer Dutz]

Hi Ben,

if you have followed the latest discussions here ... currently the modbus 
protocol supports 16bit integer values for registers and Boolean values for 
coils.
The protocol doesn't directly support anything else. However I have seen that 
vendors use arrays of registers to support higher level types. In my special 
case the PLC vendor used two 16bit integers to provide 32bit float values.

We will probably start adding support for the basic IEC 61131 datatypes 
(https://en.wikipedia.org/wiki/IEC_61131-3) but I think this will only apply 
for the Bool, Bit-String, Signed and Unsigned Integers as well as Real values. 
Durations, Times, Dates and especially Strings will be problematic as it seems 
every vendor uses a different encoding of these.

Chris


Am 08.09.20, 13:52 schrieb "Ben Hutcheson" :

Hi,

Looking at the example I had with the hello-world-write example trying to
write a String to the Modbus protocol.

ava -jar plc4j-hello-world-plc4x-write-0.8.0-SNAPSHOT-uber-jar.jar
--connection-string modbus://127.0.0.1:5467 --field-addresses 40010
-field-values 32000

The value 32000 then gets cast as a String and is passed to the
encodeString function in ModbusFieldHandler. (It doesn't have one it gets
passed to the DefaultFieldHandler). To get this to work properly we would
need to define a datatype to cast the String to, S7 does this already and
with the consensus that IEC 61131 data types be used where possible then I
see no reason we shouldn't add the datatype field to the ModbusField. If we
are doing this for these protocols, then why don't we add the datatype
field to the PLCField interface, this would allow us to use the same
default encodeString (We may have to map the protocol specific datatypes to
IEC 61131 here, the same internalEncodeString might be better) functions
for S7 and Modbus by casting the input to a PLCField instead of a S7Field
or ModbusField.

When encodeString is then called we can use the datatype that is passed to
it to encode it to a PLCInteger/PLCFloat/etc.., the same way the S7
protocol does it. S7 however only allows Strings to be passed as string
related variables (CHAR, WCHAR, STRING and WSTRING), I don't see any reason
we can't expand this to be able to pass any PLC datatype from a string.

The next problem I had was to then be able to parse the PLCInteger class to
a byte array within the fromPLCValue function. For the UINT datatype for
the Modbus protocol, this is a 2 byte array however the PLCInteger class
contains it as a 4 byte array. in the fromPLCValue function there doesn't
seem to be a way to test to see if it is an UINT or a 4 byte integer such
as a DINT. If we were to change the classes in
plc4j/api/src/main/java/org/apache/plc4x/java/api/value to match the IEC
61131 datatypes then we should be able to parse them correctly in Modbus
fromPLCValue function.

I have probably missed a few things out, like how the TransportSize class
for the S7 protocol works, and we may have to settle for mapping protocol
specific types to IEC61131 types in the encode functions in each protocol,
what are your thoughts?

Kind Regards

Ben




On Sun, Sep 6, 2020 at 11:25 AM Christofer Dutz 
wrote:

> Hi all,
>
> well I doubt that we could really centrally handle this.
> If you have an idea how to unify this, I'd be happy for a suggestion.
> I guess most will have to be handled in the individual drivers themselves.
>
> But I really would like all drivers to support the same base-set of
> datatypes.
>
> Chris
>
>
>
> Am 06.09.20, 17:02 schrieb "Cesar Garcia" :
>
> Hello,
>
> I think it can be applied from several points of view, the one
> typified as
> you indicate (HREGISTER: REAL) or (HREGISTER [2]), each one has its
> advantage.
>
> To be able to handle the types indifferently (specifically between
> Modbus
> and S7), I modify the field of the Modbus driver so that it strictly
> adapts
> to the PLC4X API. This prevents the user's App from having to 
implement
> code to interpret the content of the records.
>
> This is implemented in version 0.6.1 of  PLC4X, but the new version is
> something else.
>
> Best regards,
>
> El dom., 6 sept. 2020 a las 10:03, Ben Hutcheson (<
> ben.hut...@gmail.com>)
> escribió:
>
> > Hi,
> >
> > I ran into this issue this morning when using the hello-world-write
> example
> > and trying to write to a Modbus connection. It looks like it assumed
> the
> > input value is a string whereas the Modbus protocol doesn't have
> support
> > for it yet.
> >
> > I was thinking about expanding
> >
> >
> 

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

[Ben Hutcheson]

Hi,

Looking at the example I had with the hello-world-write example trying to
write a String to the Modbus protocol.

ava -jar plc4j-hello-world-plc4x-write-0.8.0-SNAPSHOT-uber-jar.jar
--connection-string modbus://127.0.0.1:5467 --field-addresses 40010
-field-values 32000

The value 32000 then gets cast as a String and is passed to the
encodeString function in ModbusFieldHandler. (It doesn't have one it gets
passed to the DefaultFieldHandler). To get this to work properly we would
need to define a datatype to cast the String to, S7 does this already and
with the consensus that IEC 61131 data types be used where possible then I
see no reason we shouldn't add the datatype field to the ModbusField. If we
are doing this for these protocols, then why don't we add the datatype
field to the PLCField interface, this would allow us to use the same
default encodeString (We may have to map the protocol specific datatypes to
IEC 61131 here, the same internalEncodeString might be better) functions
for S7 and Modbus by casting the input to a PLCField instead of a S7Field
or ModbusField.

When encodeString is then called we can use the datatype that is passed to
it to encode it to a PLCInteger/PLCFloat/etc.., the same way the S7
protocol does it. S7 however only allows Strings to be passed as string
related variables (CHAR, WCHAR, STRING and WSTRING), I don't see any reason
we can't expand this to be able to pass any PLC datatype from a string.

The next problem I had was to then be able to parse the PLCInteger class to
a byte array within the fromPLCValue function. For the UINT datatype for
the Modbus protocol, this is a 2 byte array however the PLCInteger class
contains it as a 4 byte array. in the fromPLCValue function there doesn't
seem to be a way to test to see if it is an UINT or a 4 byte integer such
as a DINT. If we were to change the classes in
plc4j/api/src/main/java/org/apache/plc4x/java/api/value to match the IEC
61131 datatypes then we should be able to parse them correctly in Modbus
fromPLCValue function.

I have probably missed a few things out, like how the TransportSize class
for the S7 protocol works, and we may have to settle for mapping protocol
specific types to IEC61131 types in the encode functions in each protocol,
what are your thoughts?

Kind Regards

Ben




On Sun, Sep 6, 2020 at 11:25 AM Christofer Dutz 
wrote:

> Hi all,
>
> well I doubt that we could really centrally handle this.
> If you have an idea how to unify this, I'd be happy for a suggestion.
> I guess most will have to be handled in the individual drivers themselves.
>
> But I really would like all drivers to support the same base-set of
> datatypes.
>
> Chris
>
>
>
> Am 06.09.20, 17:02 schrieb "Cesar Garcia" :
>
> Hello,
>
> I think it can be applied from several points of view, the one
> typified as
> you indicate (HREGISTER: REAL) or (HREGISTER [2]), each one has its
> advantage.
>
> To be able to handle the types indifferently (specifically between
> Modbus
> and S7), I modify the field of the Modbus driver so that it strictly
> adapts
> to the PLC4X API. This prevents the user's App from having to implement
> code to interpret the content of the records.
>
> This is implemented in version 0.6.1 of  PLC4X, but the new version is
> something else.
>
> Best regards,
>
> El dom., 6 sept. 2020 a las 10:03, Ben Hutcheson (<
> ben.hut...@gmail.com>)
> escribió:
>
> > Hi,
> >
> > I ran into this issue this morning when using the hello-world-write
> example
> > and trying to write to a Modbus connection. It looks like it assumed
> the
> > input value is a string whereas the Modbus protocol doesn't have
> support
> > for it yet.
> >
> > I was thinking about expanding
> >
> >
> github/plc4x/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/connection/DefaultPlcFieldHandler.java
> > to include default handlers for the various IEEE 61131 data types,
> the
> > specific protocols can then override them as necessary?
> >
> > Kind Regards
> >
> > Ben
> >
> > On Wed, Sep 2, 2020 at 9:36 AM Christofer Dutz <
> christofer.d...@c-ware.de>
> > wrote:
> >
> > > Hi Julian,
> > >
> > > I agree ... if one driver would define an "INT" as 32bit integer
> and the
> > > others would treat it as 16bit ... that could be a problem.
> > > Perhaps having a statement of the project that we use the IEC
> 61131 types
> > > as a basis and if you want to use a given protocols different
> types, that
> > > you can prefix them ..
> > >
> > > Assuming a driver for the famous "HURZ" protocol would use 32bit
> INTs,
> > > then an "INT" could reference the 16bit version and a "HURZ_INT"
> could be
> > > the 32bit version?
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > > Am 02.09.20, 15:26 schrieb "Julian Feinauer" <
> > > j.feina...@pragmaticminds.de>:
> > >
>  

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

[Christofer Dutz]

Hi all,

well I doubt that we could really centrally handle this. 
If you have an idea how to unify this, I'd be happy for a suggestion.
I guess most will have to be handled in the individual drivers themselves.

But I really would like all drivers to support the same base-set of datatypes.

Chris

 

Am 06.09.20, 17:02 schrieb "Cesar Garcia" :

Hello,

I think it can be applied from several points of view, the one typified as
you indicate (HREGISTER: REAL) or (HREGISTER [2]), each one has its
advantage.

To be able to handle the types indifferently (specifically between Modbus
and S7), I modify the field of the Modbus driver so that it strictly adapts
to the PLC4X API. This prevents the user's App from having to implement
code to interpret the content of the records.

This is implemented in version 0.6.1 of  PLC4X, but the new version is
something else.

Best regards,

El dom., 6 sept. 2020 a las 10:03, Ben Hutcheson ()
escribió:

> Hi,
>
> I ran into this issue this morning when using the hello-world-write 
example
> and trying to write to a Modbus connection. It looks like it assumed the
> input value is a string whereas the Modbus protocol doesn't have support
> for it yet.
>
> I was thinking about expanding
>
> 
github/plc4x/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/connection/DefaultPlcFieldHandler.java
> to include default handlers for the various IEEE 61131 data types, the
> specific protocols can then override them as necessary?
>
> Kind Regards
>
> Ben
>
> On Wed, Sep 2, 2020 at 9:36 AM Christofer Dutz 
> wrote:
>
> > Hi Julian,
> >
> > I agree ... if one driver would define an "INT" as 32bit integer and the
> > others would treat it as 16bit ... that could be a problem.
> > Perhaps having a statement of the project that we use the IEC 61131 
types
> > as a basis and if you want to use a given protocols different types, 
that
> > you can prefix them ..
> >
> > Assuming a driver for the famous "HURZ" protocol would use 32bit INTs,
> > then an "INT" could reference the 16bit version and a "HURZ_INT" could 
be
> > the 32bit version?
> >
> > Chris
> >
> >
> >
> >
> > Am 02.09.20, 15:26 schrieb "Julian Feinauer" <
> > j.feina...@pragmaticminds.de>:
> >
> > Hi,
> >
> > agree with your suggestion!
> > Although we have to be careful to not mix it up with specific
> > implementations of datatypes in some drivers.
> >
> > Julian
> >
> > Am 02.09.20, 15:21 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> >
> > Hi all,
> >
> > today I was at a customer’s site and used the Modbus driver to
> get
> > data. This generally worked fine.
> > The thing however I found a little complicated, was that the PLC
> > seemed to offer all values as 32Bit Floating point values.
> > So in order to correctly read them, I had to read an array of 
two
> > consecutive shorts and then manually convert them into a float.
> >
> > I bet we can do this better.
> >
> > So I thought … how about we use the same
> > https://en.wikipedia.org/wiki/IEC_61131-3 datatypes we are already using
> > in other drivers and for example if you write:
> >
> > holding-register:1:REAL
> >
> > it would automatically use modbus to read an array of two shorts
> > and to internally convert these to one REAL/float.
> >
> > What do you think? I think we could probably do this in most
> > drivers.
> >
> > Chris
> >
> >
> >
> >
> >
>


-- 
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

*Email: support.aan.automat...@siemens.com
*

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

[Cesar Garcia]

Hello,

I think it can be applied from several points of view, the one typified as
you indicate (HREGISTER: REAL) or (HREGISTER [2]), each one has its
advantage.

To be able to handle the types indifferently (specifically between Modbus
and S7), I modify the field of the Modbus driver so that it strictly adapts
to the PLC4X API. This prevents the user's App from having to implement
code to interpret the content of the records.

This is implemented in version 0.6.1 of  PLC4X, but the new version is
something else.

Best regards,

El dom., 6 sept. 2020 a las 10:03, Ben Hutcheson ()
escribió:

> Hi,
>
> I ran into this issue this morning when using the hello-world-write example
> and trying to write to a Modbus connection. It looks like it assumed the
> input value is a string whereas the Modbus protocol doesn't have support
> for it yet.
>
> I was thinking about expanding
>
> github/plc4x/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/connection/DefaultPlcFieldHandler.java
> to include default handlers for the various IEEE 61131 data types, the
> specific protocols can then override them as necessary?
>
> Kind Regards
>
> Ben
>
> On Wed, Sep 2, 2020 at 9:36 AM Christofer Dutz 
> wrote:
>
> > Hi Julian,
> >
> > I agree ... if one driver would define an "INT" as 32bit integer and the
> > others would treat it as 16bit ... that could be a problem.
> > Perhaps having a statement of the project that we use the IEC 61131 types
> > as a basis and if you want to use a given protocols different types, that
> > you can prefix them ..
> >
> > Assuming a driver for the famous "HURZ" protocol would use 32bit INTs,
> > then an "INT" could reference the 16bit version and a "HURZ_INT" could be
> > the 32bit version?
> >
> > Chris
> >
> >
> >
> >
> > Am 02.09.20, 15:26 schrieb "Julian Feinauer" <
> > j.feina...@pragmaticminds.de>:
> >
> > Hi,
> >
> > agree with your suggestion!
> > Although we have to be careful to not mix it up with specific
> > implementations of datatypes in some drivers.
> >
> > Julian
> >
> > Am 02.09.20, 15:21 schrieb "Christofer Dutz" <
> > christofer.d...@c-ware.de>:
> >
> > Hi all,
> >
> > today I was at a customer’s site and used the Modbus driver to
> get
> > data. This generally worked fine.
> > The thing however I found a little complicated, was that the PLC
> > seemed to offer all values as 32Bit Floating point values.
> > So in order to correctly read them, I had to read an array of two
> > consecutive shorts and then manually convert them into a float.
> >
> > I bet we can do this better.
> >
> > So I thought … how about we use the same
> > https://en.wikipedia.org/wiki/IEC_61131-3 datatypes we are already using
> > in other drivers and for example if you write:
> >
> > holding-register:1:REAL
> >
> > it would automatically use modbus to read an array of two shorts
> > and to internally convert these to one REAL/float.
> >
> > What do you think? I think we could probably do this in most
> > drivers.
> >
> > Chris
> >
> >
> >
> >
> >
>


-- 
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*

*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*

*Cel: +58 414-760.98.95*

*Hotline Técnica SIEMENS: 0800 1005080*

*Email: support.aan.automat...@siemens.com
*

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

[Ben Hutcheson]

Hi,

I ran into this issue this morning when using the hello-world-write example
and trying to write to a Modbus connection. It looks like it assumed the
input value is a string whereas the Modbus protocol doesn't have support
for it yet.

I was thinking about expanding
github/plc4x/plc4j/spi/src/main/java/org/apache/plc4x/java/spi/connection/DefaultPlcFieldHandler.java
to include default handlers for the various IEEE 61131 data types, the
specific protocols can then override them as necessary?

Kind Regards

Ben

On Wed, Sep 2, 2020 at 9:36 AM Christofer Dutz 
wrote:

> Hi Julian,
>
> I agree ... if one driver would define an "INT" as 32bit integer and the
> others would treat it as 16bit ... that could be a problem.
> Perhaps having a statement of the project that we use the IEC 61131 types
> as a basis and if you want to use a given protocols different types, that
> you can prefix them ..
>
> Assuming a driver for the famous "HURZ" protocol would use 32bit INTs,
> then an "INT" could reference the 16bit version and a "HURZ_INT" could be
> the 32bit version?
>
> Chris
>
>
>
>
> Am 02.09.20, 15:26 schrieb "Julian Feinauer" <
> j.feina...@pragmaticminds.de>:
>
> Hi,
>
> agree with your suggestion!
> Although we have to be careful to not mix it up with specific
> implementations of datatypes in some drivers.
>
> Julian
>
> Am 02.09.20, 15:21 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
>
> Hi all,
>
> today I was at a customer’s site and used the Modbus driver to get
> data. This generally worked fine.
> The thing however I found a little complicated, was that the PLC
> seemed to offer all values as 32Bit Floating point values.
> So in order to correctly read them, I had to read an array of two
> consecutive shorts and then manually convert them into a float.
>
> I bet we can do this better.
>
> So I thought … how about we use the same
> https://en.wikipedia.org/wiki/IEC_61131-3 datatypes we are already using
> in other drivers and for example if you write:
>
> holding-register:1:REAL
>
> it would automatically use modbus to read an array of two shorts
> and to internally convert these to one REAL/float.
>
> What do you think? I think we could probably do this in most
> drivers.
>
> Chris
>
>
>
>
>

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

[Christofer Dutz]

Hi Julian,

I agree ... if one driver would define an "INT" as 32bit integer and the others 
would treat it as 16bit ... that could be a problem.
Perhaps having a statement of the project that we use the IEC 61131 types as a 
basis and if you want to use a given protocols different types, that you can 
prefix them .. 

Assuming a driver for the famous "HURZ" protocol would use 32bit INTs, then an 
"INT" could reference the 16bit version and a "HURZ_INT" could be the 32bit 
version?

Chris




Am 02.09.20, 15:26 schrieb "Julian Feinauer" :

Hi,

agree with your suggestion!
Although we have to be careful to not mix it up with specific 
implementations of datatypes in some drivers.

Julian

Am 02.09.20, 15:21 schrieb "Christofer Dutz" :

Hi all,

today I was at a customer’s site and used the Modbus driver to get 
data. This generally worked fine.
The thing however I found a little complicated, was that the PLC seemed 
to offer all values as 32Bit Floating point values.
So in order to correctly read them, I had to read an array of two 
consecutive shorts and then manually convert them into a float.

I bet we can do this better.

So I thought … how about we use the same 
https://en.wikipedia.org/wiki/IEC_61131-3 datatypes we are already using in 
other drivers and for example if you write:

holding-register:1:REAL

it would automatically use modbus to read an array of two shorts and to 
internally convert these to one REAL/float.

What do you think? I think we could probably do this in most drivers.

Chris

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

[Julian Feinauer]

Hi,

agree with your suggestion!
Although we have to be careful to not mix it up with specific implementations 
of datatypes in some drivers.

Julian

Am 02.09.20, 15:21 schrieb "Christofer Dutz" :

Hi all,

today I was at a customer’s site and used the Modbus driver to get data. 
This generally worked fine.
The thing however I found a little complicated, was that the PLC seemed to 
offer all values as 32Bit Floating point values.
So in order to correctly read them, I had to read an array of two 
consecutive shorts and then manually convert them into a float.

I bet we can do this better.

So I thought … how about we use the same 
https://en.wikipedia.org/wiki/IEC_61131-3 datatypes we are already using in 
other drivers and for example if you write:

holding-register:1:REAL

it would automatically use modbus to read an array of two shorts and to 
internally convert these to one REAL/float.

What do you think? I think we could probably do this in most drivers.

Chris