When I first started doing PLC programming, a billion years ago, we had the limitation of doing 4 digit math. It was expected to reset the carry bit just before an add function and to check it just after to make sure that the add function didn't exceed the 4 digit limitation. If it did, we would then take the carry bit and increment a second register to indicate the sum was more that 9999 (or FFFF). I see no problem in treating an 'overflow' bit the same way.
I understand the rounding limitations of floating point numbers. I think it would be a better solution to round up the smaller number in order to fit within the available bits left over from the whole number part of the sum. To do nothing, again IMHO, is a very poor solution.
Mr. Nachtwey,
The reason I am adding a very small number to a very big number is as follows:
I read an analog signal from a belt scale that represents 'Tons Per Hour' of material that is calculated by the scale control unit. I use the GSV values to calculate the number of microseconds that have passed since the last scan of the PLC. I then take those two pieces of information to calculate four values: 1-Tons Per 8 Hour Shift, 2-Tons Per Month 3-Tons Per Year 4-Tons Total Life Time Of The Plant (Note: The plant has only been in operation for about a month)
The Tons Per Shift Works Reasonably Well, but it would never exceed 800 tons (limitation of the mechanics of the plant). I noticed that the Tons Per Month, Tons Per Year and Tons Lifetime had all stopped incrementing a little above 8000.
Within a few days (hopefully) the communications between the PLC and the scale controllers will be operational. At this time, I will be reading the total accumulated tons lifetime value from the scale controller itself so all this is actually a moot point.
Also, yes, I could take the tons per shift that seems to be working reasonable well and calculate the other three values.
The logic that currently exists adds the tons per last scan into a subtotal, then, in one rung of ladder code, compares the subtotal to the value 0.1. If it is less than that, it does nothing. If greater, it adds 0.1 to my totals and subtracts 0.1 from the subtotal. Before enabling the changed code, I set the totals to whole numbers.
This gives me a reasonably good result for the time being. I did notice something odd though. Occasionally, the total is incremented by a value of 0.111 and not 0.1. Odd, but I am not going to chase that one right now.