I have tested it and it does work. Tags are accessible from the expression binding for the alarm pipeline property.
edit: I have not tested it during runtime. I only change that tag internally in the designer so I don't have to do it all manually. I have not (yet) tried something like providing a dropdown box to provide selection of different alarm pipelines for the alarms.
Had to get a little creative with dynamic updates on the Storage Provider name.
Tag change script on a string tag inside the UDT. This string tag holds the name of the Storage Provider you want to use.
When this string is updated the script writes the new value into the parameter of the UDT. The Storage Provider is bound to the parameter.
That string tag can be a memory tag or an expression tag that binds to a string tag at the provider level.
Heh. Don't we all sometimes. Do document it well for the poor guy who follows you.
Oh, I am, considering that I'm currently the sole Ignition Integrator on this $2m+ project.
I do like it that way though, for consistency's sake.
I'm VERY late to this post... but can confirm that we have been running redundant edge gateways for some time now. Unsure when it was introduced, but I'd bet a candy bar that we started our first Edge redundancy prior to 8.1.16.
(Unrelated:) The new Edge licensing model (unlimited devices, 35 day-historian, etc. &, somehow, cheaper pricing) makes it very difficult NOT to choose Edge gateways for all of our remote installs.
We have central gateways (strategically located), each configured to 'bring in' & manage their respective Edge gateways. Each contains Enterprise Administration, Unlimited Perspective Clients, Historian, some custom modules, and NOT A SINGLE CONNECTION TO A PLC. Regarding alarming, all of the Edge Gateway providers have a version of the same UDTs, each with alarm pipelines configured for their (respective) central gateway.
We opted to configure ALL alarms w/ the same pipeline of their respective gateway, always, and then have the 'primary' pipeline redirect alarms to other pipelines as necessary. Essentially, we moved our 'case statement' to the alarm pipeline.
I'm guilty as charged! While I hate wasting my day away reverse-engineering, I hate the idea of repetitive tasks (configuring the same parameter across tens -or- hundreds of tags) even more. I try to leave breadcrumbs for anybody that follows. One example, naming a parameter with a prefix of 's' is an indication that it's written to from a script (e.g. 'sIsEnab', 'sEngLow', etc.). The remainder of parameters are prefixed with a 'p' to indicate that they should be modified by the designer (e.g. 'pDescription', 'pEngUnits', etc.).
