Hello Chris,
I can contradict your point of view a bit. Strong relying on type
information might be a dead end, because we will never be able to cover
all cases specific hardware vendor have.
Some of ADS devices do not have symbol table (i.e. plain I/O islands),
therefore hard assumptions on type information can simply broke the ADS
driver. I believe that possibility to specify tag type should remain
possible. First to let driver avoid round trips, second make an option
to shift management of this to user program, if he is willing to take
that part.
All of our address can be aligned to either:
$adrType:$path:$dataType{$config}
$adrType:$path[$arrayInfo]:$dataType{$config}
Config is optional, currently not all drivers use it (the key-value
pairs), we have it in case of modbus and hopefully soon with opc-ua.
Best,
Łukasz
On 2.10.2024 16:14, Christofer Dutz wrote:
Hi all,
I have recently been working on fine-tuning some of our API parts related to
tag parsing, value validation etc.
Next on my list is the correct handling of array types. I think in most of our
drivers we have paid only little attention to these in the past.
Now for most protocols, we need to define the type in the address string, as
there’s no way to know how to interpret the type.
That’s why we currently have this convention:
"{some-address}:{data-type}[{array-information}]"
However, there are some where this information is provided by the protocol …
such as ADS and most probably Logix etc. The more drivers we create with browse
support, the more this will be.
In that case we shouldn’t let the users provide the datatype and simply use the
one coming from the PLC as that’s more probably going to be right.
Now if we omit the datatype from these addresses, then we would sort of break
our usual convention.
I would therefore propose to change the order to this:
"{some-address}[{array-information}]:{data-type}"
What do you think?
As always … If I don’t hear anything otherwise for the next few days I’ll
simply change it.
Chris
