top 10 configurations tips

What are your top 10 configuration tips?

Some of my favorites are:

- using display states instead of configurations to control hidden parts
- copying display states and exploded views between configurations
- using automatically created design tables to copy configurations
between similar parts
- avoid mixing SW equations and design tables - one or the other
- avoid mixing incontext with configurations (such that one part has
size configs and another just has one config with incontext references -
the second part size is driven by the first parts configuration)
- use configs to simplify large assemblies for performance gains
- for parts used in a large assembly it is a great idea to have a
consistently named config like "simplified" to take advantage of
automatic features for creating assembly configs.
- be careful of the settings for what happens to new features, if they
get added or not added to part or assembly configs - set your templates
appropriately.


Feel free to add to the list, or discuss items on the list.

Thanks,

matt
http://mysite.verizon.net/mjlombard/

 

Good topic -. I hope to come back next Tuesday (after vacation) to see
what else comes up...
Mine (in no particular order):

1) make a config in the asm for in-context relations, and be religious
about making in-context relations ONLY in that config.

2) set properties-advnanced options for asm configs so mates and
features are NOT suppressed - except when I want them to be.
Regardless, be sure to re-check those 'advanced options' under the asm
config, (they can really make an assembly unmanageable with mystery
mates, etc, if you go by the default), Same goes for those options
under part configs - the default might not be what you want, and you
will spend a ton of time repairing what you could have prevented
up-front.

3) After I make the asm config for in-context mates, I make another
config (or configs) for parts that move relative to one another and I
drag a second instance of those components in and mate them the way
they move. This inoculates me against errors from moving in-context
parts, because the in-context instances of those parts stay where they
are supposed to be (in the past I could even suppress their instances
to keep them out of the BOM and, oddly, everything would update
correctly, but I have not checked recently and lately, out of cowardice
I just hide them - must check, must check)

4) I am not a design table guy.
When I can, I get the assembly to where I want it with just one config,
then when I think the job is close to being done I add the other
configs. This takes care of all the usual issues with multiple
redundant mates, etc. Not always practical, but its what I shoot for.
Sometimes I will see guys struggle with an asm for hours trying to save
just three existent configs that have repetitive, redundant mates due
to not setting the advanced options away from the default - I tell them
to just blow them out, delete the extra mates, and redo it from the
one stable config they have (goes back to being sloppy with advanced
options under properties, usually, but it can take longer to try to
repair than to redo from scratch)

5) Storyboard the real-world assembly of your product with configs -
one config for each step of the assembly.
For instance, I thought I had nailed a project I was working on last
night, but just this morning I learned while making the storyboard that
a fastener would have been obscured by another component during the
sequence of assembly.
Oops. It happens.
When you are changing 5 things at a go, it is easy to make a mistake. 1
minute making that 'storyboard config' saved $1000 in erroneous
prototypes - and the fix involved changing a single dim. Not bad - I
do not normally produce $60,000 an hour of value for a client.
Of course, run interference detection in each one of those configs -
especially when that config shows the component on its way to its final
location (and I hammer our guys on that - use configs to ease
components into place and be sure there is no interference in each
intermediate position when the design is tight). Why configs instead
of draggoing the parts on screen? You can redo the test, exactly, each
time, as the design changes (and they ALWAYS change)

6) Name configuration specific items in the tree. In a part - I use
the nomenclature *configname* before the feature name if it is used in
only one config. In my business I have to pass on parts to others, and
I don't want them deleting important features just because they are
suppressed - if I am the least bit afraid the next person won't
'get' it, I even use a **SAVE*config name* prefix (suppressed
features, after all, look irrelevant to the design). In assemblies, I
use the same nomenclature for mates if they are suppressed in any of
the configs.
If the value changes from config to config, I add the suffix '###' to
the mate name because it is the darkest character combo I can find -
boy, it jumps out if you are looking at a long string of mates. Is
there a way yet to add color, bold, etc????
The '###' tag is also very handy for that one dim or angle mate
that you use to test out a design - makes it easy to find when you
have several hundred mates to scan through.

7) Folders to segregate configuration specific items - usually more
relevant in assemblies. All the In-Context placement mates for the
base component go into an 'In-Context' folder. This, however, does
not inoculate them from being changed erroneously by someone futzing
with the mates in the folder associated with the 'component' in the
tree, or when using 'view-mates' on a component. Since the
'In-Context' mates are often the most critical to a design, I try
to make a point of taking the Ctrl-C, Ctrl-V time to add the prefix
'*In-Context*' to all of those critical, critical mates. ...usually
(chagrin)

8) When adding a feature to a part that has multiple configs, I will
complete the feature, select it in the tree, then go to suppress (or
unsupress) in the edit menu at the top of the work window and choose
which configs I want it applied to. Nothing sucks worse than having to
scan each and every config to see which has the correct feature and
which doesn't (which was a *severe* bug in earlier versions of 2006
- no matter if you told Swx to unsupress across all configs, it
DIDN'T - this * seems * to be fixed in later service packs. But, BE
CAREFUL, and, unfortunately, vigilant)

