Industry Online Support
Technical Forum
2/8/2008 6:37 AM  
Joined: 11/3/2007 Last visit: 5/17/2008 Posts: 3 Rating: (0) 
Dear All, I am working on PCS7 project with CPU 4174H. I am facing a problem in flow totaliser. I have attached two blocks in a sample project FB2Totaliser driver and FB3Totaliser calls. I have called FB3 in a CFC which is called in OB 36 with a cyclic intrupt of 1000ms.The problem i am facing is that the totaliser is not adding properly. Whenever my totalised valueis around20000.0then the totaliser is addingmore then normal and when the totalised value is around 40000.0 then the totaliser is addinglower then normal. But when the totalisation is started from 0.0 it is perfact. I have tried many ways like : 1. Calling FB3 in OB33 of 500ms and changing division factor in FB2 to 7200. 2. Calling FB3 in OB35 of 100ms and changing division factor in FB2 to 36000. 3. Giving a constant value in place of flow rate. But the problem is still there. Please give your suggesstions to rectify the problem. Thanks in anticipation. Regards Rahul Singhal AttachmentTotalize.zip (58 Downloads) 
2/12/2008 11:33 AM  
Joined: 8/11/2006 Last visit: 9/11/2016 Posts: 20 Rating: (2) 
Hi, Rahul. Your problem is that you are using the floating point variable (REAL) to store the value of your totalizer. This type can't be used for accounting purposes. Every time you make an addition, you introduce some error in the result. If two numbers that you are trying to add, are of different order (very big number such as 20000 or 40000, and very small number, such as 0.001) the introduced error is getting very high. For example, try to perform 16777210.0+10.0 with 32bit REAL numbers. You will get 16777220 as expected. However, try to perform 16777210.0+1.0+1.0+1.0+1.0+1.0+1.0+1.0+1.0+1.0+1.0, and you will get only 16777216 (that is 2^24). The reason is the internal structure of the floating point number (it has 24 bit mantissa). The floating point format can simultaneously represent very big and very small numbers, but you should work with it carefully to avoid such errors. I would recommend to use integer variable for accounting (try to count cubic meters, or liters, or milliliters, whatever your application requires). Best regards, Alexander. 
2/19/2008 7:26 PM  
Joined: 11/3/2007 Last visit: 5/17/2008 Posts: 3 Rating: (0) 
Dear Akorostel, Thanks a lot for replying to my problem. As you have suggested me to use an integer for accounting but for my application it wont be useful. Because i am totalising a variable flow (0 kg/hour to 60 kg/hour). The flow is an analog input and varying continously. Can you please suggest me some other way to remove the error. Thanks With Regards Rahul Singhal 
Last edited by: Rahul Singhal at: 19.02.2008 19:27 

2/20/2008 11:44 AM  
Joined: 8/11/2006 Last visit: 9/11/2016 Posts: 20 Rating: (2) 
Hi, Rahul. The best way to solve your problem would be to use flowmeter with impulse (or frequency) output. In this case you would only have to count the number of impulses and then multiply it on the constant coefficient. If you have to count the flow using existing equipment, you may try following algorithm (I did'n test it). For example, the current flow is 50.0 kg/h and your counting block is called once per second. Then 50.0 kg/h = 13.88889 g/s. The integer totalizer counts how many grams of product have passed through your flowmeter. The totalizer is increased by 13 grams (assuming that the flowrate is constant until your block is called next time). The rest, 0.88889 g, is stored in temporary floating point variable. On the next call (let's think that the flowrate is still the same, 50.0 kg/h), you count 13.88889 + 0.88889 = 14.77778 g is passed (current flowrate plus the rest from previous tact). You increase the totalizer by 14 grams, and store 0.77778 in the temporary variable. The totalizer calculation is integer, so it is completely errorfree (you only have to use integer variable of enough size to store large values). You will still have some floating point calculations (addition and substraction), but using numbers of the relatively same order, and so the error will not be so large. I hope this helps. Best regards, Alexander. 
Follow us on