Perspective: creating bindings in script?

Ignition
,
1

v8.1.3

I fear the answer is no as it was in Vision (well, it was possible, but extremely flakey and dodgy to do), but can we create bindings via script in Perspective?

The alarm status table is causing us grief (slow performance for 25k alarms) and also isn’t customisable enough to display how I want our alarms to be displayed (would be nice if we could provide a View to use for each row), so instead, I’m creating my own viewer using a flex repeater. I want read all alarms within the path filter and then read the alarm IsActive properties and want to hide them in the flex repeater if off. However to do that I have to set the instancePosition param values which are outside of the flex’s templates. I thought that I could instead use an output param in the template View to create this and then bind the keys based on the status of the alarm, however I can’t bind to an object’s children if it’s a param, even if if it’s an output…

Actually, I will try binding the instancePosition to a custom.instancePosition instead. This works :wink: crisis averted

2

No. A view's fundamental structure (components, bindings, etc) is not mutable at runtime.

3

Is there a way to programmatically enable or disable a binding, as is possible with the checkbox in the binding editor?

I was hoping similar to the self.refreshBinding('props.data')

4

We stopped using the builtin alarm summary and wrote our own.
We have global scripting that filters alarms based on AlarmGroup which is a custom property on each alarm.
The script parses the alarms, builds dataset tags in the folder for each alarm group and then we use that dataset tag to display the alarms.

We fire the scripts off of a tag change script on
[System]Gateway/Alarming/Active and Acked
and
[System]Gateway/Alarming/Active and Unacked

Cuts way down on queries against the alarm tables since every client just looks at the dataset tag vs having queries running against the tables.

5

Interesting. I have “Area Alarms” UDTs that I use for the purpose of summarising alarms at particular levels in the tag structure. These have the counts of alarms for each state category (ActiveAck, ActiveUnack, ClearUnack) and also a document tag that has the actual alarms that are active and their details. Originally I was running a custom function that was calling the system.alarm.queryStatus function every 5s for each instance of this UDT, however this was suspected to be causing significant (~10-15%) loading on the CPU. What was also contributing to this was that the count tags were using jsonGet as well as jsonEncode and jsonDecode functions to pull out the counts from the UDT instances’ document tag values. The json functions I’ve discovered from support are CPU hungry, so i’ll be doing converting to doing something similar to what you mention, and using a global script to store alarms into a system.util.getGlobals() key value and reading that instead in my UDT instances.

In terms of how I use the alarm fields for naming, I haven’t used any custom alarm fields as these can’t be displayed in the alarm status table / alarm journal table, so instead I use the existing fields and bind them as:
name = the name of the alarm (e.g. Failed to Start)
label = {deviceDescription} [{EquipID}] (e.g. Outlet Pump [BLU_PU001])
displayPath = {alarmArea}< {alarmParentDevice}> (if {alarmParentDevice} is not blank)
e.g.
Filtration Centrifuge 1
Tank Farm Premium T3044

6

To get around it you can add 3 custom properties to the component. One binds to your "enabled" tag, one binds to the "disabled" value, the other is the toggle. Use an expression binding to bind to the enabled/disabled data based on the value of the toggle.