0

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

null
    • smason
    • yesterday
    • Reported - view

    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.

      • srieger
      • yesterday
      • Reported - view

       Thanks for the response. That’s exactly what I described. Here’s another example showing the data flow from Birth to Payload to Historian. While the Birth message (for some reason) contains a rounded value, the Payload clearly does not. However, the final value in Canary is rounded to match the initial value in the Birth message.

      Additionally, we have another Ignition gateway subscribing to these same topics and receiving the full decimal value not rounded. An another quick connect client reading the protobuf payload and we see the full, unrounded float.
       

      Birth:

      Payload Example:

      Canary Historian:

    • srieger
    • yesterday
    • Reported - view

     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:

      • smason
      • yesterday
      • Reported - view

      Thanks for the information! I've shown this to development. There is still some discrepancy in your screenshots from the birth message to the payload. The birth message appears to be a SparkplugB payload, but the Payload screenshot does not. The tag names are the same, but the timestamp within the client does not contain the milliseconds. I'm not sure what client you are using to inspect the message payloads, but development asked if you can download MQTT.fx and subscribe to the same topic as what our Collector is doing (https://www.softblade.de/). We use it for troubleshooting purposes here and have found it to be really useful. You can get a 90-day trial I believe. They have a SparkplugB decoder within the tool that allows you to see the messages in plain text. We're curious to see what the values look like within that tool.

      • srieger
      • 22 hrs ago
      • Reported - view

       Yes I can use this tool and get back to you. The reason the payload looks different is because after being decoded with protobuf, I'm using a script to filter the data down to a specific folder path and provide some readable dates.

    • srieger
    • 21 hrs ago
    • Reported - view

     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

    • srieger
    • 12 hrs ago
    • Reported - view

    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.

      • smason
      • 4 hrs ago
      • Reported - view

      Ok. I can help you set up MQTT.fx if you'd like, but I think you may be on to something. Development is fairly certain it wouldn't be anything that our software is doing just because it doesn't have that capability.

Content aside

print this pagePrint this page
  • 4 hrs agoLast active
  • 8Replies
  • 21Views
  • 3 Following