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
