.0625 Rounding up to .063 in generic model, but down to .062 in Family Table

[rleseberg]

I am using CREO 2

---------------------------------

I posted a question on this issue back on Feb. of 2016, when working at another company, and we did contact PTC about it.

They were working on it, but I left there 3 months later, before it got resolved, and I have no good way to contact the old company, and frankly wouldn't want to.

So, here I am again, with the same problem, and posting again, just to see if anyone has anything on this.

---------------------------------

Just like the title says,

I have a dimension of .0625 that that is set, in properties, to 3 decimal places.

When I do and "EDIT" and check the dimension, it show .063, just like it should (.XX25) rounds up to (.XX3).

However, when  I enter this dimension into a family table, it rounds down to .062.

Further, the instance that is of the same dimensions as the generic(I do not use generics as an instances) says .062 as well.

OK, Now the really odd thing is that the drawing still shows .063 like it should.

I thought, at first, that what is going on here is that in the family table truncating the dimension, and then .0625 becomes .062.

However, this can't really be the case because, if so, the drawing would have to show .062 as well, because it gets the dimension from the family table instance.

Any ideas out there?

[rleseberg]

Amen Steven.

[rleseberg]

So, I received a call from PTC regarding the case that I opened.

The rep had his default decimal places set at 3.

He made a rectangular part, and gave the length and width dimensions of 2.235 and 4.245.

He then set the decimal places for those dimensions to 2, and I would have expected them the either round down to 2 23 and 2 24, or to fallow the round to even, as in 2.24, and 2.24.

To my absolute surprise, his both rounded up to 2.24 and 2.25.

I honestly don't know what to think about that.

What is did do, is to make a the simple example part shown below.

As you will see, it has :

6 Strong Perimeter Dimensions

1 Ref Length Dimension

1 Depth Dimension

The family table dis some odd things when setting these all to two decimals, as shown in the views below:

3 odd middle decimal perimeter dims rounded up to even, both generic and instance

2 even middle decimal perimeter dims rounded down to even, both generic and instance

1 even middle decimal length, and 1 (ref) even middle decimal length (both dimensions) rounded up to odd for generic, but down to even for the instance

1 even middle decimal depth rounded up, both generic and instance

Upon setting all dimensions back to 3 decimals places:

All generic dimensions went back to the original 3 decimal numbers

All instance dimensions were truncated to the rounded version of the instance with a " 0 " for the third decimal.

I couldn't figure why the two length dims went up to odd for the generic, and down to even for the instance, so I reset all of the numbers an did another test, removing the (ref) length dimension.

All dimensions acted as in the first test, even the length went both ways again, as shown below:

There seems to be very little consistency, but the round up to even and down to even appears to be somewhat in charge.

[swood]

Thank you for keeping us updated. Did the PTC rep have any input upon seeing what your example is doing?

[rleseberg]

I just sent it this morning, so I have not heard back yet.

I was able to attach the actual .prt file and the views shown here, but was not able to send my extended comments.

They allow 3900 characters, and I had over 1900 remaining.

[MartinHanak]

Hi,

Use Add Comment button on PTC Support Case page to attach extended comments.

MH

[rleseberg]

     "Use Add Comment button on PTC Support Case page to attach extended comments."

That is what I did, and it errored out.

I was able to Add a very short Comment to let them know that I was having trouble.

The .prt file and all of the view files uploaded, so that is good.

[MartinHanak]

Hi,

FYI if I want to send long comment containing pictures and text formating then I simply create Word document and send it to PTC Support as Case attachment.

MH

[rleseberg]

Great Idea

I don't know why I didn't think of that.

I have it in a word dock already, just to save it.

Off it goes.

[rleseberg]

Just an update to let you all know that, this is the third day since I sent the sample Family Table part, and all of that information to PTC, via the support case upload, and I have not yet heard back from them.

They did call me and go over a quick test over the phone the day after I initially opened the case, but nothing since.

I will, for sure, post here when I hear anything from them.

I have to say that I am still very confused but the following:

    A lot of users, here, seem to have these rounding issues.

    Yet when the PTC support rep did a test with, both, even and odd middle decimals, and ending in 5, they both rounded up, as they are supposed to do.

     Something seems fishy.

[StephenW]

Maybe you could test "out of the box" configuration. Remove all configs, don't use start parts and drawing templates.

Create a simple part, drawing, and table and see if it works as expected. Maybe there is something "odd" about your specific set up that is giving you the unexpected rounding.

[rleseberg]

That is not a bad idea, but as I mentioned, and as you know, many others have chimed in with having these rounding issues as well.

Be that as it may, how would I go about getting to an, out of the box, condition, without loosing all of my configs and such?

[StephenW]

What I do is I rename the config.pro files that load (temporarily) so they will not load. My preference is to simply add an "x" (xconfig.pro) so I can easily rename them back.

You can check your options to see what config.pro files load. Use the drop down arrow to see all the files and their locations

EDIT: also rename the config.sup file if you have one.

[swood]

Another way to do this is to make a new workspace first, and leave it empty. I then rename my Work folder (working directory) so that a brand new one is created. This way I know NO settings are carrying over. I then start Creo directly from the parametric.exe file from the install location. This should guarantee the most "out of the box" setup, with no chance of overwriting existing settings. When you're done testing, delete the new Work folder and rename your old one.

[StephenW]

This wouldn't work for me since the company has a config.sup and a config.pro in the "text" folder in the loadpoint of Creo.

It's important to know all the places the configuration files are loading from. If you only have a single configuration file loading, it'll be pretty easy.

[rleseberg]

Thank you Stephen.

This is very helpful, as always.

