on 02-23-2017 08:38 AM
I have been introducing PMI at my company for thelast coupleof years.
One of the main topics that I am facing is how to document a change when using only 3D model with no drawing. With a drawing we put change triangles on the drawing and this quickly denotes where the change happened.
Without the drawing if a feature is removed for example, how do you show this?
Do you use viewers and show differences between the models? maybe JT comparison? do you change the PMI dim color, put them on different layers, copy to a change view? Etc.
These are the types of questions I am looking for.
I am looking for information on how other companies are handling this.
Any help would greatly be appreciated.
on 02-23-2017 08:50 AM
What we did wasn't related to GD&T but to design changes. In the 3D CAD, you can make a list of notes that listed the changes made. Similar to how a drawing would list changes at the top note, they wouldn't be required to displayed or shown in the CAD.
Second, we would show the changes made in Red. Now, this doesn't show features that are removed, but there you can show if a feature changed sizes or direction, etc.
In addition, you could extract the removed features, move them into a new group and then show them in different layers or views.
If a feature was removed, we would at least take a screen shot of the old and match it with the new design change, or if there were multiple iterations to test.
Just some suggestions.
on 02-23-2017 09:03 AM
We have been working with PMI and MBD for the last years and have applied a methodology where we create a Model View named "Change Description" where we inherit the changed/added PMI's. We also attach a "Change Note" underneath every changed/added PMI where we describe the change. It could for example be "Dimension was 43,5 mm".
For deleted/removed PMIs and geometries there is no PMI to inherit so here we just add a Change Note pointing out the updated area. It could for example be "2x holes removed" and two leaders/arrows pointing out where they have been located. This would be enough for us, since we always document the older versions, so if you have the change note and the old version it would be hard to misunderstand the change.
Hope this was useful for you!
on 02-23-2017 09:06 AM
on 02-23-2017 10:51 AM
In my company, we annotate the changed feature, callout, or general area, with the Drawing Change Notice identifier. Descriptive language, like ADDED, RELOCATED, REVISED and REMOVED are used to describe the change as necessary (e.g., DCN A: flange removed this area). The annotations are all created on a single layer that is categorized with the Engineering Change Order number. We use layers, but you could just as easily organize the annotations into a group, or a view. Only the differences between the current model and the immediate previous model are annotated. All prior ECO/DCN references are removed from the model. We include only the current model definition in the model.
on 02-23-2017 11:42 AM
I'd like to suggest a different tact. Question why there is a need to annotate/higlight individual changed features within a model. What purpose does that have? Is there some downstream user that needs that type of clarification within the model itself? Does it help the Designer? What requires this practice?
I would suggest breaking away from traditional 2D Drawing type practices.
Just wanted to put this out there for discussion on this topic. Developing new processes and implementing, especially ones that eliminate non-value added activity/effort positively impacts the bottom line. But quite often it can seem painful initially getting everyone to let go of long held assumptions without truly knowing why those practices are followed, or not considering advancement of technology like MBD and PMI and how those interplay with other related practices...
on 02-23-2017 11:47 AM
on 02-23-2017 12:04 PM
It's always interesting to question the origin of some traditional work methods, and I'm pro doing that .
In this case, I believe it's important to document the individual changed feautures for the manufacturers. In our long development periods, we constantly experience last-minute changes and unexpected turns in the development. This means that the manufacturers have often started with the CNC machine programming, and if we then send them a new file, they want to easily see what is updated, if they need to re-do the whole program or just a part of it.
And if the changes are very small, it can be tricky if you have two prototypes with different versions to know which one is which, if they are not marked/labeled. A change history can then easily help you.
A change history also gives some kind of design history for products with a long life-cycle. By looking into the history, you can figure out some of the design decisions that was made on the way.
on 02-26-2017 12:00 AM
I would say BCT Inspector is a very powerful tool. You can use it for 3D models as well as drawings. Even you can compare the JT of two different revisions. Most thing I like about it that, Whenever you can create new annotation,delete,modify or simply change the position. BCT Inspector shows the status of all which becomes very helpful to understand the changes clearly.
on 02-27-2017 10:26 AM
Hello Jessica, I'd like to point out that all CAM programming that I'm familiar with, it's very easy to determine whether a CAM program matches the latest Design Revision Model and identify those Features which are not matching the Master Engineering Data and make changes to the CAM accordingly. If you have CAM programmers redoing a complete program for a simple set of Feature changes, I would look into getting someone else to do that work.
Same type of review between Revisions can be accomplished for Design Review as NX has a very powerful CAD Model comparison capability.
The Change History is usually documented on the Change Documentation which should describe the intent and reasoning for the change which would be truly effective from a historical perspective.
Relying on Change Documentation within the CAD Model seems a strange place to want to input that data as it's really somewhat hidden within the model in my opinion.