Skip to main content
M
mlocascio1-Visitor
1-Visitor
August 20, 2014
Question

Dimensioning Drafts

  • August 20, 2014
  • 52 replies
  • 81191 views
Pete Bokma,



Thank you for the suggestion. I think that what you are referring to would be A) A FAKE dimension on a drawing (if I went that way) or B) additional geometry in the model.



Please keep in mind that this draft is outbound. That may have some bearing on how it displays. Still, I would like to see a better way to display a draft dimension.



Michael P. Locascio



This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

52 replies

Show previous replies
R
rreifsnyder15-Moonstone
15-Moonstone
August 20, 2014
Actually that is not at all true. You can add annotation dimensions in the solid, and in fact many of the annotation schemes I have seen using 3d pdf’s and creo view use created annotations.

BTW, what good is any of this if you have to use STEP which does not carry model driving dimensions. We can talk when AP242 is fully supported.

Rob Reifsnyder
Mechanical Design Engineer/ Producibility Engineer / Components Engineer / Pro/E SME / Pro/E Librarian
[LM_Logo_Tag_RGB_NoR_r06]
P
PaulMailloux1-Visitor
1-Visitor
August 21, 2014
I like those 2 cents Jeff, great point with the Pro/Mold extracts… dimensionless



Paul Mailloux ▪ Program Manager



NyproMold, Inc.

144 Pleasant St, Clinton, MA 01510 ▪ www.nypromold.com
P
ptc-19327451-Visitor
1-Visitor
August 21, 2014
Its fun to see this topic come up again and again.  BTW, I also work with cavities, and copy-geom features and am in the Created Dims-OK camp.

In the Words of Star Trek's Dr. McCoy: "He's dead, Jim".
I think we beat this topic to death many times.


Christopher F. Gosnell

FPD Company
124 Hidden Valley Road
McMurray, PA 15317
PH:724.941-5540
FX:724.941.8322
www.fpdcompany.com
----------
D
DonSenchuk12-Amethyst
12-Amethyst
August 21, 2014
I always browbeat my users away from created dims if at all possible. This is especially true if they’re new users.

As Agent K says in Men in Black “People are dumb, panicky dangerous animals and you know it”.

People will engage in bad modeling practices if given half a chance. Maybe less than half a chance. (The best example in this thread has been making Set Datums part of other features (locators) – or the default datums! – which then requiring all other features to be touched when moving the Datum.) It’s not their fault if they were never taught a better way, but that doesn’t excuse their insistence on continued use of bad modeling practices.

People WILL also learn what @O does. That one thing, right there, should be enough to scare the bejesus out of anyone advocating to use created dims in favor of shown dims. Once a user learns this, they WILL start using it. And, in my experience, randomly. In all the companies I’ve worked at, the rework and scrap cost so much I could likely retire off the money wasted.

All that being said, there certainly are times when it’s OK or even necessary. Merged parts (a forging model into a machining model is common) into parts may require created dims. Sheetmetal may require created dims. External References may require created dims. I’m sure there are others where it is occasionally acceptable/required to use created dims. The thing is, I’ve yet to see any example where 100% use of created dims provides only positives and no negatives. Fact is, in my experience, the benefits of heavily skewing toward driven dims far, far outweighs the benefits of created dims.



R
rreifsnyder15-Moonstone
15-Moonstone
August 21, 2014
A few points on your response, as well as one from David Haigh. I didn’t say I make the first 3 datums my GTOL datums. I said I model to them. They are stable and you have the least to fear about features failing which to me is a greater danger when an inexperienced user is making changes beyond modifying a dimension. As David said, that leads me to recommending that the GTOL datums be created near the end of the model in ways that they can be changed without redoing everything. Of course that brings us back to the beginning, because if you make the GTOL datums last, then they can’t be used to create geometry and thus the shown dimensions are likely not useful.

My other point is whether something like a locator should be a GTOL datum. Datums must be related to the function of the part, usually something that functionally ties other features together. In the case I cited, the locator was an extremely important feature since it tied that part, as well as the entire subsystem, together. I have no issue with the selection of the locator as a datum feature, but rather with the philosophy that all features in the part needed to be tied to it.

Rob Reifsnyder
Mechanical Design Engineer/ Producibility Engineer / Components Engineer / Pro/E SME / Pro/E Librarian
[LM_Logo_Tag_RGB_NoR_r06]
D
dgschaefer21-Topaz II
21-Topaz II
August 21, 2014
“The thing is, I’ve yet to see any example where 100% use of created dims provides only positives and no negatives. Fact is, in my experience, the benefits of heavily skewing toward driven dims far, far outweighs the benefits of created dims.”

