Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
Hi,
I have been thinking of this for a while.
When a dimension is required in modeling a part, I put a fractional number. For instance I put 15/32, is actually equal to .46875. It always been round into .469 since the default_dec_places is set into 3. That makes me have to type in .46875 to get 15/32, which is what I want. ( It is easier for me to input fractional number compare to a long decimal number)
My question: Is there any setting to make CREO to convert this fractional value without round it, or just simply keep it that way when it is input as fractional number.
This unexpected converter behavior causes issues when it comes to assembly.
Thanks
Solved! Go to Solution.
Hi,
CR2 M070, Part mode, number of decimal places 3:
When I enter 15/32, then I can see 0.469 displayed in graphics window. If I open Dimension Properties window, I can see 0.46875 value in Nominal Value field. When I enter =(15/32) [see https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS172437], the results is the same.
MH
You may check article at https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS21479
Thanks for your reply.
This is a case I definitely gonna encounter.
Hi,
CR2 M070, Part mode, number of decimal places 3:
When I enter 15/32, then I can see 0.469 displayed in graphics window. If I open Dimension Properties window, I can see 0.46875 value in Nominal Value field. When I enter =(15/32) [see https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS172437], the results is the same.
MH
That is a little known solution Thanks!
This answered my question.
If it can accept 15/32 or =15/32 as =(15/32) could make this more user friendly.
The reason I like to input 15/32 instead of .46875 is that less input and easier to memorize. Strict requirement of =(15/32) makes it less benefit of inputting fractional value.
This has always been an issue for me in Pro|E. If you enter a fraction in a feature dialog in the ribbon, it truncates or rounds... However, in some cases, it will maintain the double precision value whne data is entered elsewhere. Then you have mechanism features that maintain something short of single digit precision.
I set my precision to 4 places for all visual feedback. In cases where the arithmetic value is critical, I turn off rounding. If I need the fractional value, I make a relation where the fraction must be accounted for fully.
It would be great that when we create fractional values in -any- field, this equation would remain rather than solving it.
This issue has bitten me more than once.