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

[rleseberg]

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

[BenLoosli]

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.

[rleseberg]

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.

[dschenken]

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.

[rleseberg]

You are exactly correct on that, and I type in the 3 decimal numbers, but they still get truncated in the family table.

[dschenken]

I'm not certain why you want a 3 place value in the table to be rounded to some other value on the drawing. That's certain to cause problems if the model is used elsewhere as the geometry will be different from the drawing.

If it is important to do so you can create a parameter with 3 places and use a relation to set the 2 place dimension equal to the parameter.

For certain, Creo does not 'remember' what the value used to be. If it is changed from .125 to .12 it will be .120 when it is displayed as 3 places.

[rleseberg]

You misunderstand.

I have the default decimal set at 3.

I then set the dimension properties to 2 decimals, but CREO should still remember the 3 decimal number and round accordingly.

.125 set to 2 decimals should display as .13.

[BenLoosli]

According to ANSI Z210.1, your .125 should round to .12.

Maybe the designers of the family table routine follow this standard, but general drafting certainly does not.

[TomD.inPDX]

True, but rarely implemented.  Also a good question.  We did once get into the discussion with regard to dual dimensions (there the tolerance range of a secondary dimension is rounded to provide a lesser tolerance range).  PTC weighed in on that discussion with some good information.

Bottom line, something NASA may have started... "always round 0.5 to the nearest even number"

Personally, I don't like any rounding in CAD.  Limit features and fit tolerances are the one thing that requires some kind of standard.  PTC decided to give us a "maintain nominal" in limit dimensions.  I promptly turn this feature off too as it really can be dangerous.

[RWL]

OK, I finally heard back from PTC regarding the issue of decimals ending in 5 (.125, .675, etc) not consitantly rounding up or down for that matter.

I was told that there was, indeed, a bug that has been fixed, so that these decimals will always round up.

Accorcing to the representative, the expected result has always been for them to always round up, as, in my opinion, they should, especially since they do in every other part of the software.

I was also told that this fix has been implemented as follows:

Creo 3.0 - Build  M140

Creo 4.0 - Build  M030

Creo 5.0 - Build  F000 (Base Build)

Sadly, this doesn't help me at this point, as we are using CREO 2 - Build M090, and that is considered a retired version.

We will be going to CREO 4 within the next year, so I will have to wait until then to see if it has indeed been fixed.

If anyoue out there can try one of these builds and verify the fix, I would certainly appreciate it.

Roger

[RWL]

BTW, this was performed as PTC Case: C13699871.

[TomD.inPDX]

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.

[rleseberg]

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

[TomD.inPDX]

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.

[rleseberg]

I was at home sick on Friday, so I thought I would just through this out there to see if anyone else had experienced this particular issue. Now that I am back in the office, I have shown this to my internal support representative, and they are working on how to best pust this out to PTC.

[TomD.inPDX]

Thank you, Roger.  Please keep us informed.

[rleseberg]

Example Dimension = 6.125

Set to “2” decimals = 6.13

I finally called PTC support, and discussed the issue with the rep, and he did a quick experiment on his system to verify that the dimensions in the family table should, indeed, stay at the default decimal setting, in my case "3". This is true, even when the particular dimension has been set to "2" decimals.

On my system, when a particular dimension is set to "2" decimals, the family table also displays it as "2" decimals, and does actually truncate the 3rd decimal out of the dimension. Strangely, in most situations, the dimension is still displayed as "3" decimals in its dimension properties, and when displayed in "Edit" mode of the sketch, "Not Edit Definition" but simple "Edit", the dimension will be displayed as properly rounded up to 6.13, whereas the dimension when displayed on the drawing will be displayed as rounded down to 6.12, as if it came from the improperly truncated and rounded down version from the family table.

He had me to send him one of my family table parts and one of the drawings, and he discovered the same thing with my file. He also discovered, as I have on occasion, that the number would actually be truncated in the drawing properties window as well. He wants me to send him my Config.Pro file which I will do as soon as my IT support technician arrives.

Stay tuned,

Roger

[rleseberg-2]

Still no answer to the issue, but I can tell you this:

The PTC support rep was able to create a family table part with 3 decimal numbers like .125, .625, etc... in the family table.

When he edited these dimensions to 2 decimals, the family table still displayed the 3 decimal numbers, and he stated that this is how it is supposed to work.

The family table is not supposed to change the dimension, only store the entered dimension. These dimnensions then rounded up, as they are supposed to, when he entered them into a drawing.

Anyway, I sent him one of my family table parts, and he found the same issues with it as I did, and he was using the same build (M170) as I am, and he did not change to my cinfig.pro either. So than this is odd, that he can make a new part that acts correctly, yet on that same system, my part continues to exhibit the same buggy behavior as I found on my system.

He has set it to the developers to see if they can determin if this is a bug that has been corrected in a newer buid, or if it is a bug in the actual model file.

Stand by for further details...............

Roger

[dschenken]

Good update. I wonder if this is a defect in the data or if there is more than one family table interpreter. I have come across certain part features that have not been promoted to use the latest interface and Creo will use different software to redefine them. It will be interesting to know which it is.

[MaliDim]

you can try following set:

[MaliDim]

sorry, must be [.2]