Indirect Tag Binding Performance

I’m working on a project in which I’m creating screens that use a lot of indirect tag binding. Basically, the user clicks on an object, which sets a custom property on the root container, and a bunch of window objects update accordingly. My problem is, no matter how many or how few objects I do this with, it takes a full second or so to update the objects. All of these objects display the overlay with the green question mark for a second – making the display seem a little sluggish or amateurish. If I opt out of using the overlays, then all the values go to -1 for a second, which isn’t much of an improvement.

Is this typical? Are there any good workarounds?

Thanks.

You can try changing your default scan class for any SQLTags involved. The default time is one second.

Thanks, Jordan, but the problem isn’t the update rate of the tags. The tags are updating fine. The delay comes when using indirect binding and switching from one tag to another. Hopefully that makes sense. I’m not really concerned with how fast the tags update on the gateway or on a window, but concerned with the lag that occurs when changing the property value that switches the objects tag binding.

The problem here isn’t the indirect bindings, per se. It’s just that you’ve got stuff that’s subscribed to one set of tags, and then you switch it, and it has to go and subscribe to a different set of tags. Until the values of that next set of tags arrive, the components display the “Unknown” overlay.

Some factors that may affect how long this takes

  1. The client poll rate. default is 1/4sec. You haven’t changed this have you?
  2. Are these bindings UDT bindings or direct to tag values? UDT bindings take longer to initialize.

I haven’t changed the client poll rate, but these are UDTs. So it sounds like I’ll have to live with the lag since I can’t avoid the use of UDTs. Can you suggest any possible ways to make the transition look a little more appealing? The only thing I can think of is to bind to expressions that use “if” statements, displaying a blank whenever the value is -1. This seems to work, but will take a while to implement, and it’s going to be difficult to explain to the customer why I had to add so much complexity.

Another option would be to “pre-load” each of the UDTs in some sort of dataset, or by creating custom UDT properties and binding to each of my UDTs. I think I have plenty of horsepower for this, but there are two problems with these options.

  1. I have no idea how to get my UDT structure into a dataset. Is there some way beyond brute force scripting?
  2. If I create custom properties for each tag, I can’t figure out how to bind to one of the sub-elements because I can’t nest custom properties in an expression.

To be clear, it isn’t the UDTs themselves that are slow, it is having custom properties of a UDT type and using a UDT binding.

This is usually easy to get around - keep your UDTs but don’t have custom properties of UDT type - just bind basic type properties directly to the elements of UDTs that you need. This avoids loading the whole UDT in the client.

What I’ve been trying to do all along was bind basic type properties directly to elements of my UDTs (via indirect binding methods). That’s where the lag lies. If I recreate the tag structure using nested folders instead of a UDT, the binding is very snappy. I may have to do this, which is unfortunate because it defeats the whole purpose of object oriented development. But I can’t live with the slow screen updates.

Hi,

What version are you currently using? I just want to make sure I’m looking at the right thing, as there have been a few changes over time to how this works.

Also, roughly how many items are in your UDTs?

Regards,

I’m using 7.7.4. Just as a test, I created a UDT with only four elements and it still shows the same symptoms.

On a system without very much load, and a UDT without hundreds of tags, I wouldn’t expect the delay to be very big.

On a quick test, I see the tags go to unknown briefly, and then come in. After that point, though, I can switch through them and I don’t see the bad quality, theoretically because they’re cached after that point.

Could you try going to Console>Loggers in the gateway, search for “TagStore”, set it to debug, and then re-run your test? After, attach the wrapper.log file from “{InstallDir}\logs”, or post the parts that show how long the tag loading is taking. I’m trying to get some idea of the performance of system as it switches tag subscriptions.

Regards,

Here’s the relevant portion of the wrapper.log. These times don’t look excessive at all, but it’s very noticeable on the screen until the tags are cached as you mentioned.

INFO | jvm 1 | 2015/05/13 09:56:44 | DEBUG [TagStore ] [09:56:44,280]: Precaching tag definitions for 99 out of 99 tags.
INFO | jvm 1 | 2015/05/13 09:56:44 | DEBUG [TagStore ] [09:56:44,284]: Internal tag store loaded 53 tags in 4 ms
INFO | jvm 1 | 2015/05/13 09:56:44 | DEBUG [TagStore ] [09:56:44,850]: Precaching tag definitions for 74 out of 74 tags.
INFO | jvm 1 | 2015/05/13 09:56:44 | DEBUG [TagStore ] [09:56:44,854]: Internal tag store loaded 10 tags in 3 ms
INFO | jvm 1 | 2015/05/13 09:56:48 | DEBUG [TagStore ] [09:56:48,244]: Loading tag definition from database into cache for id ‘65’.
INFO | jvm 1 | 2015/05/13 09:56:48 | DEBUG [TagStore ] [09:56:48,253]: Internal tag store loaded 1 tags in 5 ms
INFO | jvm 1 | 2015/05/13 09:56:49 | DEBUG [TagStore ] [09:56:49,852]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:49 | DEBUG [TagStore ] [09:56:49,856]: Internal tag store loaded 1 tags in 4 ms
INFO | jvm 1 | 2015/05/13 09:56:50 | DEBUG [TagStore ] [09:56:50,366]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:50 | DEBUG [TagStore ] [09:56:50,371]: Internal tag store loaded 1 tags in 5 ms
INFO | jvm 1 | 2015/05/13 09:56:53 | DEBUG [TagStore ] [09:56:53,568]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:53 | DEBUG [TagStore ] [09:56:53,571]: Internal tag store loaded 1 tags in 3 ms
INFO | jvm 1 | 2015/05/13 09:56:54 | DEBUG [TagStore ] [09:56:54,041]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:54 | DEBUG [TagStore ] [09:56:54,046]: Internal tag store loaded 1 tags in 5 ms
INFO | jvm 1 | 2015/05/13 09:56:56 | DEBUG [TagStore ] [09:56:56,180]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:56 | DEBUG [TagStore ] [09:56:56,183]: Internal tag store loaded 1 tags in 3 ms
INFO | jvm 1 | 2015/05/13 09:56:56 | DEBUG [TagStore ] [09:56:56,707]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:56 | DEBUG [TagStore ] [09:56:56,710]: Internal tag store loaded 1 tags in 3 ms
INFO | jvm 1 | 2015/05/13 09:56:59 | DEBUG [TagStore ] [09:56:59,087]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:59 | DEBUG [TagStore ] [09:56:59,091]: Internal tag store loaded 1 tags in 4 ms
INFO | jvm 1 | 2015/05/13 09:56:59 | DEBUG [TagStore ] [09:56:59,647]: Precaching tag definitions for 2 out of 2 tags.
INFO | jvm 1 | 2015/05/13 09:56:59 | DEBUG [TagStore ] [09:56:59,650]: Internal tag store loaded 1 tags in 3 ms