10/4/2012 11:18 AM | |
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. |
Last edited by: cpender at: 10/5/2012 10:17 AMLast edited by: cpender at: 10/5/2012 10:15 AMLast edited by: cpender at: 10/4/2012 11:34 AM |
|
10/4/2012 2:43 PM | |
Joined: 9/23/2005 Last visit: 1/21/2025 Posts: 4858 Rating: (741) |
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, |
|
10/4/2012 3:18 PM | |
Joined: 1/3/2006 Last visit: 2/19/2024 Posts: 726 Rating: (71) |
Hi
|
Last edited by: manmeet at: 10/4/2012 3:26 PMSome rephrasing and spelling corrections |
|
This contribution was helpful to1 thankful Users |
10/4/2012 3:26 PM | |
Joined: 9/27/2006 Last visit: 1/20/2025 Posts: 12330 Rating: (2702)
|
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 |
10/4/2012 3:26 PM | |
Joined: 10/7/2005 Last visit: 1/21/2025 Posts: 3032 Rating: (1058)
|
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 |
|
3/12/2013 12:57 PM | |
Joined: 10/23/2012 Last visit: 9/24/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 |
|
10/1/2013 2:24 PM | |
Joined: 1/5/2011 Last visit: 11/29/2024 Posts: 815 Rating: (123) |
Thanks for your reply manmeet, Can you explain why you quoted the following?
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? AttachmentFloatingpointno_IEEE745.zip (531 Downloads) |
Last edited by: Jens_app at: 10/1/2013 2:28 PMKeep it simple and on-topic. |
|
10/2/2013 8:55 AM | |
Joined: 7/18/2011 Last visit: 12/6/2024 Posts: 521 Rating: (91) |
Hi cpender Maybe you can take a look at this FAQ about 64bit numbers. Kind regards, BV |
4/13/2017 2:55 PM | |
Joined: 9/3/2014 Last visit: 3/13/2019 Posts: 4766 Rating: (122) |
New question published by norimane is split to a separate thread with the subject How to round REAL. Best regards |
Follow us on