Managing UDTs common to many Edge gateways


I have a project where I want to deploy 40 very similar Edge gateways and connect them all up to a main gateway. The Edge gateways will all connect to similar devices, which I am modelling with some nested UDTs to represent each device.

If I have to manually export and import the UDTs to each edge gateway, it will become very time consuming to update them each time I want to make a change. Can I ‘push’ UDT definitions to my Edge gateway using EAM? Can I create instances of a main gateway UDT on my Edge gateway without actually having the UDT on Edge? What’s the best way to handle this?

EDIT: Extra questions (because I’m struggling a bit to get my head around Edge):

Currently if I try to edit a tag from my remote edge gateway while in my main designer, I get the following message. Is there some way I can set up my Edge gateway to accept editing tags from the main designer?

Also what determines what my delay will be when setting up Edge as a remote tag provider? Say I have a modbus device that I’m polling every 100ms with Edge, then I set Edge up as a remote tag provider to my main gateway (same local network). Will my delay just be 100ms + network delay or is there some other parameter that influences this? I’m pretty new to OPC so I’m not sure I understand everything that’s going on behind the scenes.

You should be able to send tags to the edge gateways. So I guess UDT definitions too.

Regarding the speed. I believe that by default, remote tag providers use WebSockets. So it should indeed be the 100ms OPC-UA polling + the network latency.

1 Like

Ah! I didn’t realise that Tag Types had a path - of course they would! I tried it and it works - thanks :slightly_smiling_face:

Regarding the speed. I believe that by default, remote tag providers use WebSockets. So it should indeed be the 100ms OPC-UA polling + the network latency.

Music to my ears! :star_struck:

I do have to say that 100ms can be too fast for certain devices. Certainly if you have a lot of tags that change often.

The PLC usually runs OPC communication on a lower priority, and will delay sending of updates if there’s not enough time left in the cycle. So depending on your hardware, it’s possible you won’t reach 100ms.

Yeah, I’m aware that there can be problems polling too fast. Most of the manufacturers I work with either suggest a 100ms, 500ms or 1 second maximum poll rate, so just looking at the worst case. Do you know how this works when you have multiple spans of registers to poll? Say HRs 0-99 then 100-199 then 200-299? Do I need to set the poll rate to 3x slower than the maximum rate allowable, then Ignition will know to evenly space them? Or does it not matter and I can just set it to the maximum poll rate? I’m guessing this is manufacturer specific, but wondering what the usual approach is.

Fortunately I don’t need to connect to PLCs over OPC for most of my projects, just between my main Gateway and Edge gateways (hence why I was nervous about adding a second delay onto my device-to-Ignition delays).

The key to polling pace is response time. That is a combination of request processing time in the PLC and the network round trip latency (~ping time). Most drivers will optimize requests for adjacent or nearly adjacent registers into single requests for blocks of registers (but with options to disable optimization, as that screws up various stupid devices). But in general, the pace can’t be any faster than the sum of the response times for all subscription requests. AB Logix is a special case, as its protocol not only allows bulk reads of array ranges and UDTs, but can further wrap multiple arbitrary requests into a single request for the network round trip. Anyways, study your drivers’ diagnostic pages where the response times and request counts are displayed for all subscribed items.