plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject [DISCUSS] Update the way we are doing the DataIo stuff
Date Thu, 22 Oct 2020 06:58:59 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message