9) I know this is a miserable thing to have to say, but before release
you really have to check all the configs before you release for
production. That means complete scrutiny, interference detection,
every check you can make. What takes a few hundred dollars in labor
can save tens of thousands in mistakes.

10) PWx and configs - at least until the last time I checked, you
better add your PWx materials BEFORE you make your configs. If you do
it after, you will have to re-apply your materials for
EVERY-STINKING-CONFIGURATION. Granted, this is powerful - I used to
have to make displays for Phillp Morris, and then, if PM didn't like
it, do it again for RJ Reynolds (and, of course, show the display for
each of their individual brands), I think configurationspecifc PWx
materials is a terrific OPTION.
But, in most work, it is not (as far as I know) an option, and it blows
(and was still extant through 2006, sp 4). Maybe our resident PWx
expert, Rob, would care to comment?

Ooops - I have ten, I had no intention of having ten - just wanted to
list my top ones regradless of number.

Most of what I mention is just good, common sense practice that just
takes seconds to do (especially with the 'labels' and being sure
new items are suppressed/unsupressed appropriate across configs) but
can, in my experience, save days in lost time. Yeah, it sometimes
sucks to do it, and I am not as religious as I wish I was, but anytime
I don't it I remember that I should have.

My question: How many use design tables vs manual creation of configs?


Ed 'blahblah' Eaton

 

I prefer to use design tables, partly because part of the reason for
the configs in the first place is to use them during the modeling,
especially on mechanism with distinct positions. It is better to wait to
the end after all the changes have been made, but I need the configs en
route. Design tables just help keep everything organized instead of
needing to remember which config is doing what.

Sometimes I auto-create a design table, make some changes or even just
use the auto-created table to do a check on the differences between the
configs and make sure I didn't miss something, then delete the design
table to keep the overhead lower.

I was hoping to see feedback from more folks on this topic.

 

Me to.
Ed

 

1. Use configuration specific custom properties exclusively.
1A. Set config name as part number in BOM
1B. Name the first (default) config as the file name (if that is the
part name)

2. Use derived configurations for simplified versions of parts. Give
them a name like DWG-partno. These are used for drawings where you want
defeatured parts (no fillets and chamfers) and in assemblies to help
speed.

3. Use a design table to create large numbers of similar
configurations. If configuration parts are used sequential numbers can
easily be generated in a design table.

4. Name dimensions that will be used in design tables to make them
easier to track when using auto create.

5. Linked dimensions and design tables do get along well across
configs.

6. Configs can be copied and pasted using CTRL-C/CTRL-V

7. swCP3 works great copying custom props from one config to another.

8. FILE/FIND REFERENCES will force SW to load all parts in all configs
which sometimes helps find those odd parts with invalid paths that are
suppressed in all configs.

9. To be continued

 

Do you have a reason for that? Do some PDM products not recognize config
specific props?

perfect, thanks, great suggestion

Can you drive global variables with a DT?

 

I have been making a list and checking it twice...

1. Our library parts are made with design tables, unless a specific reason
not to, in order to make it easier to create new configs.

2. Config-specific properties unless a specific reason not to, such as
several configs of a limit switch with the arm in different rotation
positions.

3. Make config names mean something, but not too specific. Example, name a
config "Drawing config" rather than "921A". That way if the part ends up
changing to another sheet, you don't have to change the config name also,
but yet it means more than "config 1" or something.

4. Sheet metal flat pattern config - let SW create it.

5. With our library parts and templates like bulk material, we have many
configs already built for the different sizes, etc. When I use that part, I
add new configs for the particular task at hand. Example, I have a template
for rectangular tubing. I want a part that is 4x3x.25 tube for the top of
the carrier. I go to the appropriate "starter" config and then insert a new
config, which makes my new one a copy of the particular size. I then name
it starting with a "0" and then our part number for that material, and then
something descriptive. That way any that I use are at the top of the list.
They also list the base material, so when assigning the material properties,
I can easily pick out which ones are the same material. And the name means
something. Then at the end of the design, I delete all the configs I am not
using, but leave the DT. That way I can recreate all the starter configs if
necessary.

6. I use configs for different positions of a lift, carrier, etc. I may
also have a config that is labeled "free" or something like that and in that
config, make the lift carriage able to be moved manually.

7. Automate things with configs, such as a macro that walks through all the
configs in a file and displays then maximized isometric view. It's a good
way to put one last look on all the configs before releasing. Another macro
I use is to turn on or turn off the setting for "Suppress new features and
mates" for all configs. Flip the switch, make your global/specific change,
and then flip the switch again.


WT