Vision alarm status table - Unfiltered on initialization

I’m having a similar issue to this post, but within Vision. I use an alarm status table in a template to preserve some custom formatting and to streamline some filtering (e.g. enter a tag path, the template formats it to a wildcarded qualified path and binds that to the source filter).

Occasionally when opening a window or popup with this template, the alarm table will appear unfiltered - all alarms will be included. The filter then kicks in 1-2 seconds later. This causes a flash of color and action, which without fail prompts operators to go ‘woah, what was that?’

Has anyone else encountered this? I suspect it could be a timing issue with the expression bindings - e.g. in the time it takes to generate the qualified tag path, the table begins displaying all alarms (because the source filter is blank until the expression completes). Would love any insight into this, and any recommendations for side-stepping the issue!

The window may be loading with the initial state of how it was saved in the designer. Try putting a filter in the designer that won’t load anything and save that and see if that solves the issue.

That doesn’t seem to affect it in my case. Generally, my template instances do have filters applied in the designer - restrictive ones that wouldn’t cause the behavior I described above.

To be a bit more specific about my implementation, my template has template parameters of display path filter and source filter. The template would typically be placed in a popup that is passed a UDT tag path for indirection. The template’s display path filter is an indirect tag binding to a string tag, and the source filter is an expression that converts the UDT tag path to a qualified tag path. Within the template, display path filter and source filter are bound directly to their respective filters on the alarm status table.

Another observation is that this behavior is most repeatable on popups with more bindings. Seems to give credence to it being a timing issue.

Could you have the source filter bind to a custom property that then binds to your expression. This way you can save the template with an invalid source filter in the custom property?

I’m not sure if that will work, but I’ve seen this behavior on components with indirect bindings where the tag path which is in a custom property is evaluated when the template loads with whatever was last saved in the custom property in the designer. If I put an invalid value (or blank in my case) in the custom property before I save it, then it will stop that from happening (might have overlays initially which is acceptable to me).

1 Like

It very much is a timing issue. Tag binding, indirect or otherwise, deliver an null or -1 initial value on startup if the tag is not already on hand from another live binding. Then they update after a brief delay when the value arrives from the gateway. The expression that drives the filter on the alarm status table should be constructed so that any invalid or blank inputs yields a fallback filter that produces no rows. The fallback will then be applied right at the start, and update when all of its inputs become valid.

1 Like

Finally had a chance to return to this - wanted to provide an update and say thanks to you both for your assistance! I’ve ended up doing something along the lines of pturmel’s suggestion.

I’ve changed my implementation somewhat. I’m now generating a source filter string tag within a UDT. As before, my popup is provided a UDT path and uses indirect bindings. I read the source filter tag into a custom property source_filter. My alarm status table has the following expression binding on the source filter property, enabling it to provide a safe fallback (AKA returns no alarms):

if (
	isGood({Root Container.source_filter}),
	{Root Container.source_filter},
	'~'
)

Short, sweet, and most importantly, works!

1 Like