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 /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
matt wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Me to. Ed
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
TOP wrote:

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?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

--
Posted via a free Usenet account from http://www.teranews.com


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.