I have some things to take care of today, and will be out until next Thursday, so I won't be able to try this until then at least.

Have an awesome and safe memorial day weekend.

Roger

[rleseberg]

I went out for a few days last week, and have not heard anything since then.

I did get a couple of emails and calls from the PTC rep, prior to then and he assured me, at that time, that this has been sent on to their R&D group.

In the last call, I was finally able to get the rep to state that, as far as he knows, all numbers with decimals ending in 5 should round up, not down.

That is how his system was working, and he could not reproduce the inconsistencies that I was seeing, until, finally, when using my example file, he was able to see a number round down instead of up.

I pressed him again for PTC's stance on how numbers are to round in family tables, and he finally had to admit that he wasn't absolutely sure, and that he needed to get a definitive answer from R&D.

I will post back when and if I hear anything further.

[mender]

Or perhaps I will.  Confirming this was reported to PTC as an SPR, and has since been investigated.  The cause is that the family table is using standard sprintf() behavior for displaying the numbers, which rounds strictly from .xx5, which can lead  to numbers believed by the user to be exactly .xx5 (but internally +/- a tiny tiny fraction) to behave inconsistently.  The fix is to apply the same formatting to fam tab as is done for the dimension display, where values deemed to be 'pretty much exactly .xx5' are rounded up.  Current plans are to have this fix in Creo 3 M140, Creo 4 M030, and Creo 5 F000.  Caveat the lesser, the fix is not yet completely finalized+approved, so this is not a firm commitment.  Caveat the greater, I am not touching the broader argument with a ten-foot pole.

[dschenken]

It's a sort of a rule that it is considered better to be consistent than to be right. Consistency is much easier to demonstrate.

How unusual that one of the printf()'s is at the bottom of a problem. Is there a scanf() nearby to complete the set? Also I read ACM Risks and Stackexchange too much.

[RWL]

I posted this a couple od days ago, but do not find the post here at all. I don't know what happend.

Well anyway, I did finally hear back from PTC regarding this "Rounding In Family Tables" issue.

BTW, the case number for this issue is "PTC Case: C13699871".

Re rep told me that PTC R&D did find a bug and that it has been fixed and implimented as follows:

Creo 3.0 - Build  M140

Creo 4.0 - Build  M030

Creo 5.0 - Build  F000 (Initial Base Build)

Sadly, we are still using CREO 2, and build M090, so I will not be able to verify that this has actually been fixed.

If anyone out there is on CREO 3 of CREO 4, and could bump to the build listed above, and verify the fix, it would be very much apreciated.

Roger

[StephenW]

I think you posted https://community.ptc.com/t5/Creo-Modeling-Questions/Three-decimal-dimensions-truncated-to-two-decimals-when-entered/m-p/477700#M111422

[RWL]

Your are absolutely correct.

That was the thread that I had going the first time around, when I started a defferent case, back at my old company.

I was layed off a couple of weeks later, and was not able to continue the corrispondance with PTC.

I got confused when I searched here for this thread, and ended up posting the results over there instead.

Oh well, it got posted in both places, so I guess that is not a bad thing.

[StephenW]

You can see your posts (author or participated in) in your profile if you click your avatar. That's how I found it quickly.

[BenLoosli]

Roger,

I will note that your "Yet when the PTC support rep did a test with, both, even and odd middle decimals, and ending in 5, they both rounded up, as they are supposed to do." comment is not what Z210.1 says should happen with dimensions that end in a 5 and how they are rounded. To average dimesion creep, dimensions ending in a 5 when rounded to 1 less digit should go to the even number.

Like it or not, the code in both Creo and Excel should be following the standard for how dimensions are to be rounded. There have been many instances where enforcing standards has changed the dynamics of how we look at parts and drawings, but we need the standards enforced to be consistent in what is being presented. The cases of the same 3-place value ending in 5 sometimes rounding up and sometimes rounding down  when changed to 2-place is a joke. It needs to be consistenetly presented in the same manner to everyone in everyplace.

[rleseberg]

    "I will note that your "Yet when the PTC support rep did a test with, both, even and odd middle decimals, and ending in 5, they both rounded      up, as they are supposed to do." comment is not what Z210.1 says should happen with dimensions that end in a 5 and how they are rounded.      To average dimension creep, dimensions ending in a 5 when rounded to 1 less digit should go to the even number.

From everything I have seen, I can't say with any certainty that PTC has implemented the Z210.1 standard at all. It certainly doesn't seem to apply anywhere outside of a family table.

FOR EXAMPLE: If I do an edit of a part with a bunch of 3 decimal dimensions, all ending in 5, with an even mix of even and odd middle decimals, they all round up. They also show on a drawing all rounded up. The only place that I see the "haywire" rounding concept taking place is inside of a family table, and it is inconsistent at best. It the Z210.1 standard was in place, why not in all parts of the program, why only in the family table?

No, I am of the opinion, albeit unproven, that whatever is going on, in these family tables, is something else altogether,

    "The cases of the same 3-place value ending in 5 sometimes rounding up and sometimes rounding down  when changed to 2-place is a joke.      It needs to be consistently presented in the same manner to everyone in everyplace."

I maintain that any decimal dimension, ending in 5, should always and forever round up, not up for odds and down for evens.

At very least, there needs to be the choice to set it that way.

I simply have no reason, in the universe, to care about dimension averaging, so rounding odds up and evens down does nothing for me other than to make my head hurt.

On the other hand, it seems that there are those who do care do care about dimension averaging, so for the cost of this software, it would make sense to give the users the choice to set either way.

Again, as I have said before, as old and supposedly mature as this software is, this has to have been an ongoing argument for a long, long time.

Just fix it already.............