My expectation would be that the alarm would enable when both of these conditions evaluate to true, but it does not seem to be evaluating the second condition. In other words, it toggles when HH Alarm != 0, but does not move when HH Alarm NALM moves from 1 to 0.
I've tried this several different ways but nothing has worked so far. I've tried with parenthesis, without. I'm sure I'm overlooking something simple here but I'm not sure what I'm doing wrong.
Thanks!
UPDATE:
Just in case anyone stumbles upon this at a later time. Should have caught this problem earlier, but we have determined the cause of this.
Seems our integrator left the alarms for each of our tags in an overridden state, so when we made the updates to the UDT, the updates were not being reflected in the tag / UDT instances. Manually going into each tag and removing the override has seemingly resolved the issue. As it turns out the issue was never actually with the logic not working but simply that the changes made to the UDT were not being applied to the tags as expected because they were overridden.
I created 3 simple tags
AlmTest BOOL
Bool1 BOOL
Bool2 BOOL
Created an alarm on AlmTest and set it to condition and used the expression {[.]Bool1}&&{[.]Bool2}
When I toggle both Bool1 and Bool2 to True the alarm goes active.
Not sure if your tag paths are wrong, or they are not bools, but you don't need to do the !=0 or the =1 to evaluate for True/False.
That makes sense but unfortunately those tags aren't actually bools. They're OPC tags (which I browsed to by the way, so the paths should be correct), and from OPC those tags are actually integers. The one is kind of like a BOOL in that it's just a 1/0, but the HH Alarm tag is a 1/not zero.
I'll do some more testing but in my case, I would simply need to toggle BOOL1 (HH Alarm) to toggle the alarm. That part evaluates correctly as expected...
The problem is that it does not seem to be evaluating BOOL2 (HH Alarm NALM) for me. When that condition changes, it doesn't impact the alarm at all.
I did try converting that second value over to a BOOL though just for the sake of trying & even then it still seems to ignore that second condition.
Anything else you would want to consider? Your config honestly looks identical to mine unless I'm just missing something... I guess yours is setup on the individual tag whereas mine is at the UDT level. Would not anticipate that as relevant, but it is different.
I'm not really attempting to ack the alarm in Ignition. We might consider that in the future, but really I just want to clear it when it gets ack'd in our other system. We really just use Ignition in the limited capacity of alarm notification, so this is simply just to stop the alarm notification escalation that we have setup. I don't really understand why it's not working though; seems pretty simple to do
Correct, HH Alarm is true. I would expect this to work as well but unfortunately it's not.
If you're asking if the alarm itself is enabled, then that is also true. It does go into alarm when the first condition is met. For some reason it simply does not seem to be evaluating the second condition so the second condition never does anything to impact the status of this alarm.
If push comes to shove, I believe I can do some simple math to make this work (under the guise of a single condition), but I'm a bit perplexed as to why it doesn't appear to be evaluating that second condition.
Appreciate the pointer to tag diagnostics. That's pretty handy. Here's what I'm getting on that tag when it goes active (that's the 13). Toggling the NALM value does not impact this activeCondition value whatsoever.
Does yours show both conditions?
I'm sure I'm somehow doing something wrong here but I'm at a loss for what it is...
I don't know why or how it'd be relevant, but the NALM point is a polled OPC point whereas the alarm point is a subscribed point. I can see those values update though & don't see any errors on those points.
Sorry for the confusion. I just updated that image in the post you're referring to. It does toggle to 0 when it get's ack'd but I failed when copy/pasting the image it seems.
I can confirm that this point is polled & it is not subscribed. When testing though, I was reading the values of those points in Ignition & wasn't looking for an alarm state change until those values updated. I'm not sure if that's what you're saying here, but if that's the case, I will confirm that even after those values updated, the alarm status was not updating to follow. There's a reason it's polled & not subscribed, mostly licensing limitations on the OPC server (not Ignition). If that's a problem for some other reason though, I'd certainly be interested. We can always up those licenses if need be; just trying not to add extra costs unless necessary.
All that said, this seems to be effectively resolved. I'm not sure what happened but this is what I did...
I copied the UDT that was assigned to the tag I was testing. I reassigned that tag to the copy of the UDT & I tested again. It worked there. I'd actually tested it right before I copied it & it wasn't working. Then I reassigned the tag back to the original UDT & now it works. It's like it got latched in there w/ the old code.
I'm not sure how that happens or what I can do to avoid that... Best guess I've got is to restart the Ignition services?
