plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: [DISCUSS] Update the way we are doing the DataIo stuff
Date Thu, 22 Oct 2020 10:17:46 GMT
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
> 

Mime
View raw message