False alarm triggering and misdata in dababase due to loss of precision of floating-point type data

[LeoChen]

Dears,

     as screenshoots below, when a simulated float transferred from kepware to thingworx, 1.2 turns to 1.2000000476837158, so a false alarm triggered. Misdata logged in influxdb as well.

• a simulated float which is 1.2 on kepware

• but on thingworx that turns to 1.2000000476837158

alarm triggered when property is above 1.2

• So a false alarm triggered

I can't change data restricted to external audit, what can I do to modify the data to the correct.

[Rocko]

Have you made sure that the value on Kepware really is 1.2 and not 1.2000000476837158 just being displayed as 1.2 in the Quick Client?

[LeoChen]

check property in qc, it is 1.2

Or try to write 1.2 to this remote tag on thingworx, value also turns to 1.2000000476837158

• write 1.2 to the tag
• 

   Then value turns to 1.2000000476837158

 floate points has the question.

[Rocko]

This is actually expected behaviour and a consequence of using float type in Kepware instead of double.

Check this article for reference: https://www.ptc.com/en/support/article/CS341193

https://www.h-schmidt.net/FloatConverter/IEEE754.html

To work around this, use double in Kepware or transform your variable in TWX with toFixed.

[LeoChen]

use Double or toFixed is not feasible.

1. use Double: data type from PLC is unable to change;
2. use toFixed: alert still use raw data, and this is not conducive to large-scale promotion.

[Rocko]

I haven't tried this but you should be able to configure the tag in Kepware as double without changing the PLC. Otherwise there are also Advanced Tags which could achieve the conversion.

For toFixed, it would mean you need a subscription to DataChangeEvent and you change the properties new value. This should be processed before the alert is created.

This is simply how IEEE754 works, when you put low precision content into a high-precision container. You can try to create a case with PTC support, not sure you will get a different reply. In any case, please post an update here how this was resolved.

To explain what happens: Floating point number are stored binary, so there is a limit to their precision. E.g.

let a=1.2;
// 1.2 with DOUBLE precision via https://www.binaryconvert.com/result_double.html?decimal=049046050
let b=1.19999999999999995559107901499; 
// it is EQUAL as they have the same binary representation
// this is the alert limit your value from kepware is compared to, 1.19something
logger.warn("a==b? "+(a==b));

// 1.2 with SINGLE precision via https://www.h-schmidt.net/FloatConverter/IEEE754.html
// this is the value you send in via Kepware as float
let c=1.2000000476837158203125; 
logger.warn("c>a? "+(c>a)); // no surprise, 1.20something is larger than 1.19something

[LeoChen]

Change data type in kepware as double dont sort out. 

DataChangeEvent may burden on the system as tag increase.

[LeoChen]

Thansk for your reply. There's variaty of tag in fact, some of them are double, some of them are float, some of them are dword, etc, but they are all number with js in thingworx which may lead to burden on system. So I report this to PTC.

[wcui]

@LeoChen The issue you report here seems to depend on multiple factors as below and finding a comprehensive solution is not easy. Please open a technical support case and share more details there so we can help you find a possible workaround. I will close this post later.

- PLC driver

- tag data type

- ThingWorx property data type

- Others (such as Kepware AdvancedTag, ThingWorx DataChange Subscription)

[TonyZhang]

Hi @LeoChen ,

It appears that the previous reply by Rocko answers your question.  For the benefit of other Community Members who may have the same question, it would be great if you could designate it as the Accepted Solution.

In the event that this response did not answer your question, please post your current status so that we can continue to support.

Thanks for using the PTC Community!

Regards,

Tony