cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

KEPServerEX LocalHistorian to not only store on value change

SOLVED
Guest

KEPServerEX LocalHistorian to not only store on value change

With great success is the LocalHistorian able to store values that frequently change value or state.

 

However, I'm having difficulties with the LocalHistorian not storing any values unless there is a change from the driver. As a result we have experienced data inconsistencies. For states that only change a handful times a month this creates a challenge, and in worst case we could miss a state change. At the source I see that the value is sent with a new timestamp every 30 seconds. My LocalHistorian scan rate is 1 second.

 

I need a feature that can force a new value storage at least every x seconds to be sure that all states are current.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Re: KEPServerEX LocalHistorian to not only store on value change

Hello!

 

Thanks for writing in. With the current features of the Local Historian, it is only possible to log data when the value or quality of the item changes.


The only potentially reasonable workaround I could offer you would be to, when you want to "force" collection of unchanging values, is to disable and re-enable the device object(s) providing the tags within KEPServer. This can be done via Configuration tool, System tags, or via the Configuration API (for system tags, tag addresses like <channelName.<deviceName>._System._Enabled.) Once your device is disabled, your tags will move to bad quality which due to the change in quality will cause them to be logged by Local HIstorian. From there, when you re-enable your device, the tags will move to good quality and the current value/quality/time will be logged.

 

This workaround comes at the expense of inserting unnecessary bad quality data updates into the Local Historian, but it is the only mechanism that could reasonably meet your requirements. 

 

We certainly value your feedback and will consider a future enhancement where data can be logged into the Local Historian at a static interval instead of only on value or quality change. 

 

Thanks, 
Sam

View solution in original post

5 REPLIES 5
Highlighted

Re: KEPServerEX LocalHistorian to not only store on value change

Hello!

 

Thanks for writing in. With the current features of the Local Historian, it is only possible to log data when the value or quality of the item changes.


The only potentially reasonable workaround I could offer you would be to, when you want to "force" collection of unchanging values, is to disable and re-enable the device object(s) providing the tags within KEPServer. This can be done via Configuration tool, System tags, or via the Configuration API (for system tags, tag addresses like <channelName.<deviceName>._System._Enabled.) Once your device is disabled, your tags will move to bad quality which due to the change in quality will cause them to be logged by Local HIstorian. From there, when you re-enable your device, the tags will move to good quality and the current value/quality/time will be logged.

 

This workaround comes at the expense of inserting unnecessary bad quality data updates into the Local Historian, but it is the only mechanism that could reasonably meet your requirements. 

 

We certainly value your feedback and will consider a future enhancement where data can be logged into the Local Historian at a static interval instead of only on value or quality change. 

 

Thanks, 
Sam

View solution in original post

Highlighted

Re: KEPServerEX LocalHistorian to not only store on value change

Hi @andyba.

 

If the response provided by @sam_kepware answered your question, please mark it as the Accepted Solution for the benefit of others with the same question.

 

Regards.

 

--Sharon

Highlighted

Re: KEPServerEX LocalHistorian to not only store on value change

Sam,



Thank you for your reply. I understand your work-around actually needs to bring the whole device down, and then up again? This would then mean to switch the device with all its configured tags, both where data are found with a mix of sub-second, and slow moving states changing once a day? I guess I could split on two different devices based on this categorization.



Then the question remains, how do I get an automated toggle of the device enabled every hour or so?





In any case, It seems far more robust and elegant to enable such a feature with the LocalHistorian product.



Thanks,

-André


Highlighted

Re: KEPServerEX LocalHistorian to not only store on value change

Hi André, 

 

To automate the toggle, you could:

 

1- write Python or Javascript that interacts with our REST-based configuration API to disable and reenable the device object(s)

 

2- write Python or Javascript and use an OPC UA toolkit to disable and reenable the device using the OPC system tags that I mentioned in my first reply

 

3- if you're using a commercial SCADA application, then similar to #2, automate the writes to disable and reenable the device object(s) and use the OPC system tags mentioned previously

 

4- buy our Advanced Tags Plugin and configure Link Tags and Derived Tags to disable and reenable the device based on a triggered condition, the triggered condition being the couple of times per day or more that you wish to "refresh". The trigger expression would be built within a Derived Tag where the Derived Tag would evaluate System Time Hour and Minute tags such that the Derived Tag would yield "true" when the expression is true. The Link Tag would then be triggered off of the state of the Derived Tag, and you'd have one link tag to disable (write zero) and another LInk Tag to enable (write true). You could use our free Simulator driver to provide source values of zero and one.

 

Let me know if further questions.


Thanks, 
Sam

Highlighted

Re: KEPServerEX LocalHistorian to not only store on value change

Hi @andyba.

 

If the responses provided by @sam_kepware answered your question, please mark the appropriate one as the Accepted Solution for the benefit of others with the same question.

 

Regards.

 

--Sharon

Announcements