I would like to communicate with my PLC via Modbus TCP. As I will have several variables, to optimize and facilitate, I thought about using UDTs.
However, I encountered some difficulties:
1- I am totally dependent on my address. When I register it on the gateway, I cannot prevent it from appearing at the end, which defeats the purpose of using a UDT. If I have another PLC, I cannot reuse the UDT tags and need another UDT.
If I change the address, I will have to change it in the PLC, the gateway, and the UDT. If it were passed at the end by parameter {pump1}, I would use a single UDT, always associated with pump 1 or pump 2, not the address. For the same reason, I did this in my MQTT UDT.
Ex:
2 - Looking at the forum, I found two ways to do it, but I don't know which one is best. Whether it's creating it through the gateway or creating it directly in the tag. Even so, it comes back to the UDT issue, which I'm lost on.
and creating through the gateway, I couldn't read two consecutive addresses ;-;
I would create your base UDT and then create a UDT that uses it as the parent datatype. You could add a parameter for each OPC item path address on the child UDT. The structure of the UDTs would then remain the same and could use the same templates/views.
When connecting to Modbus devices, it's generally recommended to avoid using the Modbus mapping in the driver configuration. Instead, use the manual addressing approach in Ignition documented here:
Also if there's a pattern in the modbus addresses like there's a base address for a UDT set of tags with an offset, you can do parameters like this:
ns=1;s=[{deviceName}]HR{baseAddress+9}
Where your device name parameter is ET_ASSIS and the base address parameter is 6000.
This is also how I’ve done Modbus UDTs, it means you can also manually override individual tag addresses that don’t match the pattern for any reason, and that override is per device.
It is an extra configuration step when configuring/creating devices and OPC tags via automation. The only positive is that it gives you browsable addresses. (You can get browsable manual addresses with my alternate driver if you need that during development.)
It also creates a level in indirection that makes troubleshooting and maintenance more difficult. You can no longer determine the actual Modbus address being read from looking at the OPC Item Path. Instead, you have to look at the path, go to the mapping table, do the lookup yourself, but not before you maybe deal with a non-standard radix conversion, maybe deal with address stepping, etc…
