plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: [DISCUSS] Update the way we are doing the DataIo stuff
Date Thu, 22 Oct 2020 12:12:23 GMT
Hi Lukasz,

please just have a look at the KNX dataIo for example. Here we have a wide variety of  non-standard
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?


Am 22.10.20, 12:17 schrieb "Łukasz Dywicki" <>:

    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?


    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

View raw message