Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

REAL totaliser value truncation

Created by: cpender at: 10/4/2012 11:18 AM (8 Replies)

Rating (0)

Thanks 1

9 Entries

10/4/2012 11:18 AM	Rate (0)
cpender Posts: 13 Rating: (0)	Hi, I have a Siemens S7 319-3 PN/DP CPU installed on a customer's site for over 2 years. We have a pulsed digital input from an electricity meter. Each pulse respresents 200 kWh. So, there is logic in the PLC (OB35 every 100ms)that adds 200.0 to a REAL number(Elec_kWh) when it detects arising edge on thedigital input. This was working ok until a few weeks ago whenthe customer noticed that themonthlyfigures calculated in the PLC were different to those on the fiscal meter. I investigated and found that when I converted theElec_kWh REALnumber (currently approx 175,350,000 kWh or 1.7535 E08)to a DINT that it was only incrementing by 192 and not 200. This figure is trended on a SCADA system, so I checked back on the history and it looks like this started to happen once the figure reached 134,217,600 kWh. The next figure, which should have been 134,217,800 was in fact 134,217,792. This has resulted in a 4% difference in their reports compared to what has been billed (resulting insignificant financial implications). I have rectified this by using a DINT addition instead of REAL but the customer needs to explain and prove this error. What I need to understand is why this happens. The only plausable thing I can think of is that: 200 = 11001000 (binary) 192 = 11000000 (binary) Somehow the last 4 least signifant bits of the binary addition are being truncated. Can someone please explain why this happened? Please let me know if you require any further information or screenshots etc.
cpender Posts: 13 Rating: (0)	Last edited by: cpender at: 10/5/2012 10:17 AM Last edited by: cpender at: 10/5/2012 10:15 AM Last edited by: cpender at: 10/4/2012 11:34 AM
Suggestion To thank Quote Answer

10/4/2012 2:43 PM	Rate (0)
jacek d Platinum Member Joined: 9/23/2005 Last visit: 9/13/2024 Posts: 4697 Rating: (721)	That's because resolution of a floating point data format is decreasing while numbers increase (because of finite number of decimal places in mantissa). Simply speaking adding very small number to a very high does not produce acurate result.
	Regards, Jacek What is confusing you is the fact that you never see a number but always its digit representation. So you end up thinking that the number is the representation. - Andrej Bauer Any claims against me - based on whatever legal reason - resulting from the use of any code and/or ideas presented on this forum shall be excluded. #StayWithUkraine
Suggestion To thank Quote Answer

10/4/2012 3:18 PM	Rate (0)
manmeet Gold Member Joined: 1/3/2006 Last visit: 2/19/2024 Posts: 726 Rating: (71)	Hi All this problem stems due to fact that we have only 32 bits to represent a fractional number. In Step 7 these 32 bits are distributed like: 31st bit is Sign, Bit 23 to Bit 30 represents Exponent, Bit 0 to Bit 22 represents Mentissa. All this is then cubled together to represent a Floating number by using formula (IEEE Standard): Number = 1.m * 2 to the power of (e - bias) So all this leads to funny approximations. From step 7 Help: The floating-point numbers in STEP 7 are accurate to 6 decimal places. You can therefore only specify a maximum of 6 decimal places when entering floating-point constants. The calculation accuracy of 6 decimal places means, for example, that the addition of number1 + number2 = number1 if number1 is greater than number2 * 10 to the power of y, where y>6: 100 000 000 + 1 = 100 000 000. Your error started because of method being implemented to represent a floating number as said above.You have mentionedthat your problem started from 134217800.0 which after conversion got converted to 134217792, but everything was perfect 134217600.0. Fact is even if you try to convert 134217601.0, it will be represented as 134217600, so there is a error much before 134217800.0 If try to convert 134217640.0 then it will be converted without any error, again error will come at 134217641.0 !
	Last edited by: manmeet at: 10/4/2012 3:26 PM Some rephrasing and spelling corrections
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users Damayanti

10/4/2012 3:26 PM	Rate (0)
dchartier Grandmaster-Expert Joined: 9/27/2006 Last visit: 9/15/2024 Posts: 12282 Rating: (2683)	Hello cpender; As others have pointed out, your summations will all have a loss in precision due to the REAL data format. So you must change the structure of the program if you want to maintain an acceptable value in the totalizer. i suggest you think about keeping the present value of the totalizer in a known register, as an archive. Keep a register with the date-and-time value of the archive. Then reset the totalizer function and start anew, collecting data for a known period that is acceptable to you and the client, such as one, three or more months. Once that period is over, add this value (large enough to dissipate the precision error) to the archived totalizer, update the time registration, and start again: zero out the totalizer value, collect data for a known period, adjust the archived total value... Hope this helps, Daniel Chartier

Suggestion To thank Quote Answer

10/4/2012 3:26 PM	Rate (0)
fritz Diamond Expert Joined: 10/7/2005 Last visit: 9/15/2024 Posts: 3020 Rating: (1054)	Hello cpender and just in case the previous answers are not satisfactory enough for you or your customer, you'llfind the "official" Siemens explanation in the FAQ below: How accurately can I calculate with REAL numbers that are used in extensive formulas? I hope this helps
	Cheers fritz The advice and opinion given in this thread is that of the author and does not necessarily reflect the views of I S Systems Pty Limited. To find out how I S Systems can help you with your automation needs please visit www.issystems.com.au.
Suggestion To thank Quote Answer

3/12/2013 12:57 PM	Rate (0)
jkt_2 Experienced Member Joined: 10/23/2012 Last visit: 8/7/2024 Posts: 39 Rating: (0)	hello cpender can u post totaliser zip file please.. i am also working on the same procedure
	Last edited by: jkt_2 at: 3/30/2013 6:39 AM
Suggestion To thank Quote Answer

10/1/2013 2:24 PM	Rate (0)
Jens_app Gold Member Joined: 1/5/2011 Last visit: 6/15/2024 Posts: 815 Rating: (122)	Thanks for your reply manmeet, Can you explain why you quoted the following? manmeet If try to convert 134217640.0 then it will be converted without any error, again error will come at 134217641.0 ! How come the error will come at this number? Can you provide me a example why starting from this number calculation are not accurate anymore? If its onlya 6decimal accuracy, then I'd think the error would come even earlier? By the way, I added aconversion of the number134217640.0 to a 32bit single precision float number (IEEE-754 1985 floating-point standard). Anyone intrested to take a look and tell me if it's correct? Attachment Floatingpointno_IEEE745.zip (328 Downloads)
	Last edited by: Jens_app at: 10/1/2013 2:28 PM Keep it simple and on-topic. A simple straight-to-the-point answer is often of more quality than a complicated one.
Suggestion To thank Quote Answer

10/2/2013 8:55 AM	Rate (0)
BeVee Gold Member Joined: 7/18/2011 Last visit: 10/9/2023 Posts: 521 Rating: (91)	Hi cpender Maybe you can take a look at this FAQ about 64bit numbers. Kind regards, BV

Suggestion To thank Quote Answer

4/13/2017 2:55 PM	Rate (0)
Min_Moderator Platinum Member Joined: 9/3/2014 Last visit: 3/13/2019 Posts: 4767 Rating: (123)	New question published by norimane is split to a separate thread with the subject How to round REAL. Best regards Min_Moderator

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on