[BUG] Nested UDT - broken OPC item paths when bound

Hi,

Please see below issue with nested UDT and OPC Item pathing.
UDT Instance has bindings to a direct modbus register, which works perfectly fine on the root UDT instances, where all parameters are defined as integer types.

[PLC_M340]HRS{AddressOffsetDescription+BaseAddress+(DeviceNum*BlockLength-BlockLength)}:16

  # Parameter values
     AddressOffsetDescription = 0
     BaseAddress = 10000
     DeviceNum = 1
     BlockLength = 22

  # Results in the following OPC Item Path
     [PLC_M340]HRS10000:16
  # Which has a 16 character string at this address

Now, the issue is when this UDT is nested, and the same parameters provided, the OPC path has .0 added to it.

[PLC_M340]HRS{AddressOffsetDescription+BaseAddress+(DeviceNum*BlockLength-BlockLength)}:16

  # Parameter values
     AddressOffsetDescription = 0
     BaseAddress = 10000
     DeviceNum = 1
     BlockLength = 22

  # Results in the following OPC Item Path
     [PLC_M340]HRS10000.0:16
  # This OPC tag is incorrect, and invalid

The resulting OPC tag is different, given the same parameters.
I believe this issue is that the calculated number is formatted incorrectly because the solution I have for now is to format the parameter with |#00

[PLC_M340]HRS{AddressOffsetDescription+BaseAddress+(DeviceNum*BlockLength-BlockLength)|#00}:16

  # Parameter values
     AddressOffsetDescription = 0
     BaseAddress = 10000
     DeviceNum = 1
     BlockLength = 22

  # Results in the following OPC Item Path
     [PLC_M340]HRS10000:16
  # Which has a 16 character string at this address

Version
8.1.19

Thanks,

Hi Sam,

Can you check if all of the UDT parameters are of the type integer and not floating point? I’ve tried recreating this problem and it appears that floating point parameter types can cause this in the OPC item path which is expected.

Hi,

Yes I can confirm all are number parameters are stored as Integer type

Please see below example UDT definition folder.
Create an instance of a tag with type udt_test and you will get the errors I describe. I have a feeling it’s something to do with the initial values set on the nested UDT, because when I create a new udt definition I have not been able to recrate the issue, however if I create a new udt with a parameter WITHOUT a value set i.e. DeviceNum Integer ’ ’
then the issue appears. Now the UDT does not work properly, even if a value is set on the parameter

Thanks,

udt_addressing_bug.json (4.7 KB)

Did you manage to recreate the issue using my provided json?