When is data in KEPServerEX marked as bad? Can it be forced as bad?

Forum|Forum|2 years ago
August 11, 2023
3 replies
3597 views

The system that's currently logging historical data doesn't know if the data is bad or not. Communication to the device it's getting their data from is good but that device may not be talking to all the other devices it's gathering data from.

When the device we are getting data from thinks the data is bad it just maxes the value and doesn't leave it as last known. They then have all of their reports, trends, graphs, remove the high values from those requested from the current database.

Is there a way to have KEPServerEX mark the data with a bad quality code, when a certain value is read? So that the Ignition Tag Historian will know the sample should be excluded from data requests.

T

Tanquen

Author

12-Amethyst

Unfortunately while we have purchased many KEPServer licenses over the years for many different projects our last projects license expired 2 months ago so support will not answer the request for information on the issue.

I'm guessing support will not have an answer for this odd customer request anyway but it was worth asking. Maybe the next time we buy license from them, I can ask about it. 🙂

S

SlidingDownhill

12-Amethyst

Getting the OPC within Kepware to do it might not be possible, but can you create a script in your SQL server to look for that max value and then update the records quality tag value to 0? Schedule that to run as often as you need it to . Daily, hourly, just before a report.... whenever

Having said that you could just as easily remove or zero the records that have that max value.

T

Tanquen

Author

12-Amethyst

I did ask Ignition about that and they say you can change the values in the Historian table that they do not support it and it can break stuff.

"It is possible but highly not recommended as manually managing the tag historian table can break your trends/historian. However, this would be highly complex. To achieve this, you would need to follow how our tag historian works in the back end. The first query retrieves the Gateway and Tag Provider of the tag on the sqlth_drv table. The second query retrieves the scan class in sqlth_scinfo based on your tag in accordance with the first query's result. The third query retrieves all the TE entries that matches your your tagpath along with the scid from the second query. The fourth query retrieves the correct partitions table that matches your window time frame on the sqlth_partitions table. Lastly, the fifth query will look onto the partition table based on the fourth query's result and use the tagid's from the third query to retrieve the data. On the fifth query, you can alter this to instead delete the records that have a value of 'x' to fit your needs."

Others in the Ignition forum said there would be issues. "The query would have to handle history partitioning, etc". "Especially for tags that use analog deadband, as it will scramble the reconstruction of the "compressed" samples."

I was just hoping there may be a way in KEPServerEX to mark the values bad before the Ignition Historian got them. Not something many are looking to do I'm sure.

C

cmorehead