The read tags function system.tag.readAll allows you to read tag value and its quality. Similarly is there a way I can also read the alarm status for these tags (active, cleared, acknowledged status) for these tags in a single read ? Tag event script can be then made use of to get updates on alarm status change.
In Ignition there can be multiple alarms associated with a Tag. However can multiple alarms be active for a tag simultaneously? That is can a Tag generate more than one alarm at the same time? Aren’t the alarms mutually exclusive? e.g. Tag value can be in one of the states like low, or very-low or high or very high, or on or off etc. Isn’t it safe to assume that there will be one alarm active at a time for a tag? Can someone give an example where more than one alarm will be active for a tag? Can we not assume that a Tag is in one of the alarm states at any given time? What are the advantages/ disadvantages of the assumption?
You can have multiple alarms for the same tag so you cannot assume there will be only one, you can for instance set two different alarms: one if the value is above a setpoint and one if it is below. In certain cases that makes perfectly sense and you would have trouble specifiying it in a single alarm.
Most of the time however I agree that an alarm for a tag is a common scenario.
system.tag.getConfiguration (system.tag.getConfiguration - Ignition User Manual 8.0 - Ignition Documentation) is the only method that I know of.
Of course you can pass a folder path instead of a single tag path (as shown in the examples).
I agree that there can be multiple alarms associated with a single tag, but my point was can these multiple alarms be ACTIVE at the same time? e.g. When a hi value alarm is active, a very high value or a low value alarm will not be active at the same time, is that correct.
Can we not treat the state of a Tag itself as an alarm e.g. tag is in NORMAL state, or HI state or LOW state, or BAD state etc. The advantage will be that we have just one integer for every tags telling its state at any point of time instead of many alarm tags variables. Of course we need to log the state transitions and acknowledgement by operators. I don’t know what the ALARMS specification of ISA or whatever standards organizations define.
As it is you can have N active alarms on a single tag, so it’s not so much whether a tag “has an active alarm or not” but instead about “how many active alarms a tag has”.
In a limit case the same tag can have 2 active alarms and 2 inactive ones.