When Configs Just Won't Due

[MadMango]

Configs are great for similiar parts, and product variants (when used with a Design Tables), but I have been presented with a problem that I need to knock around with some of you.

Most of our products are mechanical assemblies, ranging anywhere from 600-900 components. Most of our products were done in AutoCAD back in the 70's and 80's. These mature products have many congifgurations as some components are cross-platofrm compatible (used across several different product lines).

2 of our product lines have well over 100 different configurations. These products do not have top-level assembly drawings or models, though most of the individual sub-assys and components are modeled and detailed with 2D drawings. Everything is built from "tribal knowledge" and old out-dated drawings.

I find that when thinking about making configs for 100-150 products... well, it makes my head hurt, especially when you throw into the mix ECOs.

If a product was changed thorugh ECO, and we had top-level models for every config, it would force someone to have to update every model, which could take days if not weeks. If components were simplied changed, this wouldn't be so difficult as the models would just reference the changed parts and the assy would update on it's own.

The problem enteres into the picture when components are obsoleted, superceded or deleted. This would force someone to have to go into each config and possibly remate broken Mates and other duties. With a 100 configs, this might takes months.

If you are in a similar situation, what have you done to solve this issue?

[green]"I think there is a world market for maybe five computers."[/green]
Thomas Watson, chairman of IBM, 1943.
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[CorBlimeyLimey]

Could you not update the models & drawings on an as needed basis, rather than all at one time?

Also, I know squat about API programs, but I suspect that one could be written to sequentially Open, Update & Save all configs in a part or assy and be left to run overnight. Much like when files are updated from one SW version to the next.


Eng-Tips.com Forum Policies faq731-376
Making the best use of this Forum. faq559-716
How to get answers to your SW questions. faq559-1091
Helpful SW websites every user should be aware of. faq559-520

 

[MadMango]

Letting things 'rest' until an update is required is the boat we are in now. Sometimes 5-20 changes may have been in effect before we get around to needing to do something with a particular configuration. Then all hell breaks lose...

Like I mentioned, updating modified components isn't the issue. It's when components have been deleted from an assembly or sub-assy, or an entirely new sub-assy is created that would cause problems.

I'll have our resident programmer take a look at developing some sort of API. I never thought of this.

[green]"I think there is a world market for maybe five computers."[/green]
Thomas Watson, chairman of IBM, 1943.
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[drawoh]

MadMango,

Can you isolate the parts of your design that change from sale to sale? Anything that does not change makes a nice sub-assembly.

Can you have a standard assembly, then document a set of kits that modify it into what the customer wants? This is a good strategy for coping with an extensive option list.

Again, this is an attempt to move most of your complicated stuff into an assembly that does not change a lot, or that is required to change all across the board.

This is the precise scenario that design change rules were meant for. Never, never, never change form, fit and function of something with a given part number. Do not incorporate the revision number into your part number, and do not call up the revision numbers of parts and assemblies on your parts lists.

If a detail change has no effect on the subsequent assembly, the subsequent assembly can ignore the design change.

If you must change form, fit and function, generate a new part number, and update the next level assembly to incorporate the new part. Your objective is to minimize the extent to which each revision trickles down your assembly tree.

JHG

 

[ctopher]

We kinda had the same problem.
When we loaded PDMWorks a few years ago, we decided to check-in as much as possible and revise as needed. Everything that was checked-in was also stored in the original folders on the server for safe keeping until we were satisfied each file was updated in SW the way we needed. As we add configs, we can either check-in as same rev or roll rev. If it gets messed up, there is backup. In PDMW any revision can be deleted or roll back.

Chris
Sr. Mechanical Designer, CAD
SolidWorks 05 SP0.1 / PDMWorks 05
ctopher's home site

 

[SBaugh]

You know MM, it sounds like you are using faces to mate with in your assemblies. If you used planes in the assembly to mate your components to you would not have as big of a deal. You would only lose the mates of that component or sub-assembly, instead of monster mess of mates in your FM.

Just a thought late at night...

REgards,

Scott Baugh, CSWP
3DVision Technologies

http://www.3dvisiontech.com

http://www.scottjbaugh.com

faq731-376
faq559-716 - SW Fora Users

 

[MadMango]

Scott, yeah, many of these problems come from bad SW workflow that was done way back in 1997 when we were first getting our feet wet with SW96+.

I guess we are paying the piper now. We all learn from prior mistakes. No one wants to direct the proper effort and time into correcting our past mistakes, unless it is an emergency. I guess that's one lesson some people will never learn.

[green]"I think there is a world market for maybe five computers."[/green]
Thomas Watson, chairman of IBM, 1943.
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[rgrayclamps]

Hi, MadMango:

Configs are NOT great for similar parts, and product variants at all. SolidWorks is an object-oriented program. It is most efficient to treat each individual part or assembly as an object. If you group a series of parts or assemblies using multiple configurations, they tend to tangle each other. If you use any "ERP" systems, they will treat each part or assembly as an independent object.

At my company, we do not allow use of multiple configurations for parts. For assemblies, we also use single configuration unless its components are located differently (for an example, an assembly can have open and close states). Multiple configurations are an invitation to disasters.

when components are obsoleted, superceded or deleted, by definition, you are to make revisions to their parents (assemblies). If you use any ERP systems, you are not allowed to obsolete any parts until you revise their parents. SolidWorks is a database program. So are all modern ERP systems. I do not see any problems in this area. The problem you have is that you use multiple configurations (not object-orientated). Use of multiple configurations should be disencouraged.

Alex

 

[crjones]

If you use an indented bill of material construction, construct your assemblies in line with these smaller assemblies. Use the same criteria that you use for these sub assemblies to have the same base number to set your configurations. If the base number changes the assembly model changes.

 

[EvanBasalik]

As someone who writes API for a living, it sounds like what you have is a situtation that does call for API code - MAYBE! The problem is figuring out the rules for what to change. If the rules are something you can lay out for someone, the API code would be great. Or, maybe the API code can help you enough that the number of ones you have to do manually is small enough its not too bad.

Could you explain the rules of what needs to be modified to someone?

Evan T. Basalik, MCSD
--------------------------------
It's all about prioritization...