I can’t see any way of putting in a time delay before an alert is triggered. This would be very useful in filtering out spurious alarms.
I’m thinking this is a FactorySQL request, not FactoryPMI. At first glance the request made sense. Then I thought about it, and I can’t see how that could possibly be useful. Please explain.
From Wikipedia in case anyone else doesn’t know what a spurious relationship is.
[quote]In statistics, a spurious relationship is a mathematical relationship in which two occurrences have no causal connection, yet it may be inferred that they do, due to a certain third, unseen factor (referred to as a “confounding factor” or “lurking variable”). The spurious relationship gives an impression of a worthy link between two groups that is invalid when objectively examined.
[/quote]
Nathan,
This would have been a FactorySQL request until SQLTags came along! Although FSQL is doing the work, I thought it best to put it in the FPMI section as this is where the configuration is carried out.
As an aside, the only thing I am using FSQL for in my current system is to set up initial configuration and historical logging. I see from your development plans that you are proposing SQLTags History for FPMI. When this comes along, configuration in FSQL is going to be pretty minimal.
As regards alert delays, we’ve used this feature in other packages many times. One that springs to mind is a cleanroom monitoring system we installed. This system monitored the differential air pressure between rooms. When someone opened the door and moved from one room to another, the pressure differential dipped briefly, then quickly recovered. By using a delay on the alarm, we could screen out these brief dips, but still alert the operators when there was a real problem, such as a door being left open.
n/m - I thought you meant delaying when an alert is sent. You mean that the alert condition must be true for some period of time before “it counts”. We have a deadband value to prevent continuous “blips”, but the first one would normally still be caught.
Historically I’d recommend doing this in the PLC with a timer. I’d still recommend that as a more robust option, but FactorySQL may be able to handle it well with SQLTags. Ideally, your scan class rate would greatly exceed the alert delay time. Sounds like a reasonable request to me.
n/m?
Deadbands only work with analogues, not digitals. I would agree that alarm handling should be done in the PLC where possible. Sometimes (as in this case) we are replacing part of a working system and don’t have that luxury. Also, we often use ‘dumber’ data acquisition devices which cannot carry out any processing, they only pass on the values as read.
This has been on the table for a bit- or maybe I should say under the table? 
But really, it’s a very good idea, and there have been a few people who have requested it, I just think that it’s gotten overwhelmed by other features so far. The truth is that we actually did a bit of work in the alerting system to make this fairly easy to implement, I think we just need to go back and get it done! Essentially the idea at the time was mostly that you may have conditions that are alerts, but that the can clear on their own- only necessary to contact someone if the alert didn’t clear in a given amount of time. Makes sense to me.
I will add it to the formal dev roadmap, tentatively for 4.2, which is scheduled for early February. If you have any other ideas in this regard, get them in now! (Although, I know there’s a lot that can be done for alerting, so try to have a bit of restraint 
)
Regards,
A “Time Deadband” feature has been added to SQLTags in Ignition.