Buffer Ready Alarm for BACnet trends in MP/RP Controllers

[visi]

Hi, do you have any plans on adding Buffer Ready Alarms for the BACnet trends? I use the Swedish Library in SEAL.

[StefanLundin]

Hello. 
We try to add features as they are requested. Generally, when it comes to feature requests, we would like to have as much information as possible. Please provide more context about what and why.  Perhaps add examples of how you want to see the final result (screenshots or export file). In other words, more details about what you think is missing and how you want it to be set up. This makes it easier for us to implement a desired functionality.

[visi]

1. Example from a SEAL application (SWE) downloaded to a BACnet controller.

2. Example of a standard global application downloaded from BMS Applications to a BACnet controller.

It includes Buffer Ready Alarms to the BACnet Trends (marked in yellow)

3. This is an example of how a final result could look like from SEAL.

 

The Buffer ready alarm notifies the Extended Trendlog in ES/AS when it is time to fetch log data from the BACnet Trend log. A lot of FSR's don't know about this function/object, so i thought it would be a good idea to get them from SEAL :). I know it can work without buffer ready alarms.. But we are told to use them in different trainings and guides, especially in larger bms systems.

 

[Linus]

Hi @visi 

Interesting topic. Can you show me which binding do you use from the Buffer Ready Alarm to the Extended Trend Log? I cannot really see why this object would help.
Of course the buffer ready alarm is helpful to monitor if the extended Trend Log is collecting data.

But as far as I can see, it is enough to bind the BACnet Trend Log to the extended Trend Log. The extended Trend log collects the data without a buffer ready notification I think.

In the BMS help there is a topic.

It says that we only need Buffer Ready Alarm for external BACnet Trends

https://ecostruxure-building-help.se.com/bms/Topics/show.castle?id=5546&locale=de-DE&productversion=...

https://ecostruxure-building-help.se.com/bms/topics/show.castle?id=8632&locale=de-DE&productversion=...

[Jeff · Accepted solution]

Hey, friends!

The trending engine within EBO is intelligent enough to automatically move trend log samples from a child EBO trend log to an extended trend log in Smart log mode, but you're correct that this feature doesn't work for external BACnet trends.  This does include BACnet trend logs onboard our own SpaceLogic and EasyLogic (and b3) controllers.  For BACnet trends, EBO extended trend logs can still use the "Maximum transfer interval" to fetch log samples.  This can work well enough for external BACnet Interval trend logs, where we know the total time capacity of the trend log (sample interval X buffer size) since we can configure the max transfer interval to occur multiple times during the total time capacity of the trend log.

In contrast, when COV trend logs are used on SpaceLogic controllers, we don't know the total time capacity of a trend log...i.e. how long until it will start overwriting trend log samples.  It could hold multiple days worth of trend log samples for very stable logged signals, or for a very volatile signal, it could be toggling on and off every few seconds.  In the latter case, a maximum transfer interval of an hour or more could result in lost trend log samples.  Setting very short maximum transfer intervals results in additional traffic (and still may result in lost log samples for extremely volatile signals).  The BACnet solution to this problem is allowing a notification to be generated by the SpaceLogic controller to notify its hosting server that the trendlog is at XX% capacity of new trend log samples.  In this way, the server knows to fetch trend log samples as needed to prevent any trend log samples from getting overwritten by the FIFO queue used for the trend log buffer.  Hope this helps clear things up.

[visi]

Hi @Linus 

You mass select the BACnet trends in your MP/RP controllers that you have Extended Trend Logs added for, Right click -> New connected object -> Alarm, add a suffix or create directly. It binds automatically to the TotalRecordCount property of the BACnet trend log and to the Default Notification Class object. 

And yes the Extended Trend log collects the data without a buffer ready alarm.. 🙂

But without it you don't have a BACnet Notification Class object, that i think helps?

I've heard that it is important if you have a big customer site with many connected devices.

I see the BMS help you attached about external BACnet trends only, but all trainings and eLearnings says that we need it for internal BACnet trends aswell. I've talked with the BMS support who have helped FSR's in the past when the Extended trend log didn't fetch data from the internal BACnet trends, until you create a Buffer ready alarm. So i get a bit confused 😄

[Linus]

Hi @visi 
Thank you very much fur those helpful informations.

I am also confused now, but maybe its the best to tell our partners to create the buffer ready alarm then.

But to summarize, another disappointment that we have no intrinsic reporting / alarming for RP/MP products.

With intrinsic reporting and alarming, it would not be necessary to create additional objects.

[StefanLundin]

Thanks everyone for the great discussion on the subject!
It is now much clearer to me why and how we should add Buffer Ready alarms to the standards.
To summarize, we will explore the best way to include Buffer Ready Alarms for trend logs when an SEAL Design application is created for MP/RP devices.