I am trying to gather some best practices documents to distribute in my company. The main reason for this is that we have many designers who are, quite frankly, terrible at using Pro/E. This is primarily due to a company culture where the older designers who are bad at using Pro/E teach new designers how to be bad at using Pro/E. This cycle continues over an over until you have terrible models/drawings with problems such as:
1. Sketches with no strong dimension or constraints. One wrong move and you blow up the whole sketch.
2. Plates with holes that are created using a revolve rather than the hole tool or an extruded cut.
3. Sheet metal parts that are modeled as a solid, shelled, and roundeded (never converted to an actual sheet metal part).
4. Layers that are an absolute disaster. In many cases designers will hide features/datums instead of putting them on the proper layer and hiding the layer.
5. No concept of simplified reps. They try to do pretty much everything in the Master Rep and can't understand why it takes half an hour to load a model.
6. Hydraulic hoses and tubes that are created without Pro/Piping which means that useful information can not be extracted from the models.
I have been asked to help remedy this by providing tutorials showing what is accepted as the best practice for several of these issues. The problem is that I have very limited time to work on this so I would like to gather as many as I can from internet sources. If anyone can provide links to best practices documents or send them to me directly, I would be very grateful.
When I Shifted from Solidworks to ProE, I am also feel ProE was very terrible software.. But now I'm enjoying with ProE.
My suggestion for your guys is compare modeling and drawings techniques with other CAD softwares.
Below links are more usefull for you.
Thanks & Regards,
Naveen Kumar Gongu.
The best I've seen is to put a check function in the process. First develop the policies and procedures to the needs of the company and then have a responsible person to enforce those policies. After a while, everyone will be doing things the same way.
There are few best-practices; there are some methods people have chosen for consistency in model development. I don't think documentation is the solution.
Working with parametric modeling is very similar to software development. The biggest difference is that software development is known to be a cooperative endeavor for anything but tiny projects. It entails code reviews, comments, other people understanding what was written and why it's that way, at least ideally.
In parametric modeling the same factors are still in place, but the discipline often isn't. Users often treat the part they are working on as somehow separate. I've had users feel it's too difficult to redefine a sketch for a feature and just delete it, replacing it with another feature - and thereby destroy multiple levels of assemblies and drawings, because they don't get how the interrelation that allows parts to accurately fit together has anything to do with their work.
To extend AD's response: The only way for consistent practices to work is to start with one user responsible for all the models - that is, they get to say if the models are acceptable or not, and if not, either they fix them or the person who made the model gets to redo the work. As a number of vetted works builds up, users will see more examples of what's done right, or at least what is consistent usage. Eventually it will become the norm.
The selection of that person is a critical one. It has to be someone who is capable of understanding what the models are supposed to do, be able to accomplish that within the limitations of the software, and be able to justify why their method is enough better or more useful to make the change. It is very helpful if they know how to easily teach others all of these.
The critical part is that management has to be willing to sanction users who won't or can't get the hang of it or absorb the cost of re-working the material, and also be willing to understand the risk that their go-to guy is the wrong guy for the job and work on making sure the management evaluation of that user is a useful one.
Before adding policies and prodedures, start by reviewing a few hundred models and drawings. Collect the concepts that seem to work, including down-stream CAM and other efforts. Look at those concepts that are painful and understand the circumstance that led to that. Example: the revolved cuts. It's a single feature that can be redefined to be a c'bore, or with countersinks on one or both sides, or include a snap-ring groove, at any time while losing the least info when redefined. Perhaps it was done before hole features worked - they used to really stink big time. Knowing why a feature is used in a seemingly odd way will go a long way to developing a consistency.
You might consider ModelCheck as well to weed out some of the more interesting methods of forcing invisibility on parts and features that few others would think to use. Like creating a feature to fill or completely remove another feature. Or using simplified reps to control assembly configurations so that the assemblies can't be found in Windchill. Which reminds me of a great trick. Doing a save-as on a drawing of one part, removing all the views from the copy, but not the models, and adding a different part. I've seen this done where a bracket is placed on a drawing of a complex assembly. Nothing like expecting two items in a workspace and getting a few hundred. Good times.
Here's one I consider to be a good practice - create the location dimensioning scaffold before creating feature driving geometry. For example, on an extruded hole I'll use construction lines aligned to part edges and crossing where the hole will be and create dimensions to them; not to part geometry or to sketched curves directly. Then sketch the circle at the intersection. Why? If/when the decision comes to make it a slot, nothing else is affected but the outline. The locating dimensions shown on the drawing, with all their settings, will be unchanged. If I copy the sketch, all the dimensions come with it and merely need to align to a new location. If I'm really after some permanence, I'll include a sketched axis point that has a dimension that can move it off center. This way even when converting from circle to slot, mating hardware aligned to that axis won't be affected -and- if changed to a slot, I can move it independently and see the effect in using assemblies. Circular hole to straight slot to curved slot and next assemblies work fine.
All of which is a bad practice if designs never change from circlular holes to slots and no one is ever concerned that hardware may move off center during assembly.
Here is a list that I created based on some documents that were passed around the ptc-user group.
A monthly proe users meeting would also be useful. The company pays for lunch and the team discuss tips, tricks, good practices.