Creo 4 isn't yet live at my company, but I've noticed a few worrying issues. Although the Datum Reference Symbols (I'm going to refer to these as "DRS" from here on) claim to be checking for duplicate names, there are actually three competing ways to create DRS's in the software, which do not cross check with each other. Namely
- Set datum annotations (i.e. 1982 style from a Datum Plane Feature)
- DRS created in the 3D model
- DRS created in a 2D drawing
Furthermore we've noted that a DRS created from a 2D drawing (i.e. a "draft" DRS) doesn't actually associate itself in any way to the model, much like how a draft dimension works. Since they're two "separate" entities, I can reason why it doesn't check its name with the model DRS's. At the same time, this easily leads to a case where a modeler designates a GTOL in a drawing thinking he's referencing a DRS that is true to the model, whereas it's actually a drawing DRS created by someone else that also happens to be on a totally different plane from the actual 3D DRS (which could be in another sheet and not immediately obvious from the designer's perspective).
Furthermore we've noted that while the name of a model DRS is connected to the datum field of the GTOL they're attached to, a draft DRS is kind of "dumb". i.e. if you change the draft DRS name, the GTOL datum field does not update.
Has anyone else run into these issues? Any workarounds or news from higher powers?
Quick answer is do not create or use draft GD&T datums.
There is a fourth one. Create a symbol that looks like one. I've also seen Feature Control Frames created as text notes.
The underlying problem is a people problem. While it would be good for PTC to settle on a method that resulted in one source of truth, there is nothing to prevent someone from circumventing any process.
I've worked with people who created fake tables for on-drawing BOMs rather than change the components of an assembly. Once that sort of thing is OK, there is really nothing to be done to prevent lesser conflicts.
I had worked in WF4 for years, and Creo 3 for a time before migrating to Creo 4, so I was accustomed to creating axes or planes in the model, designating them as datums, and showing or hiding them as appropriate (first option). There could be slight tedium when several lower-level datums also wanted to show up, but no big challenge. Then Creo 4 came and did away with the previous "Show/Hide" dialogue, replacing it with a very context-sensitive "Show Model Annotations." Often, the datum I wanted to show was not available to select. In comparison, adding a DRS in the drawing (third option) was very direct and straightforward. I agree that it is less tied to the model and therefore less robust, but by making the old method more difficult and making the new method very easy, it seems PTC is trying to encourage users to use the third option instead of the first. Because it's simpler to do and equally acceptable, I would not be surprised if more and more people use the third option instead of the first.
I agree that, in terms of 2D drawings, more people will use the 3rd option. Especially since the third option allows you to move the datum plunger around, instead of being locked to the surface.
What is worrying to me though is that this makes it harder for a company to move towards MBD/MBE, since the third option doesn't have that association with the model.
If the old style of designating your datums in the model was preserved, then I could see this making sense, since your drawings would be unaffected and Creo 4.0 allows you to directly add datum planes and other geometry to combined states. That would make using the model datums as the source of truth very intuitive for MBD, and sufficiently workable for 2D. I am confused where PTC is angling with this new style of annotating though, it seems at odds with their push for MBD.
I've been banging my head against a wall all afternoon trying to figure out how to get the new datum feature symbol to display "in dim" of a diameter dimension. Google has not been my friend. Any demo I've found starts with visible dimensions in the part. That seems to be a prerequisite to placing the datum symbol "in dim", yet none of them tell you how to get them visible. I basically came to the same conclusion that CP4 drives you to stop using GD&T in the model, delete any that exist, and re-create everything in the drawing. Having a mixture of part and draft content feels really uncomfortable coming from a Pre-CP4 background of using set datums, creating all the GTOL in the part, and showing everything in the drawing.
See if this video helps. Its one of the better ones out there:
Thanks for showing, but it doesn't address the issue. I've watched the video 4 times.
20 seconds in, it mentions "combination states". It doesn't explain combination states/annotation planes. If you didn't use combination states in CP3 and prior, Wildfire, or Pro/Engineer, is a combination state/annotation plane required use GD&T in CP4 and higher?
25 seconds in, the creator starts creating new driven dimensions. This is used multiple times in the video. It doesn't explain why he isn't showing driving dimensions. That seems like extra work. Also, the ideal state of a parametric model is having no driven dimensions / showing all driving dimensions, so the video demonstrates the complete opposite.
38 seconds in, it talks about adding semantic references to the driven dimensions. If you followed good modeling practices, this should be baked in to the underlying feature(s) that created the geometry.
...the ideal state of a parametric model is having no driven dimensions / showing all driving dimensions...
There is actually major disagreement on this point. PTC was going down one road and had to backtrack and add better support for both approaches due to uproar in the user community.
No combination states are not required
You can show dimensions or create dimensions ... it works either way.
Semantic references are useful for downstream customers. They get published to Creo View. So if you are using MBD and you click on a GTOL it will highlight all of the semantic references.