cancel
Showing results for 
Search instead for 
Did you mean: 
SOLVED

Real To LReal Conversion Accuracy

Real To LReal Conversion Accuracy

DCEN_Tony
Established Member

Is there a way to improve conversion accuracy when doing REAL_TO_LREAL conversions?

Example:

lrTemp:=REAL_TO_LREAL(rTemp);

real variable, rTemp = 84.38, the long real lrTemp= 84.379997253417969.

Is there a way to make lrTemp also = 84.38?

Many thanks

4 REPLIES 4

AndreasL
New Contributor

LREAL has double the precision versus REAL:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

Its just codesys that shows it abit strange in certain cases, but with alot of shown decimals you see that most of the decimals are the same in both cases:

AndreasL_0-1686655233758.png

Use %.2f in displays to show it with only two decimal points:

AndreasL_1-1686655424396.png

 

 

 

DCEN_Tony
Established Member

Thanks @AndreasL .

If I do a LREAL_TO_REAL conversion then I get values as in your example as expected but problem is REAL_TO_LREAL. 

The reason it is an issue is because I was writing to drive limit in motion app (Lreal data type) from a value on HMI (real data type).  When I set some values (e.g. 84.38 as real) this showed incorrectly in motion app (e.g. 84.379997253417969 within CtrlX web browser) so just think it is a little confusing.

I assume we would have same problem with target postions also where a conversion is done from real to lreal to suit the PLC Open function block inputs.

I guess I just have to change all the existing recipe and setup variables from real to lreal to ensure no confusion

Thanks anyway

It's actually not a incorrect value, 84.38 is not representable by IEEE754 floating point numbers:

https://www.binaryconvert.com/result_double.html?decimal=056052046051056

https://www.binaryconvert.com/result_float.html?decimal=056052046051056

But it's really really close in both 32bit and 64bit floats.

This is the reason floats are never used when dealing with currencies, floats are good for alot of stuff, but there is always a limited accuracy of them.

 

 

DCEN_Tony
Established Member

Thanks for the explanation.  In the end I decided for 2 decimal place accuracy and did following conversion in code to ensure value displayed same in Motion App:

HMI Real setpoint * 100...REAL_TO_DINT...DINT_TO_LREAL...LREAL/100.

Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist