1-Visitor

Question

Three decimal dimensions truncated to two decimals when entered into family table

Forum|Forum|10 years ago
April 22, 2016
20 replies
8358 views

Hi to all,

I am new to this community, and look forward to very positive communications here.

We are using CREO 2 Build No. M170.

First of all: This issue has absolutely nothing to do with Tolerancing or with Repeat Regions.

Since going to this build we have been experiencing rounding issues when changing 3 decimal dimensions to 2 decimal dimensions.

My default decimal setting is 3, and I am not changing this setting. I am changing the decimal by going into "Dimension Properties" of the specific dimensions, in either the model or the drawing, and setting the decimal to 2 there, leaving the default set to 3 decimals.

Several of these 2 decimal dimensions have been entered into family tables, and they show up as two decimal numbers, which I believe to be normal.

The problem is that the family table seems to be truncating the 3rd decimal completely, and then, in effect, the dimension ends up rounded down in the drawing rather than rounding up.

EXAMPLE: I am going to use the dimension (6.125") to illustrate the issue that were are experiencing.

When the dimension is set to 2 decimals,CREO will by default, round it up to 6.13, but the family table truncates the 5 altogether and the dimension is displayed as 6.12 rather than 6.13, and when converted back to 3 decimals will be displayed in the family table as 6.120, which will round down to 6.12 rather than round up to 6.13.

To further confuse things, some of these dimensions, when set to 2 decimals, will show up in the "Dimension Properties Window" as 6.12 and some as 6.125, but in either case, when the dimension is set back to 3 decimals, the family table will display the dimension as 6.120.

Thanks for any and all help with this most frustrating issue,

Roger

2D Drawing

B

BenLoosli

23-Emerald III

While my reply is not directly related to your question, it is indirectly, and an issue that PTC has never addressed.

When rounding dimensions in an engineering environment, there is a standard, ANSI Z210.1, that specifies how a dimension is rounded.

The standard says that all dimensions when the last digit is 5 shall be rounded to the even number: .135 -> .14 and .145 -> .14.

The reason behind the standard is to avoid accumulation of measure. Statistically half of your rounded dimensions round up and half round down.

As far as I am aware PTC does NOT follow this standard in their software.

R

rleseberg

Author

1-Visitor

It appears that PTC may have handled their family tables that way, as the numbers that I am having issues with are all numbers of type .125, .625, etc., with an even number as the 2nd decimal, and from the family table aspect of this issue, they are getting truncated down to .12, .62, etc.

The odd part of it is that the 3rd decimal, the 5, gets totally removed, "truncated", so I am not confident that the above has anything to do with this specific issue.

I am home sick today and not able to try an experiment with dimensions with an odd number as the 2nd decimal, such as .4375, to see if it would round up to .44, and if the 75 would get truncated.

Again, this seems to not be a problem until the numbers are placed in the family table. It is as if, when these numbers are displayed as 2 decimal numbers, in the family table, they loose all memory of ever having had that 3rd decimal at all. Again, it seems as if this doesn't happen in every case, although I haven't experimented enough to say that for sure.

D

dschenken

1-Visitor

I think the values you type in are substitutes for the values in the generic. Whatever the number of places are in the generic should be matched by the values in the instance.

T

TomD.inPDX

17-Peridot

There are a number of places where truncation actually takes affect. The ribbon dialogs are the greatest contribution to these types of errors. And yes, I consider this an error. However, PTC considers them to work to specification.

By default I set my config decimal points to 4. This helps in catching those times when truncation takes affect. I blame this on the ribbon development effort as there is no XTOP equivalent from Pro|E that could contribute to justifying truncating mathematical expressions in ribbon value dialog boxes.

Care to wager that your experience is also "working to specifications"? I suspect your issue is very much related to my experience.

Another solution I've found that works is to use parameters rather than hard values. Parameters should never be truncated (not true in Mechanism... but that's a different "issue").

I am also not a hard line user of family tables so maybe that is why I didn't know this. Thanks for bringing it up.

R

rleseberg

Author

1-Visitor

Thank you for your comments, and I will try setting my default decimal to 4, but I expect that when these dimensions are modified back to two decimals, that the family table will simply truncate the 3rd and 4th decimal, as it does the 3rd right now, and still in essence round down.

Again, as I mentioned in my opening post, it seems that this problem has shown up as a result of going to build M170. I don't remember having this issue with family tables before, but then I am using them more and more, and maybe just never ran into it before.

t is a true frustration at best.

For now, I will have to, per my example, just bite the bullet, and set these dims to .13, and .63 rather than .125, or .625 and be done with it, but I would still like to find out what is actually happening with these table.

I will do the experiment of setting some family table dimensions with odd 2nd decimals like .375 and .4375 etc.to see if they round up, per ANSI Z210.1 noted by Ben above, and I will let you all know what happens with that.

Please keep the comments coming.

Roger

T

TomD.inPDX

17-Peridot

Roger, have you reported this in a support case?

When you can put these problems together in an easily repeatable way, PTC will fix it. Having data erroneously change, and change wrongly to boot is something they do take seriously.

If I am understanding you right with the clarifications, you say that all family table dimensions (values not parameterized) truncate to the decimal settings.

If you do not have maintenance, or have no way to submit a support case, please do not let this go.

I do not have M170 loaded (still on M040 Creo 2). I will test this on Creo 3 to see what it does.

Bottom line, a straight answer on something this big can only come from PTC. They will investigate and provide an answer. If that is not sufficient, you can also escalate a case until you understand the issue and hopefully a workable workaround. It could be that rolling forward or backwards in the release is necessary.

I'll let you know what I find on Creo 3.