How many configurations are too many?

How many configurations are too many in an assembly that will be
inserted multiple times into many different assemblies?
I have a small common assembly of 4 parts that I use all the time. 2
of the 4 are common parts that don't change in this assembly but the
other 2 are sized together and each have the same configs referenced
in the assembly to change between nearly 100 different sizes. Besides
the different sizes, one of the components can be at 1 of 4 different
angles. Plus there are 3 different finishes for this assembly that
doesn't affect the model really but does affect the BOM.
So we have 100 sizes X 4 angles X 3 finishes. Is 1200 configs too many
for one file?
It would be nice to include them all in one file because we can. It's
a small assembly so I'm really not concerned about performance but
rather finding the configuration that the user is looking for. The
Component Properties window only displays 8 configs in the
Configuration list box. That's a lot of scrolling to find the desired
config name in a list of 1200. Any suggestions?
We are up to date using SW2007 on XP workstations. Thanks for any
help.
dp
Reply to
dpodz
Loading thread data ...
I have the same problem, I have a faucet with different supply styles and different valve styles and different finnish styles and different spout styles and with or with out some extra options. It leads to about 1600 different configurations. The solution that I have found to deal with this problem is the use of the design table for the building of the different configurations. It is preaty difficult to learn, and once I learned some of it I was still confused on other issues. But what I found out was that there were some buggs in the solidworks software that make the configurations off by different degrees of configurations. What I mean is that the part number and the different features that were to be displayed in the modle were not matching. (sorry for the spelling I suck at it) but any how I have figured out how to make the 1600 configs but I did not figure out how to get the right names on the right part configurations of the assembly. This also works for the part level but the assembly level makes it more dificult. You can pick configuatons of configurations in your design table. Let me know if this helps and if you try this on a small scale to see how it works.
Basicly you use a design table and turn things on and off by using patterns of S & U (suppress and unsuppress) in your design table.
Thank you
Terry
Reply to
squirleboy
If you can manage to do it Terry's that would be a good way to organize the configurations from a centralized source (the design table). Another way to simplify the selection of configurations would be to use derived configurations. You could have 100 top level configurations, which is a lot easier to weed thru, but then each config would have 12 derived configs below them. The opposite might work even better - 12 configs with 100 sub configs each. I'm not sure if a design table can be used to specify derived configs, but if it can then you could use Terry's method in conjunctions with the derived configs. Yet another option would be to have 3, 4 or 12 assembly files, each with 100 configs. How well this would work depends on how often you change from one assembly to another while inside an upper level assembly. Hope that helps.
-Mahir
Reply to
takedown
If you can manage to do it, Terry's method would be a good way to organize the configurations from a centralized source. Another way to simplify the selection of configurations would be to use derived configurations. You could have 100 top level configurations, which is a lot easier to weed thru, but then each config would have 12 derived configs below them. The opposite might work even better - 12 configs with 100 sub configs each. I'm not sure if a design table can be used to specify derived configs, but if it can then you could use Terry's method in conjunctions with the derived configs. Yet another option would be to have 3, 4 or 12 assembly files, each with 100 configs. How well this would work depends on how often you change from one assembly to another while inside an upper level assembly. Hope that helps.
-Mahir
Reply to
takedown
You could have 100 top levelconfigurations, which is
The design table was a given from the start. I wouldn't create configurations any other way, at least not this many. As I said, the problem I'm having is not creating the configs but rather the users finding the one they need to put in their assemblies.
I think I may break it down into a few top level assemblies but what sucks about that is that they will be identical models just with different properties.
dp
Reply to
dpodz
If PDM is an option there are some that will manage configs as parts. You can then search for the config you want based on the description.
You might be able to write a macro to search on the descriptions also.
I have often wanted to be able to search within File/Open, Config lists etc. Anywhere a list is given in SW it should be searchable if it can grow to a large size.
I don't think you can manage Derived Configs from a DT.
Reply to
TOP
Just another thought here. It appears that the issue here is having the configurations available for users to use in their assys. If it's ok to not store a master copy of each config, then how about letting the user create a job-specific copy of whatever config they need when they need it? That way you only store & rebuild a much smaller file.
One of the SWW sessions I went to last year focused on just such a thing in that all the possible combinations of this product generated about a million configs - way too many to maintain. The design table in the assy file had one line in it, and they fed info to it in such a manner as to create strings that defined certain part configs, lengths, etc. Let me know if you need more info.
WT
Reply to
Wayne Tiffany

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.