You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Julian Feinauer <j....@pragmaticminds.de> on 2020/01/02 10:03:22 UTC
Re: Generifying the field handlers?
Hi,
fully agree with both of you.
The more we generify the better (yeah, mathematician talking here...).
I think the optimal way would to have a layer or Utils module where we already provide tons of "standards" to serialize types and which is pluggable so that protocols can also add their weird implementations for specific things.
This goes in the direction of Cesars link, I think.
Julian
Am 28.12.19, 16:44 schrieb "Cesar Garcia" <ce...@ceos.com.ve>:
Hi everyone,
I think that the second option, using some type of standard definition for
"plc4x-types", may facilitate the development of protocols.
As an example the definition of Scalar types in [1].
Best regards,
1.
http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html
El sáb., 28 dic. 2019 a las 4:19, Christofer Dutz (<
christofer.dutz@c-ware.de>) escribió:
> Hi all,
>
> while porting the code to use the PlcValue objects I did notice when
> updating all existing PlcFieldHandlers that the code looks sort of almost
> the same.
> While I would say the S7FieldHandler is by far the most advanced one
> (actually checking the data has the right type and doing range checks for
> every element).
>
> How about moving most of this code to a base class?
> I did notice that an essential part of this are the internal types defined
> by every protocol. But these types might have different names, but in
> general they do have the same meaning.
>
> So how about we define an Enum with the different types and then either
> use them in the drivers or simply provide a mapping of driver types to
> plc4x-types?
>
> I know that writing the FieldHandler was something that required a lot of
> code and coding … this way we could reuse the code and simplify things
> greatly when writing new drivers?
>
> Of course will there be fields that don’t fit this schema, especially for
> KNX and BACnet, but most of the other drivers could easily reuse the code.
>
> What do you think?
>
>
> 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: 0416-681.03.99*
*Cel: 0414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automation@siemens.com
<su...@siemens.com>*
Re: Generifying the field handlers?
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Chris,
The IEC link looks like a nice set of base types which we can expect
from all major brands. As it is existing international standard in my
perception it is definitely a good candidate for separate module. :-)
Because both you and Julian and already mentioned complex types it makes
sense to bring into library support for type handling so FieldHandlers
(or their callers) would have access to more descriptive information
about what the underlying PLC structure and desired Java type is.
My complains on bitwise operations are not targeted towards any
particular piece of code nor person. If we can share them with small
cost between two drivers/protocols then I'm 99% for it.
Cheers!
On 02.01.2020 12:44, Christofer Dutz wrote:
> Hi Lukasz,
>
> I know there will not be a one-size-fits all ... but I think there is a large number of usual suspects.
> And for these I would like to implement some default code that can simply be used. So when writing a driver for a protocol, you simply re-use the ones that make sense and implement the special cases manually.
> Regarding Cesar's link. I would rather use something like this:
> https://en.wikipedia.org/wiki/IEC_61131-3
>
> The reason is, that for example in the PLC world (At least I have seen this with multiple PLC types) ... for example a "BYTE" is usually not a small integer, but an 8 bit Bit-String ... so BOOL, BYTE, WORD, DWORD refer to arrays of Booleans.
> A one-byte integer would then rather be a SINT or USINT.
>
> I also think a lot of the PLC world products refer to this spec and therefore protocols are often directly built to support these types.
>
> Chris
>
>
>
> Am 02.01.20, 12:27 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
>
> I believe that there are a couple of more things which could be placed
> there. We have same type names between different PLCs (BOOL, UINT, SINT,
> and so on), however these are distinct between modules having no common
> parent type. The AdsDataType has very little in common with S7
> TransportSize making it fairly difficult to unify some of configurations
> handling.
> More over by making type handling one of core elements we will be able to
> unify some of bit shifting mambo-jambo related to mapping byte to
> signed/unsigned variants. I know that's not the case for most JDBC drivers
> however the API and implementations there diverge a lot as they are handled
> in separate places by database vendors. Since we have a luxury of handling
> couple PLC kinds in same projects we can take benefits of (some)
> unifications.
>
> Personally I am more convinced to module which would cope with that which
> would be separate from other utils (ie. transport related). Utils types and
> module/package kinds have a tendency to gather lots of fat over time and
> degrade rather quickly. We don't have to be shy of having a module with
> one-two packages and couple of classes as twisting dependency paths is then
> much easier. If we keep it close to other utils we will make it more
> difficult. Ie. maybe now we will have driver > plc4j-types > plc4j-spi >
> plc4j-api path but later it can be easily flipped to driver > plc4j-spi >
> plc4j-types > plc4j-api.
>
> Cheers,
> Łukasz
>
>
>
>
> czw., 2 sty 2020 o 11:03 Julian Feinauer <j....@pragmaticminds.de>
> napisał(a):
>
> > Hi,
> >
> > fully agree with both of you.
> > The more we generify the better (yeah, mathematician talking here...).
> > I think the optimal way would to have a layer or Utils module where we
> > already provide tons of "standards" to serialize types and which is
> > pluggable so that protocols can also add their weird implementations for
> > specific things.
> > This goes in the direction of Cesars link, I think.
> >
> > Julian
> >
> > Am 28.12.19, 16:44 schrieb "Cesar Garcia" <ce...@ceos.com.ve>:
> >
> > Hi everyone,
> >
> > I think that the second option, using some type of standard definition
> > for
> > "plc4x-types", may facilitate the development of protocols.
> >
> > As an example the definition of Scalar types in [1].
> >
> > Best regards,
> >
> > 1.
> >
> > http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html
> >
> >
> >
> > El sáb., 28 dic. 2019 a las 4:19, Christofer Dutz (<
> > christofer.dutz@c-ware.de>) escribió:
> >
> > > Hi all,
> > >
> > > while porting the code to use the PlcValue objects I did notice when
> > > updating all existing PlcFieldHandlers that the code looks sort of
> > almost
> > > the same.
> > > While I would say the S7FieldHandler is by far the most advanced one
> > > (actually checking the data has the right type and doing range
> > checks for
> > > every element).
> > >
> > > How about moving most of this code to a base class?
> > > I did notice that an essential part of this are the internal types
> > defined
> > > by every protocol. But these types might have different names, but in
> > > general they do have the same meaning.
> > >
> > > So how about we define an Enum with the different types and then
> > either
> > > use them in the drivers or simply provide a mapping of driver types
> > to
> > > plc4x-types?
> > >
> > > I know that writing the FieldHandler was something that required a
> > lot of
> > > code and coding … this way we could reuse the code and simplify
> > things
> > > greatly when writing new drivers?
> > >
> > > Of course will there be fields that don’t fit this schema,
> > especially for
> > > KNX and BACnet, but most of the other drivers could easily reuse the
> > code.
> > >
> > > What do you think?
> > >
> > >
> > > 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: 0416-681.03.99*
> >
> > *Cel: 0414-760.98.95*
> >
> > *Hotline Técnica SIEMENS: 0800 1005080*
> >
> > *Email: support.aan.automation@siemens.com
> > <su...@siemens.com>*
> >
> >
> >
>
>
Re: Generifying the field handlers?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Lukasz,
I know there will not be a one-size-fits all ... but I think there is a large number of usual suspects.
And for these I would like to implement some default code that can simply be used. So when writing a driver for a protocol, you simply re-use the ones that make sense and implement the special cases manually.
Regarding Cesar's link. I would rather use something like this:
https://en.wikipedia.org/wiki/IEC_61131-3
The reason is, that for example in the PLC world (At least I have seen this with multiple PLC types) ... for example a "BYTE" is usually not a small integer, but an 8 bit Bit-String ... so BOOL, BYTE, WORD, DWORD refer to arrays of Booleans.
A one-byte integer would then rather be a SINT or USINT.
I also think a lot of the PLC world products refer to this spec and therefore protocols are often directly built to support these types.
Chris
Am 02.01.20, 12:27 schrieb "Łukasz Dywicki" <lu...@code-house.org>:
I believe that there are a couple of more things which could be placed
there. We have same type names between different PLCs (BOOL, UINT, SINT,
and so on), however these are distinct between modules having no common
parent type. The AdsDataType has very little in common with S7
TransportSize making it fairly difficult to unify some of configurations
handling.
More over by making type handling one of core elements we will be able to
unify some of bit shifting mambo-jambo related to mapping byte to
signed/unsigned variants. I know that's not the case for most JDBC drivers
however the API and implementations there diverge a lot as they are handled
in separate places by database vendors. Since we have a luxury of handling
couple PLC kinds in same projects we can take benefits of (some)
unifications.
Personally I am more convinced to module which would cope with that which
would be separate from other utils (ie. transport related). Utils types and
module/package kinds have a tendency to gather lots of fat over time and
degrade rather quickly. We don't have to be shy of having a module with
one-two packages and couple of classes as twisting dependency paths is then
much easier. If we keep it close to other utils we will make it more
difficult. Ie. maybe now we will have driver > plc4j-types > plc4j-spi >
plc4j-api path but later it can be easily flipped to driver > plc4j-spi >
plc4j-types > plc4j-api.
Cheers,
Łukasz
czw., 2 sty 2020 o 11:03 Julian Feinauer <j....@pragmaticminds.de>
napisał(a):
> Hi,
>
> fully agree with both of you.
> The more we generify the better (yeah, mathematician talking here...).
> I think the optimal way would to have a layer or Utils module where we
> already provide tons of "standards" to serialize types and which is
> pluggable so that protocols can also add their weird implementations for
> specific things.
> This goes in the direction of Cesars link, I think.
>
> Julian
>
> Am 28.12.19, 16:44 schrieb "Cesar Garcia" <ce...@ceos.com.ve>:
>
> Hi everyone,
>
> I think that the second option, using some type of standard definition
> for
> "plc4x-types", may facilitate the development of protocols.
>
> As an example the definition of Scalar types in [1].
>
> Best regards,
>
> 1.
>
> http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html
>
>
>
> El sáb., 28 dic. 2019 a las 4:19, Christofer Dutz (<
> christofer.dutz@c-ware.de>) escribió:
>
> > Hi all,
> >
> > while porting the code to use the PlcValue objects I did notice when
> > updating all existing PlcFieldHandlers that the code looks sort of
> almost
> > the same.
> > While I would say the S7FieldHandler is by far the most advanced one
> > (actually checking the data has the right type and doing range
> checks for
> > every element).
> >
> > How about moving most of this code to a base class?
> > I did notice that an essential part of this are the internal types
> defined
> > by every protocol. But these types might have different names, but in
> > general they do have the same meaning.
> >
> > So how about we define an Enum with the different types and then
> either
> > use them in the drivers or simply provide a mapping of driver types
> to
> > plc4x-types?
> >
> > I know that writing the FieldHandler was something that required a
> lot of
> > code and coding … this way we could reuse the code and simplify
> things
> > greatly when writing new drivers?
> >
> > Of course will there be fields that don’t fit this schema,
> especially for
> > KNX and BACnet, but most of the other drivers could easily reuse the
> code.
> >
> > What do you think?
> >
> >
> > 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: 0416-681.03.99*
>
> *Cel: 0414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automation@siemens.com
> <su...@siemens.com>*
>
>
>
Re: Generifying the field handlers?
Posted by Łukasz Dywicki <lu...@code-house.org>.
I believe that there are a couple of more things which could be placed
there. We have same type names between different PLCs (BOOL, UINT, SINT,
and so on), however these are distinct between modules having no common
parent type. The AdsDataType has very little in common with S7
TransportSize making it fairly difficult to unify some of configurations
handling.
More over by making type handling one of core elements we will be able to
unify some of bit shifting mambo-jambo related to mapping byte to
signed/unsigned variants. I know that's not the case for most JDBC drivers
however the API and implementations there diverge a lot as they are handled
in separate places by database vendors. Since we have a luxury of handling
couple PLC kinds in same projects we can take benefits of (some)
unifications.
Personally I am more convinced to module which would cope with that which
would be separate from other utils (ie. transport related). Utils types and
module/package kinds have a tendency to gather lots of fat over time and
degrade rather quickly. We don't have to be shy of having a module with
one-two packages and couple of classes as twisting dependency paths is then
much easier. If we keep it close to other utils we will make it more
difficult. Ie. maybe now we will have driver > plc4j-types > plc4j-spi >
plc4j-api path but later it can be easily flipped to driver > plc4j-spi >
plc4j-types > plc4j-api.
Cheers,
Łukasz
czw., 2 sty 2020 o 11:03 Julian Feinauer <j....@pragmaticminds.de>
napisał(a):
> Hi,
>
> fully agree with both of you.
> The more we generify the better (yeah, mathematician talking here...).
> I think the optimal way would to have a layer or Utils module where we
> already provide tons of "standards" to serialize types and which is
> pluggable so that protocols can also add their weird implementations for
> specific things.
> This goes in the direction of Cesars link, I think.
>
> Julian
>
> Am 28.12.19, 16:44 schrieb "Cesar Garcia" <ce...@ceos.com.ve>:
>
> Hi everyone,
>
> I think that the second option, using some type of standard definition
> for
> "plc4x-types", may facilitate the development of protocols.
>
> As an example the definition of Scalar types in [1].
>
> Best regards,
>
> 1.
>
> http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html
>
>
>
> El sáb., 28 dic. 2019 a las 4:19, Christofer Dutz (<
> christofer.dutz@c-ware.de>) escribió:
>
> > Hi all,
> >
> > while porting the code to use the PlcValue objects I did notice when
> > updating all existing PlcFieldHandlers that the code looks sort of
> almost
> > the same.
> > While I would say the S7FieldHandler is by far the most advanced one
> > (actually checking the data has the right type and doing range
> checks for
> > every element).
> >
> > How about moving most of this code to a base class?
> > I did notice that an essential part of this are the internal types
> defined
> > by every protocol. But these types might have different names, but in
> > general they do have the same meaning.
> >
> > So how about we define an Enum with the different types and then
> either
> > use them in the drivers or simply provide a mapping of driver types
> to
> > plc4x-types?
> >
> > I know that writing the FieldHandler was something that required a
> lot of
> > code and coding … this way we could reuse the code and simplify
> things
> > greatly when writing new drivers?
> >
> > Of course will there be fields that don’t fit this schema,
> especially for
> > KNX and BACnet, but most of the other drivers could easily reuse the
> code.
> >
> > What do you think?
> >
> >
> > 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: 0416-681.03.99*
>
> *Cel: 0414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automation@siemens.com
> <su...@siemens.com>*
>
>
>