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" <[email protected]>: 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 <[email protected]> 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" <[email protected]>: > > 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 (< > [email protected]>) 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: [email protected] > <[email protected]>* > > >
