General Procedure Question

For those of you that work in larger groups (more than 3) do you have any procedures that define how an assembly is to constrained/mated etc?

Do you use mates for position only or to check design then suppress?

Do you mandate a fully constrained assembly?

Do you leave it up to the descretion of the designer?

What I am getting at is how do you define in a procedure that designers should not be spending an inordinate amount of time constraining/mating things that later end up blowing up your model or just being a waste of time.

thnks for any input.

Steve R

Reply to
Steve Reinisch
Loading thread data ...
1, Never have three of the same type of constraints, on any one part or sub assembly.

2, All fully constrained, even toolbox parts, before placing in Pdmworks All limit mates suppressed. These limit mates are always put in to folders and the replacement fixed mates are also put into folders, making them easier to find. Otherwise the assembly always wants to rebuild upon opening.

3, The designer gets a thick ear otherwise, lol.

I don't know why, but it has saved a lot of headaches and seems to work better, when replacing a part or sub-assembly.

Reply to
pete

I am the one responsible here for the SW installation, and my policy has generally been that I don't mandate something unless it's absolutely necessary. One example is that all of our various drawing templates have the title block info tied to properties - one stop shopping. Thou shalt not change stuff IN the title block except for unusual circumstances.

Now, that being said, I feel that no two people work alike, and since most of our projects are just a few people at a time, I don't enforce many rules. I personally don't fully constrain the rotation of hardware unless it's necessary in real life - why spend the time & processing power for the unnecessary mate. Some people don't want to see any minus signs. Some people prefer configs, others prefer one part per file to make sure they don't screw up another part. Some use in-context, others hate it. I figure that if you let a person work the way they choose, **within reason**, they will be more productive.

Does it cause problems? Sure, sometimes when you try to figure out what that person did. But for the most part around here, it's not too bad.

I also ask them to watch for repetitive operations such that maybe I can automate at least a portion of it. I always figure that if I can show them that my way will make their job easier, they are more likely to use it. And that same thought drives me to be better at what I try to implement to improve the efficiency of the whole department.

WT

Reply to
Wayne Tiffany

I agree for the most part with Wayne. I might set up a set of "best practice suggestions", recognizing that what works great in some situations is a really bad idea in other situations. For example, in general, I like working with assembly layout sketches, but if you are using dynamic assy motion for visualization or animation, you can't do that unless you have a config that suppresses mates.

Configs are also a great idea, but it only takes a couple of slip-ups to fubar a config, so design tables are often a great way to go. Some configurable parameters cannot be driven by design tables. Everything is a trade off, there are no perfect answers.

Fully defining parts that have in-context relations should be mandatory, and making in-context to moving parts is often a bad idea, but if you have a single instance used to make all the in-context relations, and another instance of the part used for motion, that is ok, but again, it may be difficult to manage if you don't know what's going on.

The stuff that is really important for groups to be doing together is the File Management stuff - how you name and store your files, especially revisions. Also, getting Toolbox to work with a group without causing problems can be a little tricky. Those are things that really do need to be standardized right up front, without any wishy-washy variations.

I think fully constraining assemblies is sometimes a waste of time. There have been suggestions that underdefined assemblies take longer to solve. This is possible, I haven't done any research to verify or contradict this, so I really don't know. Rotationally defining things like pins and set screws can work for or against you, but I think it's more likely to work against you. Having too many open degrees of freedom can make dynamic assy motion jerky and unpredictable (could be caused by a poorly defined pin), but using a plane to constrain a bolt from spinning can cause other problems which may be difficult to visualize immediately.

Also arbitrary rules like "never have three of the same type of constraints, on any one part or sub assembly" don't really get at the heart of the problem and can force people to go way out of their way. For example, is that talking about 3 "coincident" mates of any type or 3 "plane to plane coincident" mates? I regularly mate the first part of an assembly to the assembly planes instead of using the Fixed condition because, well, just because. I don't know why. From a degree of freedom analysis point of view, that's a really bad idea, because a plane to plane coincident mate constrains 1 translational and 2 rotational DOFs, so 3 of those mates constrain 3 trans and 6 rot DOFs, making you overconstrained by 3 rot DOFs. SolidWorks still deals with this somehow, but technically it shouldn't work.

All that to say that the arbitrary rule is not specific enough, but requiring a DOF analysis is too specific. Talk about wasting time! Then you'd have to find out somehow just what kind of DOF overdefinition SW can tolerate and what it can't. And then make sure that everyone follows it. Good luck. I don't know of anyone who does this. Not even me unless I'm troubleshooting something that usually works but in some specific case doesn't work.

Anyway, Wayne I think had it right. Let people work the way they like within limits. Don't let people design assemblies as multibody parts unless it makes sense and the rest of your team can work with multibody parts. Use common sense when it comes to in-context or some of the trickier functions like move face or heavy surface modeling.

If you get crazy with too many rules, the rules may need to change for each project. I say stay flexible, and use the energy you would have used on enforcement instead on educating your designers so they can handle anything.

Reply to
matt

Everything Wayne and Matt said... :-)

We run with very few rules, custom properties to populate the drawings like Wayne and a good understanding of file naming and file management within the group. We do not use PDM, and have a well defined (though not documented) way of handling our data that allows us to all work together.

For our automation product line where we have a higher level of documentation (models, drawings, schematics, manuals for the end user) we are starting to work to a bit higher standard with regards to our custom properties. We are adding more custom properties (more then the five or six we usually use) to allow us to pull more complete BOM data out of the models to help us downstream with project management.

We have no rules on how to constrain parts within an assembly. I suspect we are lucky in that we have experienced SolidWorks users that have used the software long enough, they know the pitfalls. While their choices for a particular technique may not be how I would go about it, if it gets the job done I do not stress over it. There are many more important things to stress over in our design process that add way more tangible value to the end product.

If you have a lot of new users you will probably need to spend a bunch of time on training. It takes time to really understand when to use this technigue or that technigue. Rules which contain the word "Always" as opposed to suggested guidelines with a good dose of training so the user really understands the pluses and minuses of a modeling technigue will really limit the knowledge of the group and can leave you boxed into a bad technigue for the job at hand.

Like Matt says take the time spent creating, documenting and training on rules and use that to teach your group the tips and techniques to get their work done more efficiently by truly understanding SolidWorks and the many ways it can be used to get deliverables out of your engineering department.

Regards,

Anna Wood

Reply to
Anna Wood

As you quoted Anna, "I suspect we are lucky in that we have experienced SolidWorks users that have used the software long enough, they know the pitfalls."

We started off as noobies, didn't know the pitfalls and had endless problems. We ALL agree on the rules that are in force. This rules are steadfast until we all agree to a change request, that's the great thing about meetings, everyone gets to air their view.

We don't have the, " I am the boss and you will do as I say policy in place", even though I am the boss when enforcement is needed, lol.

I work under the view of that we are all aiming for the same things, a good product and an easy life. Rules do make life easier if everyone sticks to the them.

Reply to
pete

Pete,

Good point and I think your group handles the rules questions well. You defined your requirements as a group and also will work as a group to change as needed.

Regards,

Anna

Reply to
Anna Wood

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.