Hello,
Can anyone clarify what the value for dataintegrity
should be in the case of a "Bad" value in the database?
According to the Ignition documentation on Quality Codes and Overlays, I believe it should be 512
. However, when I attempt to create a new QualityCode
using new QualityCode(512)
, it is reported as "Good".
Looking at QualityCode.VALUE_MAP
, I noticed that -2147483136
corresponds to "Bad".
Could someone help clarify this discrepancy?
Thank you
Marius
The highest 2 bits of the code indicate the Level.
There are pre-defined static fields in the QualityCode class you should just reference instead, e.g.
QualityCode.Bad
There's a helper function on Level you can use too, e.g.
QualityCode q = new QualityCode(Level.Bad.code(512))
So, would it be correct to simply retrieve the dataintegrity
value from the table, create a QualityCode
object from it, and then directly check if the quality is good or bad?
Iām thinking of something along these lines:
final int dataIntegrity = resultSet.getInt("dataintegrity");
final QualityCode qualityCode = new QualityCode(dataIntegrity);
if (qualityCode.isNotGood()) {
// Handle bad quality
...
}
Does this approach make sense?
Yes, assuming that's what is in dataintegrity
column. Try it and see 
Should the dataintegrity
value from sqlt_data_1_2025_01
be interpreted using DataQuality.fromIntValue(someInt)
instead of using QualityCode
?
I really need to confirm what dataintegrity
would contain in the case of a bad value.
Would "Bad" be represented as 512
in the table, or as -2147483647
?
In 8.1, the Historian system uses HistoricalTagValues
, which do use DataQuality
, not QualityCode
. It'd be best to go from the dataintegrity
-> DataQuality
-> QualityCode
by doing DataQuality::fromIntValue
-> DataQuality::getQualityCode
.
There isn't a 512
corresponding user code within DataQuality
. When storing the DataQuality
integer value within the 8.1 Historian implementations, the DataQuality::getQualityFor
method is used to determine the matching DataQuality
for the given QualityCode
(as part of the original QualifiedValue
). So, in this example, a Bad(512)
QualityCode
would return DataQuality.OPC_BAD_DATA
, which has an integer value of 0.
Use DataQuality::getQualityCode
when reading the data integrity value back out, and call DataQuality::isOpcBadData()
to account for bad qualities.
I do not think this would work.
The customer has in the table:
timestamp dataintegrity
------------------------------------------------------
16/01/2025 9:59:31.071 192
16/01/2025 5:56:30.637 0
16/01/2025 5:56:30.161 192
16/01/2025 1:53:29.456 0
With Ignition 7, dataintegrity = 0
would mean "bad data," but the customer says that in Ignition 8, dataintegrity = 0
would mean "unspecified."
If we use dataintegrity -> DataQuality
approach, we get "Bad Quality" for dataintegrity = 0
.
DataQuality.fromIntValue(0)
is shown as "Bad Quality".
DataQuality.fromIntValue(192)
is shown as "Good" as expected.
However:
- If we try
new QualityCode(0)
, we get "Good_Unspecified", which I think is correct.
new QualityCode(192)
is shown as "Good".
new QualityCode(193)
is shown as "Good(193)".
Do we perhaps need to use dataintegrity -> QualityCode
instead?
Thank you,
Marius
Sorry for the delayed response.
With Ignition 7, dataintegrity = 0
would mean "bad data," but the customer says that in Ignition 8, dataintegrity = 0
would mean "unspecified."
That isn't true. The quality code you see stored within the customer table is the same in 8.1 as it is in 7.9. A dataintegrity = 600
would be UNKNOWN
, whereas a dataintegrity = 0
is OPC_BAD_DATA
.
You're confusing the dataintegrity
value with QualityCode
, which this isn't; it is a DataQuality. An integer value of 0
for QualityCode
is Good_Unspecified
, but for DataQuality
it is OPC_BAD_DATA
. Again, all the integer values stored within the dataintegrity
table are the 7.9 DataQuality
. This was never changed to the new quality system for compatibility purposes.
Values stored within the history system are a HistoricalTagValue
. You can see here that the quality model used is DataQuality
.
2 Likes