TheWaterboy
Lifetime Supporting Member + Moderator
This is more of a rant than a dire problem, but stuff like this bugs me.
I have a UDT with a 64 element Bool Array as one of the structures. I have not dealt with a bool array that large before and I find that in the Proficy iFix software, using Kepware IGS as the driver, I can address elements 0-31 using the syntax Channel.Device.Tagname.X.
However when I address Elements 32 and beyond I have to use the syntax Channel.Device.Tagname[XX]@Boolean. It's notable that this syntax works for the first 32 Elements as well.
Using Kepware OPC QuickClient I can see that Kepware itself is perfectly happy using the bracket syntax without the @boolean suffix for the entire range, but not happy using the "dot" syntax at all.
So my conclusion thus far is that when the .XX syntax gets parsed by "it", "it" is interpreted as a word.bit datatype and thus would have a 32 bit limitation. But when parsed using the bracket syntax "it" assumes a Float datatype (the Kepware default for this device) and the @Boolean suffix overrides that assumption. All of that makes sense.
My question becomes ... what is "it"? Is this a Proficy platform limitation or is it a Kepware limitation? It would be more consistent and cleaner to just interpret the "dot" syntax as being an element of whatever preceded it instead have having to add a suffix to the tagname to override it when you exceed the 31st element. I'm curious why that is not the case and which part of this interaction is to blame.
Anybody know?
I have a UDT with a 64 element Bool Array as one of the structures. I have not dealt with a bool array that large before and I find that in the Proficy iFix software, using Kepware IGS as the driver, I can address elements 0-31 using the syntax Channel.Device.Tagname.X.
However when I address Elements 32 and beyond I have to use the syntax Channel.Device.Tagname[XX]@Boolean. It's notable that this syntax works for the first 32 Elements as well.
Using Kepware OPC QuickClient I can see that Kepware itself is perfectly happy using the bracket syntax without the @boolean suffix for the entire range, but not happy using the "dot" syntax at all.
So my conclusion thus far is that when the .XX syntax gets parsed by "it", "it" is interpreted as a word.bit datatype and thus would have a 32 bit limitation. But when parsed using the bracket syntax "it" assumes a Float datatype (the Kepware default for this device) and the @Boolean suffix overrides that assumption. All of that makes sense.
My question becomes ... what is "it"? Is this a Proficy platform limitation or is it a Kepware limitation? It would be more consistent and cleaner to just interpret the "dot" syntax as being an element of whatever preceded it instead have having to add a suffix to the tagname to override it when you exceed the 31st element. I'm curious why that is not the case and which part of this interaction is to blame.
Anybody know?