Hi Lukasz, please just have a look at the KNX dataIo for example. Here we have a wide variety of non-standard datatypes, which we map to the IEC types in the dataIo part ...
Ok ... in most cases a BOOL will be encoded as a single byte which is either 0 or 1, but with the DataIo we have the opportunity to control how it's actually parsed and serialized. Does that make sense? Chris Am 22.10.20, 12:17 schrieb "Łukasz Dywicki" <[email protected]>: Just a little feedback from my end. I live idea of ValueHandler in SPI as it might support wider range of use cases than generated code and eventually become a bridge for custom Struct types which are assembled from primitives. What I currently do not get is mixed use of dataIo/PlcValues. I see a point of it but currently it is a bit of unclear to me how ValueHandler and PlcValue will cooperate. We are able to map language level types directly to bit sequences needed on device end. What purpose does PlcValue serve then with ValueHandler? Assuming that we have a PLC which does not follow IEC encoding we take a language type, call specific ValueHandler and get byte sequence to be written into pipeline. Or I get it wrong? Best, Łuasz On 22.10.2020 08:58, Christofer Dutz wrote: > Hi all, > > I think Ben already noticed it and did some great work on this. But when porting to GO I also stumbled over the same thing … our system of PLCValues and generated DataIO could possibly be simplified a bit. > For go I already put all of the IEC61131 related PlcValues in a dedicated package alongside a IEC51131ValueHandler. This ValueHandler is new component and is responsible for encoding objects of the current language into standardized IEC values. > The PlcValues each have the means to access the information in them in the different language types. However I intentionally separated the BitString types to not allow numeric access … so if you ask a PlcWORD if it’s an Int, it will say: NO. > > The general Idea would be that for example A driver generally using IEC51131 but having some additional ones, could simply wrap and use the IEC51131ValueHandler and add his own types. This would greatly reduce the amount of code needed for any driver. > You could theoretically even have multiple type schemes and build a ValueHandler wrapping multiple schemes. > > But in order to do this, I could no longer support selecting a type based on an Enum as these are not extendible (at least in Java). Using a pure numeric way to determine the type also felt bad (We would have to ensure no one ever defined a scheme using ids used by another scheme). So I tried simple strings. > > In my Go implementation I now have a String property of my PlcField elements which contain the type of a given request element and they look something like this: > > IEC61131_DWORD > IEC61131_SINT > IEC61131_DINT > IEC61131_REAL > IEC61131_TIME > > In the DataIo in the MSPecs I have to change the datatype from a numeric one to an string one. > > With these changes I think we could greatly reduce the amount of code needed for a new driver and we could remove a lot of obsolete code from the existing ones. > > > What do you think? > > Chris >
