Well I am sure someone else is doing this but just haven’t quit figured out how to make it work since it’s not a built in feature of Ignition yet. What i need to do for analog alarms is have a digital permissive bit in the alert for the analog signal.
For example i am looking at a signal that has a valid range of 105 to 300 while machine is running. If machine shuts off this value goes to 0 and i get an alert for it. I don’t want this logged. In other systems I can set a “trigger” so that the alert won’t be active without that digital signal being in the correct state also.
I’m guessing i am just missing something here got to be a way to do this.
I’ve gotten around this by making a db tag (sorry, I’m still in the 7.2 world-- I think they’re expression tags now) using an expression like:
({analog_value}toInt({running}))+(toInt(!{running})-1)
If running is true, then it uses the analog value. If false it’s set to -1
Then I set up my alarm to the db (sorry, expression) tag.
Jordan’s expression should work, although an if statement may be more efficient and easier to read:
if({running},{analog_value},-1)
Put that expression in an expression tag, and set up an alert on that tag. Unless I’m misunderstanding what you’re trying to do…
Hey! It was like 2am and no coffee when I originally wrote that! 
Thanks Guys
James
Do you know if the guys are looking at adding something like this into the alerting setup for analog alerts. This is a very common thing to setup and will be a bunch of extra work to do it in this way.
This feature should be included one way or another when the alerting system gets an overhaul in 7.6. This may be implemented by allowing the AlertExecEnabled property of a tag to be bound to something, we’ll see.
Here, let me give you a little preview of what we’re working on for 7.6, and you can give us some feedback. We’re still relatively early in the dev cycle, so it’s not too late for little adjustments.
Basically, there is no longer a “digital” mode and “analog” mode. Each tag can have any number of alarms defined on it, with a variety of new alarm modes available. Each alarm is configured with properties, much like components, and most of those properties can be bound to other tags or expressions.
So, image 1 shows the new alarm config, and image 2 shows how the “Enabled” property might be bound to accomplish what you’ve described.
Yep that looks like it would work great.
I am assuming all the General Settings and Notification settings will all still be there also.
That said it would be nice to at minimum to have the notes field stored in the alert table and not just in the sqltag if not notes the at least one more field that is configurable with each alert that get stored to the alert table. This would just provide more flexibility in parsing the data and filtering it.
Hi,
Yes, the full list of properties isn’t represented there, but will still be available. The “alarm log” is going to get a significant boost as well, and become the “alarm journal” which will store not just events, but other data associated with those events. That data will include the value of properties, including custom properties that can be defined on each alarm. You will then be able to query based on these properties, in addition to more standard parameters like severity, path, etc.
Regards,
Good !!! 
When 7.6 will be available?
It looks like it should be available towards the end of the first quarter of 2013.
