Some people have a rule that SolidWorks drawings should not have overridden dimension values (Override values). I generally agree. Yet, there are several legitimate reasons to use Override values. One major reason is for proper rounding of linear dimensions for removed digits after the decimal. Currently, SolidWorks offers no option that allows the user to automatically round dimension numbers in a way that is consistent with current industry standards and practices.
Rounding rule for dimensions
On most computer systems, decimal numbers that have 5 as the last digit are automatically rounded up when removing a decimal place. For example, the number 1.425 rounds up to 1.43. This creates a problem. Most standards require that such numbers are rounded to the nearest even number in the last decimal place. For example, that number 1.425 should be rounded to 1.42, and 1.435 should be rounded to 1.44.
ASTM E 29 states:
6.4.3 When the digit next beyond the last place to be retained is 5, and there are no digits beyond this 5, or only zeros, increase by 1 the digit in the last place retained if it is odd, leave the digit unchanged if it is even. Increase by 1 the digit in the last place retained, if there are digits beyond this 5.
NASA’s Engineering Drawing Standards Manual states:
When the first digit discarded is exactly 5, followed only by zeros, the last digit retained (i.e., the digit preceding the 5…) should be rounded upward if it is an odd number, but no adjustment made if it is an even number. For example, 4.365, when rounded to three significant digits, becomes 4.36. The number 4.355 would also round to the same value, 4.36, if rounded to three significant digits. This procedure is known as odd-even rounding.
It is my understanding that this rule helps reduce statistical bias by allowing different numbers to be rounded up or down. Using the computer default rule (5 is always rounded up) only allows for the upward rounding of such numbers. This can create greater statistical errors, particularly when compounding rounded numbers to derive further rounded numbers.
Rounding as it affects tolerances
No rule is absolute. There are other considerations when rounding. A number should never be rounded so that it increases the original limits of a dimension. Although this rule mostly applies to inspection techniques, it can also apply to specification. For example, if there is a feature whose size limits are 1.255-1.275, the specification cannot be rounded so its limits are 1.25-1.28. In such a case where rounding occurs, the specification limits should be 1.26-1.27. Fortunately, this isn’t something that often occurs in mechanical design (though it does pop up when trying to apply dual dimensions).
Usually, rounding the limits is something that more often happens in quality assurance during incoming inspection of products. In such cases, Interpretation of Limits rule from ASME Y14.5 declares limits are absolute. For example, 12.25 MAX is the same as 12.2500000000000000 MAX. If the feature measurement is 12.2540, that measurement should not be rounded to 12.25, as it is still out of tolerance because it exceeded 12.25.
SolidWorks should support more rounding options
Right now, SolidWorks does offer one rounding option for dimensions. In documents options, there is a setting to round numbers to the nearest fraction, but only if fractional numbers are in use. I would like to see other rounding options supported, but not a document option. SolidWorks should have a setting added to the dimension PropertyManager that allows the user to establish a rounding rule for a particular dimension. For each dimension, users should have a choice to use the odd-even rounding rule, nearest fraction rounding rule (only when fractional numbers are in use) or always round 5 up rule. This shouldn’t just be for drawings. It should also be available in the model because they are often used as part of the product definition and because dimensions in the model can be inserted into a drawing.
For now, one can use Override values on the drawing. The drawback to this is that Override values do not automatically update if there is a change to the associated model geometry.
So, this sounds like this issue should be yet another Enhancement Request.