Hey Chris,
The IEC link looks like a nice set of base types which we can expect
from all major brands. As it is existing international standard in my
perception it is definitely a good candidate for separate module. :-)
Because both you and Julian and already mentioned complex types it makes
sense
I believe that there are a couple of more things which could be placed
there. We have same type names between different PLCs (BOOL, UINT, SINT,
and so on), however these are distinct between modules having no common
parent type. The AdsDataType has very little in common with S7
TransportSize
Hi everyone,
I think that the second option, using some type of standard definition for
"plc4x-types", may facilitate the development of protocols.
As an example the definition of Scalar types in [1].
Best regards,
1.
Just had a second look,
So it seems for all the bit, bit-string, (unsigned) integer and (unsigned)
float values this would make sense ... with the string, character, date, time
and time-date fields I guess every implementation will have to come up with a
mapping, however I doubt that for these
Hi all,
while porting the code to use the PlcValue objects I did notice when updating
all existing PlcFieldHandlers that the code looks sort of almost the same.
While I would say the S7FieldHandler is by far the most advanced one (actually
checking the data has the right type and doing range
