Historian Raw Float Precision
Hello!
We are trying to understand why we are observing a lack of precision in our raw float values. Our data source is Ignition with Cirrus Link MQTT. In most cases, the raw historian data—when viewed from the Historian tile—displays only 1-3 decimals of precision. There are a few instances where we observe 5 decimals of precision. In all cases, the values are stored as R4 (Ignition Float4/32-bit).
Upon examining the birth message, we identified one of the affected tags. Interestingly, the initial value in the birth message is capped at 3 decimals. It is unclear why this is happening:
{
"name": "Battery 1/Cell Voltage Average",
"timestamp": 1738825877285,
"dataType": "Float",
"metaData": { ... },
"properties": {
"engUnit": { "type": "String", "value": "V" }
},
"value": 3.621
}
We used a third-party quick client to subscribe to this tag in real time. This revealed that the value is actually precise out to 16 decimals:
{
"name": "Battery 1/Cell Voltage Average",
"timestamp": "1739931062394",
"isNull": false,
"properties": {},
"floatValue": 3.6440000534057617
}
Despite this, when viewing the same tag in the historian tile, it is still limited to 3 decimals, which notably matches the initial value in the birth message.
Curiously we see this pattern of matching initial value from birth message here as well:
{
"name": "Battery 1/Power Limit of Discharge",
"timestamp": 1738825877285,
"dataType": "Float",
"metaData": {...},
"properties": {
"engUnit": { "type": "String", "value": "MW" }
},
"value": 0.20193
},
And the historian data:
We are looking for some clarification on why this rounding/loss of precision is occurring, and whether it could be related to the birth message, the historian configuration, or some other factor.
8 replies
-
Hi ,
You would need to check the source of the data, whether it be Ignition or Cirrus Link. We're only logging what is passed to us in the data messages. We don't have any mechanism within the MQTT Collector or Historian to round or trim the precision.
-
Here is a more obvious example. In the screenshot below you can see our quick client subscribed to the same path and you can match the timestamps and see the value is the same but truncated, trimmed, or rounded to 6 decimals in Canary. (Historian is in Pacific, Quick Client in Eastern)
And as I continue to see, looking at the birth message from the broker, we have 6 decimals:
-
The SparkplugB decoder on MQTT.fx is not working for me. There are 4 options and I've tried them all. Meanwhile I think this is the format your devs are expecting to see?
This is from the Ignition (MQTT Engine) side, you can see the updating value with full resolution
-
I think the confusion is on the Ignition side how its showing us these values. We ran an isolated test and Canary is storing values as we literally write them even though Ignition is showing "extra precision" which I'm not really understanding at this point.