You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2021/03/04 09:35:57 UTC
[DISCUSS] Introduce a "RawPlcValue" in the API?
Hi all,
In PLC4X we have PLCValues ... mostly we default to sort of a raw byte-array PlcValue if no type information is provided.
Now in Go we have the problem, that we can only access types in the api (As if in the Java version we could only access the types in the plc4j-api module)
This is a problem for me in PLC4Go ... as I'm for example getting incoming events from the KNX bus without any type information so I'm getting byte arrays. The application knows the types a given GroupAddressValue should have. Unfortunately, I can't access the ReadBuffer and the DataIo types as these are internal.
So instead of making them public (which I would consider a really bad practice), I was thinking if we should provicd a new "RawPlcValue" PlcValueType for exactly these cases.
It would be a normal Byte-Array PLCValue but also have some additional methods/functions provided by the driver which allow parsing the raw content as a given datatype (provided as string argument).
What do you think?
Chris
Re: [DISCUSS] Introduce a "RawPlcValue" in the API?
Posted by Otto Fowler <ot...@gmail.com>.
Is there no way to restructure the go project to fix the issue, instead of introducing a new api concept?
> On Mar 4, 2021, at 04:35, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi all,
>
> In PLC4X we have PLCValues ... mostly we default to sort of a raw byte-array PlcValue if no type information is provided.
> Now in Go we have the problem, that we can only access types in the api (As if in the Java version we could only access the types in the plc4j-api module)
>
> This is a problem for me in PLC4Go ... as I'm for example getting incoming events from the KNX bus without any type information so I'm getting byte arrays. The application knows the types a given GroupAddressValue should have. Unfortunately, I can't access the ReadBuffer and the DataIo types as these are internal.
> So instead of making them public (which I would consider a really bad practice), I was thinking if we should provicd a new "RawPlcValue" PlcValueType for exactly these cases.
> It would be a normal Byte-Array PLCValue but also have some additional methods/functions provided by the driver which allow parsing the raw content as a given datatype (provided as string argument).
>
> What do you think?
>
> Chris