What's the best way to allow operators to enable and disable the alarm pipeline for specific alarms on a tag-by-tab basis?
There's not anything that's immediately apparent to me.
Have you tried simply scripting a write to it?
Scripting a write to what, exactly?
And how to do so for every tag with an alarm enabled?
Looking in the tag browser, I'm not seeing anything like an "alarmPipeline" under the alarm section.
Some of my alarms are housed in a UDT with a "notify" parameter that can toggle the pipeline, but not all tags with alarms are part of a UDT.
Pipelines don't have any notion of being enabled or disabled, but...
Maybe you could start each pipeline with a Switch Block that looks at an enabled tag or property, and feed the rest of the pipeline from the true/1 branch and leave the catch-all branch disconnected.
edit: actually... they do, but I don't know if it's available in runtime...
I'm not trying to enable/disable an entire pipeline, just enable/disable the notification on the alarm for an individual tag.
For instance, when setting up an alarm using the dialog box if an alarm is not going to notify on the pipeline, the pipeline entries in alarm config would just be blank. If it is going to notify on the pipeline, the specific pipeline is specified.
How can this be achieved programmatically for each alarm using something like a dropdown box to select "none" or "pipelineA"?
Oops, I misread the original post.
Interesting. The pipeline is not exposed as an alarm property. The alarm enable is, like so:
[default]Alarming/SimpleTest/Alarms/Alarm1.Enabled
to which you could write True and False.
If you look at a tag's JSON, you can see the activePipeline property on alarms, so it does exist, but cannot be simply written. (I tested. Got Bad_Unsupported.)
It does show up in the return from system.tag.getConfiguration, so it should take a modification via system.tag.configure.
1 Like
Yes, but then the alarm doesn't show up at all, which I would like it to, just not enter the alarm pipeline.
If toggling the enable isn't sufficient, I think you will have to use system.tag.configure. The key is to retrieve the config, modify just the element of interest, and then apply it.
1 Like
that.... seems a lot of work. on future deployments I'll probably just make a generic "alarm tag" UDT with a "notification pipeline" parameter custom tag property that can do this for me without scripting.
Wish it was exposed so I could bind directly.
Thanks anyway.
have you found a solution you were looking for? To make sure I understand, you are basically wanting to be able to configure an alarm pipeline only for specific tags but not others while using the same UDT? If that is that case, I'm not sure if it is what you are looking for, but I actually made a client with a tag creation window that allows users to create a tag using the "Alarm UDT" that I configured and pick out different selections like PLC name, tagPath, alarmName, setpoints and which pipeline to send that alarm to. I basically used UDT parameters and generic tags within the UDT definition and then access that with a single script that fires once they press a button and have all the information entered. It does use system.tag.configure to access the UDT parameters, but it is completely dynamic based on the entries the user puts into the tag creation screen.
Not quite that complex.
The system has a long list of alarms, and I would like the operator to select which ones notify on their sms notification pipeline. Most of my alarms exist inside a UDT, so I just added one parameter to each UDT Notify_Pipeline | String and bound that to the sms pipeline inside the alarm definition. The default for the UDT is set to the pipeline, but I can now use a selection or dropdown box to allow the operator to change the string that is ultimately used for the alarm pipeline with just a simple binding. If they don't want to be notified for the alarm it gets set to a blank string.
2 Likes
>1 year later...
There is also an event method - event.cancelNotification() - which is unique to a Script Block within an alarm pipeline:
https://www.docs.inductiveautomation.com/docs/8.1/appendix/reference-pages/scripting-object-reference#scriptableblockpyalarmevent
If you have a need to execute an alarm pipeline, but conditionally drop out prior to other tasks completing, this method might be a good alternative (to creating derived alarm pipelines and selecting which to utilize).