Traditional periodic Trend type makes the end user set a very small sample time such that no sample is missed. This is a complete mis-match between what is happening at the tag level.
I propose a new Trend type that hooks into the Tag Subscription. It would be a "event" trend but wouldn't require the end I/O Device to be DRI enabled. E.g. it could just be basic Modbus driver. The Trend tag would only recieve a sample when the value changes on the Variable tag.
Guest
|
Idea business value
Better performance from the Trend System. Easier configuration. No loss of data from Variable tag to Trend Tag. The possibility for more compression of historic data (if tag value changes slowly). |
|
| Idea priority | 4 – Important to my company |
sorry missed the abbreviation DRI??
Modnet, BACnet = DRI?
It is easier to change the Driver to become a DRI based driver versus a new alarm type. The purpose of DRI based drivers are to take advantage to the Time-Based events (Alarms & Trends (Event Trends) as it uses the timestamp from the field and injects this upon value change into the underlying subsystem. All DRI based drivers support this today. The request should be for a specific driver to become DRI based and then this occurs as designed.
COV Trend. Asked for this YEARS ago.
PLEASE PLEASE PLEASE add this.