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

 

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.

 

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

 

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.

 

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.