Problems with Display Path Filter Application in Alarm StatusTable

Good morning everyone,
I have a Display Path Filter added in an Alarm Status Table, which filters me the active alarms. Everything works fine, as the filter is applied correctly.
However, I have a problem: every time I log into Vision and go to the place where the Alarm Status is, the first thing that is displayed is all the active alarms for a period of 3-5 seconds, and only after that the filter I have configured is applied. I have received complaints from the customer and I am looking for a way that, when I log in, only the filtered alarms appear from the beginning.
Am I doing something wrong? I attach images.

image

2 seconds later

image

regards.

when in the designer for vision are these alarms displayed?

You may hit run in the designer to get the preload to load properly for that display filter and try from there. It sounds like maybe you have a difference in the data that is cached and the refreshRate which is default 2500 milliseconds.

if that doesn't work, then you can manually control alarms before they ever get added to the table by the extension function.

inside of the filterAlarm extension function you may try and use something like return (self.displayPathFilter in alarmEvent.get('displayPath')) Still utilizing the filter property to avoid unneeded custom properties.

1 Like

Thank you for your quick response! I really appreciate the guidance. I'll try running the screen in the designer as you suggested to see if it helps with the preload and filter application. If that doesn't resolve the issue, I'll look into adjusting the refresh rate or using the extension function to manually control the alarms before they get added to the table. Thanks again for the advice!

1 Like

More than likely, it is the binding for the display path filter not having a value yet at startup, so the component triggers its query with no filter. The binding then updates while the full query is running (which is naturally slower than a filtered query) and cannot take effect until the next query.

Consider not using a binding. Instead, move the binding to a custom property, and use a property change event to move non-empty values from that custom property to the actual display filter. Then, always save the window with some garbage in the display path filter that won't match anything.

1 Like

Apparently, I don't think I can use a custom with a property change, because I always rely on a multiple status button. If it's 1, it gives me a status filter, and if it's 2, it gives me an alarm filter.

I currently have the binding in the Display Path Filter of the Alarm Status table with this code:

// BESS 1
if ({Root Container.bess_container} = 1, 
    if ({Root Container.PV_stats_alarms_param.controlValue} = 1, 
        "BESS_" + {Root Container.bess_container} + {Root Container.bess_number} + "*Status:*, BESS_" + 
        {Root Container.bess_container} + {Root Container.bess_number} + "*Trickle charging Status:*",
    if ({Root Container.PV_stats_alarms_param.controlValue} = 2, 
        "BESS_" + {Root Container.bess_container} + {Root Container.bess_number} + " Alarms:*", 
        "")
    ),
    
    // BESS 2 - false logical 1 if container 2 is selected
    if ({Root Container.PV_stats_alarms_param.controlValue} = 1, 
        "BESS_" + {Root Container.bess_container} + {Root Container.bess_number} + "*Status:*, BESS_" + 
        {Root Container.bess_container} + {Root Container.bess_number} + "*Trickle charging Status:*",
    if ({Root Container.PV_stats_alarms_param.controlValue} = 2, 
        "BESS_" + {Root Container.bess_container} + {Root Container.bess_number} + " Alarms:*", 
        "")
    )
)

Would I have performance problems if I lower the refresh rate from 2500 ms to 1500 ms?

When you change the value of the multi state you could update the custom property and that would fire the change script.

Note what @pturmel has said. If you do this it will not have anything in the table until you write to the custom property that fires off its change script that would cause the alarm table to filter

you could do something like this effectively:

if event.propertyName == 'controlValue':
	displayPath = ""
	if  event.newValue == 1:
		displayPath = "SomeDisplayPath1"
	if  event.newValue == 2:
		displayPath = "SomeDisplayPath2"
	if  event.newValue == 3:
		displayPath = "SomeDisplayPath3"
	event.source.parent.getComponent('Alarm Status Table').displayPathFilter = displayPath

You can still use a custom property if you wanted, or use this in conjunction with the extension function. You could need to change it to fit your numbers and what type of filtering you are doing.

all this on the root container of the component or on the propertychange of the component itself?


I used a multi-state button as an example. this would be on the propertyChange event

1 Like

Perfect, it has worked for me and I see it more fluid. Even so, I will be monitoring to see how it goes smoothly in the Vision. In turn, I have added another propertyChange in the root container, because I also depend on a custom component that changes system, in this case, I mean the bessContainer, if it is 1 or 2.

bessContainer = event.source.parent.bess_container
bessNumber = event.source.parent.bess_number

if event.propertyName == 'controlValue':
	displayPath = ""
	if  event.newValue == 1:
		displayPath = "BESS_" + str(bessContainer) + str(bessNumber) + "*Status:*, BESS_" + str(bessContainer) + str(bessNumber) + "*Trickle charging Status:*"
	if  event.newValue == 2:
		displayPath = "BESS_" + str(bessContainer) + str(bessNumber) + " Alarms:*"

	event.source.parent.getComponent('Alarm Status Table').displayPathFilter = displayPath

Glad we could help; I would recommend marking a solution once you are satisfied so others can easily see this issue has been resolved for you when they are searching for a similar issue!

1 Like

I have made a couple of scripts to give solution to what I asked above

This script in the PropertyChange event of the Root Container automatically adjusts the alarm table filter when the bess_container or controlValue properties change. Depending on the value of controlValue, the script decides whether to display the status, alarms or all information of the selected BESS. Thus, each time the BESS is changed, the filter is updated to show only what we really need to see.

PropertyChange (Root Container)

changedProperty = event.propertyName
bessContainer = event.source.bess_container
bessNumber = event.source.bess_number
controlValue = event.source.getComponent('PV_stats_alarms_param').controlValue

if changedProperty == "bess_container" or changedProperty == "displayFilter":
    if controlValue == 1:
        result = "BESS_" + str(bessContainer) + str(bessNumber) + "*Status:*"
    elif controlValue == 2:
        result = "BESS_" + str(bessContainer) + str(bessNumber) + "*Alarms:*"
    elif controlValue == 0 or controlValue == 3:
        result = "BESS_" + str(bessContainer) + str(bessNumber) + "*"

    event.source.getComponent('Alarm Status Table').displayPathFilter = result
    event.source.displayFilter = result

PropertyChange (Multi-State Button)
and finally this script automatically adjusts the alarm table filter when the value of controlValue changes. Depending on the value selected, the status, alarms, or all information of the corresponding BESS is displayed. The script ensures that the alarm table always displays the most relevant information in real time.

bessContainer = event.source.parent.bess_container
bessNumber = event.source.parent.bess_number

if event.propertyName == 'controlValue':
	displayPath = ""
	if  event.newValue == 1:
		displayPath = "BESS_" + str(bessContainer) + str(bessNumber) + "*Status:*"
	if  event.newValue == 2:
		displayPath = "BESS_" + str(bessContainer) + str(bessNumber) + "*Alarms:*"
	if  event.newValue == 0 or event.newValue == 3:
		displayPath = "BESS_" + str(bessContainer) + str(bessNumber) + "*"

	event.source.parent.getComponent('Alarm Status Table').displayPathFilter = displayPath