PDM/Works & Configurations

[ClusterTruck]

Does anybody know if there is a way to get PDM/Works to handle part configurations? What I am trying to do is come up with a scheme for PDM/Works to handle SW2003 Toolbox components efficiently. I don't like the idea of having a separate part file for every piece of hardware. For instance, I would like to generate a screw, and then create a design table for the different lengths. Unfortunately, PDM/Works does not seem capable of treating configurations as a unique part. Any suggestions? Thanks.

 

[TheTick]

We are in the process of purchasing a new PDM system. The first thing we were warned about was that none of these systems did a decent job of handling configurations.

 

[Ewan]

We are also in the process of implementing PDMWorks, and have found that things are easier if the configurations for fastensers are spit out into seperate files. However, we are using 2001+.

 

[Standing]

ClusterTruck,
I do not use Tool Box, but one of the associates here does. He said go to Toolbox in the SolidWorks menu. Click Brower configuration, then Document Properties. Now set the radio button “No copy (always use maser part file)". That should do it for you. Now tool box will create configurations. Bradley

 

[RonalddeBruijn]

We are also looking for a PDM system and pdmworks looks like a good affordable choice.
Does anybody know if pdmworks also supports home made parts configurations(every config.is a part)

 

[RawheadRex]

My understanding and experience is that PDMWorks and configurations do not play well together with one another. This was a stated limitation of the product the last time I attended a demo with my former company's VAR. I was told that this was an enhancement that apparently is in the plans for a future release (if one chooses to believe that information).

The bottom line is that as of right now configurations aren't dealt with in PDMWorks.

Chris Gervais
Sr. Mechanical Designer
Lytron, Inc.

 

[sdb999]

We're in the process of implementing Smarteam PDM with Solidworks. It can handle configurations as discrete parts or unique orientations of the same part, but it comes with some baggage. If you absolutely need configurations they might be an option.

 

[sdb999]

In the same vein:
1. Is there a way to display Config. Name and Config. Description of a part in an Assembly when the part in question has only one configuration?

2. How do you link a note to Config. Description in a drawing without using a custom property?

 

[JNR]

OK, into the fray again!! Some PDM system do indeed do a great job of handling configurations - at least SmarTeam does, so I assume Matrix probably does also (and maybe some other high end systems.

There are obviously some restrictions, but it works fine and seems to allow for most needs with ONE POSSIBLE EXCEPTION.

This is how it handles config.

You are allowed up to a fixed number of characters for config names. (Used to be 10 when we designed our naming convention and is now more - don't know how many - we are done and not changing).

The first N characters are available to define configurations which are the same PART NUMBER or ASSEMBLY NUMBER.

A SPACE character then separates the remainder of the config name which is contained in paratheses. This can be any alph-# characters fro, say special analysis/explode/developemnt/whatever configs.

We use the original 10 character form and our company part naming convention has the last four characters (starting with a -) defining part configuration (as opposed to SW configuration). Drawings have the same numbers as parts/assemblies without the configuration "dash" number.

XXXX-YYYY-001 and XXXX-YYYY-002 are different (but similar) parts or assemblies. They are detailed on the same drawing XXXX-YYYY. Examples might be same screw - different lengths, or same assembly but different powersupply/color/non-form/fit/function interchangeable/etc. The SW File Name contains the first number set (drawing number).

So for SW CONFIGs:

-001 (xall)
-001
-001 (fea)
-001 (dwg1)
-001 (stow)
-001 (oper)

would all be of the -001 part/assembly, but different SW configs.

-002
-002 (test)
-002 (fea)
-002 (stow)

would be of the -002 part/assembly, etc.

For development, non released versions, we could (but don't as it happens) also have

pdr1 (revw)
pdr1 (expl)
pdr2
cdr1
dsgn

Just as and example, we could also do this for screws (but don't because they really are different parts):

8330-1234-001 (blck)
8330-1234-001 (zinc)
8330-1234-001 (sstl)
8330-1234-002 (blck)
8330-1234-002 (zinc)
8330-1234-002 (sstl)
8330-1234-003.......etc.

This is a big logical problem for PDM systems and SmarTeam seems to have dealt with it quite well once you get the hang of it.

Here is the exception - and the reason for that strange looking config "-001 (xall)".

Since suppressed items in assemblies truely do not exist in that configuration, the PDM system has to treat them as such and not include them in the associated file list(ie. basically the vault version of the BOM). So when you check the assembly in you can "loose" parts that are suppressed in the active configuration (say -001). Trouble is that when you try to check out -002 they are not there where they should be. It is recoverable, but a real pain. We use the "-001 (xall)" config to check in assemblies sometimes. This has no suppressions at all. We then use hiding to facilitate this function. It is a compromise. SmarTeam now has an option to fix this, but we have not yet tested and implemented it. However it does mean that SmartTeam has to resolve EVERY configuration when you do a check-in (it has to know what every config has to keep the associated file list correct). This could be a time issue, since we check most files in every night at least and everything at the end of the week.

BTW: This does illustrate one big issue with PDM in general. It does drive your file and part naming conventions - so be prepared for a change there. And since these changes are painfull, once you make it work you may choose not to implement future enhancements in the PDM system to handle this. Thus it pays to test first and get it right up front before globally implementing you new PDM system.



3/4 of all the Spam produced goes to Hawaii - shame that's not true of SPAM also.......