Funny, throughout this thread I’ve been thinking that in 18 years of Proe I’ve rarely shown a dim and can’t think of a time where I thought if only I have shown the dimension, I wouldn’t have problem X. Created dims allow me to separate modeling intent from documentation intent, which are not always completely aligned.

Most of my Proe career has been in molded plastics where the shown dim is likely to not point at any geometry after drafts and rounds are added. Additionally, the part isn’t made from the drawing, it’s made from the database and the database is God. The drawing is to communicate color, finish, material and critical dims for QC.

Mostly I’m just amused that this topic still creates such a debate. If you’re model accurately captures your design intent and your drawing accurately communicates what it should to those who need it (shop floor, QC department, etc.), that’s what’s important. To some degree, who cares how you got there. (I’m assuming that the created dims are not substituted with @O here. That’s another topic altogether in my book and a big no-no in almost every situation.)

--
D
DonSenchuk12-Amethyst
12-Amethyst
August 21, 2014
I have to revert back to the full quote: “A person is smart. People are dumb, panicky dangerous animals and you know it.”

I’ll readily admit that a person, in this case you, could potentially use 100% created dimensions correctly. But then we go to your last parenthetical, which is where I’m coming from. I do have a user in-house here that uses a lot of created dimensions. Because I know his skill level is very high and I know he won’t abuse @O, I leave my soap-box in the storage shed. When I have to address large numbers of users, shown dims is the way to go. Too many users in all my years seem to have this idea that simply changing the dimension with @O corrects all problems they can’t or won’t fix by editing the model. Even at companies that have rules to expressly forbid their use except when absolutely necessary, users being unable to figure out how to change even the simplest features fall back on “it was absolutely necessary for me to use an overwritten dimension.” Yes, it may come down to user ignorance or user laziness, but at the end of the day that doesn’t change the rework or scrap cost that could have been avoided. For quite a few people, there is never enough time to do it right [1], yet always enough time to do it over.

[1] Even if ‘doing it right’ means asking for help and learning the proper way and why of the matter.
P
ptc-19327451-Visitor
1-Visitor
August 21, 2014
The complexity of making unintended changes to a model is the biggest reason for using the @O option.

Back in the days of paper and pencil, this was allowed because the out of scale dim was underlined. This would be a nice feature to re-implement (I believe the ANSI/ASME specs may still allow it)

I believe Modelcheck can check your drawings to flag any @O dimensions and keep them from being checked in.

The trade-off then becomes the problems when CAD users complain that model XXX was created some time ago, is poorly documented/designed, and a change in the dim causes the whole thing to crash or turn inside-out.

BTW, although I use created dimensions I absolutely dislike @O overwritten dims. Maybe if they were underlined as noted above, and the underline could not be removed, this would be OK.



Christopher F. Gosnell

FPD Company
124 Hidden Valley Road
McMurray, PA 15317
PH:724.941-5540
FX:724.941.8322
www.fpdcompany.com
-----End Original Message-----
J
JonathanHodgson13-Aquamarine
13-Aquamarine
August 21, 2014
I’d like to propose one viable use for @O: using a dimension as a label, such as ‘Knurl this section’ (where the extents are clearly defined by geometry that is indicated by the dimension witness lines).

Of course, this may not be strictly supported by BS 8888 or your drawing standard of choice, but it can be unambiguous if used appropriately and, more importantly, won’t cause your model to crash.

Not that @O on its own can do so, as it can only be applied to a created dim…

Jonathan
D
DonSenchuk12-Amethyst
12-Amethyst
August 21, 2014
This reasoning gives me heartburn.

If one of my users makes a change to a dimension and it makes unintended changes to the model I would hope they would slam on the brakes and determine why that just happened rather than immediately resort to “I’ll just @O it and then everything will be great!” Otherwise we would end up with too many instances of the model not matching the print, leading to anybody downstream (assembly models/drawings, external refs, tool design, manufacturing, 3d capable vendors, etc.) creating bad parts. Or thousands of bad parts.

Yes, it is a real annoyance when one inherits a model with bad modeling practices. It’s also an opportunity to correct the mistakes at the source rather than just passing problems down to the next department.
Show more replies
Terms & ConditionsAccessibility statement