Hello Chris, The application of IEC61131-3 for PLC manufacturers has always been a history of "what I have and do not want to change" with respect to "what should be".
The best example is my dear Simatic, which Siemens says complies with IEC61131-3 [1], but when you go to reality it doesn't look anything like it. that's why there are brave hearts like Oscat function libraries [2] that try to even things out, but that's another story. We should follow a bit the new neighbors in the neighborhood, like PLCNext [3], and indicate our degree of compatibility. My proposal for this case would be to ensure that our libraries are at least compatible with the recommendations of IEC61131-3-2013, shown in* "Figure 11 – Data type conversion rules – implicit and/or explicit (Summary)"*. For example, implement an abstract object type PlcValue, which already implements the conversion on the received buffer from the PLC and which triggers an exception if the conversion cannot be carried out. In the case of Netty's ByteBuf [4] it does this transparently. With this we can give the users of the libraries, the implicit and implicit conversion in a transparent way. My grain of sand [1] https://cache.industry.siemens.com/dl/files/748/109476748/att_845621/v1/IEC_61131_compliance_en_US.pdf [2] http://www.oscat.de/ [3] https://www.plcnext.help/te/PLCnext_RuntimeAvailable_data_types.htm [4] https://netty.io/4.1/api/io/netty/buffer/ByteBuf.html El dom, 29 may 2022 a las 10:48, Christofer Dutz (<christofer.d...@c-ware.de>) escribió: > Hi all, > > today again I'm wasting lots of time trying to align the way we are > handling bit strings :-( > > According to IEC61131 the types: BYTE, WORD, DWORD and LWORD are bit > strings ... therefore series of bits. > However, many people treat BYTE as a numeric value. > That's actually what USINT (Unsigned small int) and SINT (small int) are > for. > BYTE doesn't specify if signed or unsigned. In Java for example it would > be signed, in go and C it would be unsigned. > > Now we did extend the BYTE, WORD, DWORD and LWORD with a getBooleanArray() > method, however this doesn't really work nicely, as it's not part of the > API and you explicitly have to cast it to PlcBYTE etc. in order to use it. > And a PlcBYTE is not a list type. In parallel I did have the PlcBitString > type, which was a List type and correctly handled the bit-stringyness. > > So, I would like to discuss with you all, how we are going to deal with > these in the future and then do a VOTE on that and stick with it. > > My opinion is, that BYTE, WORD, DWORD and LWORD should be bit-strings and > hereby Lists of Boolean values. If someone wants to read the numeric values > on the PlcValues by using the getXYZ methods, they should fire exceptions > telling the user that this is a BitString and if he wants to use a numeric > value, he should use the numeric counterpart (and tell him which options > there are: Like USINT for unsigned 8 bit, SINT for 8 bit signed instead of > BYTE, ...). > > This mixing up of types is making it a nightmare to consistently maintain > over multiple languages. > > What's your opinion on this? > > 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 <support.aan.automat...@siemens.com>*
