CSI3 History Ext recording lots of records on alarm

#1

Hi,

We have been using the csi3HistoryExt for years (AX and N4) but have run into a problem that seems to be limited to N4, we are currently running on 4.2.36.34 with the current N4 version of the csi3HistoryExt from your downloads page.
We generally configure all the historyExts the same with 15min interval and COV increment of 0.05 (5%) and min cov time of 0sec (data centre project wanted to catch short evernts) and this is generally working.
When we have a history and alarm extension on a point we start to run into trouble, i’ll detail an example in a attempt to describe the problem;
BacnetBooleanPoint with csi3HistoryExt and a BooleanChangeOfStateAlarmExt.
The alarmValue of the alarmExt is set for “true” and time delays of 1min ON, 1min OFF
When the point value is false, history records are recorded as you would expect (every 15mins) however, once the point value goes to “true” a history record is recorded (once for the change of value as expected) and then again every 3-5seconds but but the record value and status are the same for each record. After the 1minute delay, the alarm status bit comes ON (expected history record is recorded) and then the records keep being recorded every 3-5 seconds while the alarm persists. Once the point value goes back to false (expected record recorded) the 3-5s recording continues, then after 1 minute delay, the alarm status bit turns off but the 3-5s records continue. At this point the status is {unackedAlarm}, the 3-5s records continue until the alarm is acknowledged in the alarm console - once acknowledged, the history returns to what we would expect, a record every 15mins until the point value changes again.
Ultimately the result is histories with millions of records that have the same value every few seconds.

Any insight would be great
Thanks in advance
Dane

#2

I have created a BooleanWritablePoint with the exact setup as described here but do not see this behavior. Could you provide a screen shot of your setup with all the extensions expanded so I can review to make sure I have the identical configuration?

#3

image

Screenshot 1/2

#4

image
Screenshot 2/2

#5

We have used your extension on dozens of projects without seeing this behavious before so i suspect the problem’s cause could well be something else in the station. Eitherway, the extension should not react like this.
Let me know if you need anything else.
Dane

#6

I am still unable to recreate this behavior so I think we need to rule out a few things on your system.

  1. Is this happening on every boolean point with an alarm extension?
  2. Does this happen if a boolean point only has a history extension?
  3. Can you create a non-network connected point with the same configuration to see if it happens?
  4. If you use a standard Niagara COV history extension does this behavior continue?
#7

I’ll check each of these cases and get back to you, thanks

#8

One of my colleagues has been looking into this problem, they didn’t follow your steps though - however i believe they have made a good find.

From below you can see 3 Boolean points, these are all the same point with the same alarm and the same history. It appears that when niagara runs through the components must execute the point and when it sees it is in alarm if the history extension comes above that in the code then it will write another record. If the history is below it in the code then another record isn’t written and performs as we would normally expect it to.
It doesn’t do it with a nullProxyExt point and doesn’t do it with a niagara COV so it is something in the CSI3 history code that is susceptible to this configuration.

Does this help any?

image