AnsweredAssumed Answered

HOW TO AVOID FUTURE PROBLEMS WHEN MOVING TO PDM WORKGROUP

Question asked by Andres Girardot on Feb 5, 2010
Latest reply on Feb 8, 2010 by Andres Girardot

Like • Show 0 Likes0
Comment • 6

I was just hired by a start-up company that is in the process of setting up a new engineering venture. The company has three standard seats of SW2008 with the future goal of upgrading to SW Professional and use PDM workgroup to manage the parts, assemblies, drawings, and documents. Unfortunatelly, nobody in the company has worked with PDM before and we belive that it is important to proceed with early configuration management practices to avoid costly mistakes in the future. Therefore, I would appreciate if any experienced poeple in PDM workgroup can provide me with some guidence in respect to things we should establish now prior to make mistakes than can give us problems once we move to a Vault. Just to provide a start on what type of info we are looking for i am going to make some questions to bring people to write their comments:

1. Part Numbering scheme - Will PDM workgroup have problems with alpha characters, dash values, or other characters for part numbers? Should files be named with the part number and use custom properties to add other important information? or the file name is irrelevant?

2. How PDM workgroup treats configurations - I have read that PDM won't recognize configurations as different parts, if so should we start creating individual files for each part config. or are there ways around this problem?

3. How does PDM treat parts unders a diferent project names?

4. Is there an specific folder structure needed?

5. Which custom property information is relevant and important to PDM?

6. Connectivity to ERP software?

7. Accessing the vault off-site??

7. What else should i be aware of!!! DO's and DONT's

Well I hope i can get some good information that can help us avoid a costly and great headache in the future when moving to PDMworks.

-A

Kenneth Barrentine Feb 6, 2010 11:15 PM

Correct Answer

1. File names can be anything allowed by Windows. The file name becomes relevant when sending out to vendors, so using the part number for filename is the preferred practice. You can start off with names and once an assembly/parts is ready to assign a number checkin latest versions and rename inside vault. This will preserve any in-context relationships. Make sure to remove named versions from local workspace.

PDMW has an option to not display the filename (labels). This allows for instant recognition of any document without a number property filled in, assuming you are displaying the number property label in the vault.

2. True and yes. PDMW cannot manage configurations to represent different part numbers within one document.

3. One filename per vault is allowed, no duplicates. The projects in the Vault do not behave like folders in Windows. There are no real walls. The projects are just organizational and performance tools.

4. No, but beware renaming a project is not allowed. Also, no duplicates for projects, this is a "REAL" annoyance.

5. The decision is yours however, you cannot force properties to be filled out.

6. Not realistically possible. PDMW is a closed database. Even if it was "open" the big drawback is that only SolidWorks files are listed with a quantity in reporting window, assuming you export the BOM from the Vault. Generics are only considered as an "attachment". Not only is this an annoyance it's a major drawback. You might have more luck going straight from SolidWorks to ERP but, there again, no generics would make the trip which could possibly make the BOM incomplete.

7. VPN

Workgroup is a very basic and simple system. Your choices and options are rather limited. Get it up and running and experiment a little.

hth

See the reply in context

No one else had this question

Outcomes

Jordan Tadic Feb 6, 2010 3:43 PM

1. I always recommend using the part number as the file name. The golden rule in a WPDM vault is that every file name must be unique. The same rule applies to part numbers, so it makes sense to use the part number as the file name. This also makes browsing and searching more uniform as well.

2. You can certainly use configurations in your part and assembly files that exist in a WPDM vault, but you're right, it does not consider them to be separate part files. The big thing about this is you cannot have a separate revision history for each individual config (i.e. if you make a change to one of the configs in a part file, the entire part file gets revisioned). A way around this is to create a separate drawing file for each unique configuration. You can then revision manage each individual drawing file that will be referencing an individual config of a part file.

3. I assume you're aware that 'projects' in WPDM are simply a fancy name for folders. Don't be too worried about scattering part files across multiple folders within the vault. There is no replication of part files in WPDM, which is a beautiful thing.

Example: If you have an assembly and its part files are stored in a project (a.k.a. a folder), and then you have another assembly in another project that is referencing some of the first assembly's part files, WPDM will NOT make a copy of those part files in the vault. Instead, it will simply use those part files in their original location. However, it WILL display a shortcut icon of those particular parts within its project folder for easy access (as if they actually were copied to that project). Once you try this out, you'll understand what I'm saying. It works very nicely.

Here's the golden rule when it comes to projects... Create many projects and sub-projects to minimize the amount of files that are contained within any single project/sub-project. This will maximize your vault's performance. It's the same as the Windows operating system. It's faster to browse through 10 folders with 100 files each than it is to browse through a single folder with 1000 files in it.

4. Maximize projects to minimize files per project as explained above.

5. The custom properties that are important to WPDM are the custom properties that are important to you. It is imperative that you standardize on the custom properties that you'd like to have inserted into each of your SolidWorks files. And it is also a good idea to have these figured out before you install your vault. Once you pick the custom properties that you'd like the vault to add to each file, it's going to automatically give you the opportunity to add that property to each file every time you check it into the vault. The benefit of picking a set of properties and sticking to them is the ability to search by custom properties within the vault.

Without adding any custom properties, WPDM will always at least try to add these basic properties to each file in your vault: number, description, revision, owner, project, status (if life cycles are enabled), note.

6. This must be done through custom programming. Contact your reseller to see if they have an API resource available.

7. The vault will reside on a server somewhere. To access it, you'll need access to that server directly or via VPN. There is no multi-site replication for WPDM as there is with EPDM.

8. There are a lot of things to consider when implementing WPDM. Typically, it forces companies to think in a much more structured and organized way than they have in the past. To help facilitate all of these concerns, your VAR should offer a WPDM implementation service. There is a large packet of survey questions to get you thinking about the things that need to be considered when implementing WPDM, so I would suggest that you contact them to see if they can provide you with further assistance.

Actions

Andres Girardot @ Jordan Tadic on Feb 6, 2010 9:48 PM

Jordan,

That was a great response and I really appreciate the amount of information you are providing.

What worries me the most is the use of configurations with part or assembly files. From your experience which approach will be easier to implement and for new configuration managers and/or engineers to manage and use

a - Create configurations within the part and/or assembly and revision manage individual drawing files, or

b - Create single part or assembly for each configuration.

Actions

Jordan Tadic @ Andres Girardot on Feb 7, 2010 9:07 AM

Personally, I would choose option A, but it's totally up to you. I don't think it's a big deal to make a separate drawing for each configuration. You'd still have to make a separate drawing for each individual part file anyways. The main reason I’d choose A over B is because configurations are too beneficial to do without. I’m not sure how you’re using them, but if I had a part family that consisted of 10+ configurations, I would hate to have to make the same design change to 10+ files rather than just updating all the configs at once within a single part file. You’ll just have to decide how valuable configurations are to your workflow.

Actions

Kenneth Barrentine @ Andres Girardot on Feb 7, 2010 1:29 PM

I would choose "b".

If you go with "a" it will just add confusion and complexity to the end users. Especially with what they will see in the vault and checkin/out window. But experiment before a final decision is made. Present your findings to the end users.

Think about what Jordan said. Would you rev all ten items of a family if only one had a geometry change? I know I wouldn't.

A family of ten items = 10 unique items, family means nothing in this case.

Configurations are great for toolbox items and assemblies, they're just not an efficient way to manage revisions of unique items.

Actions

Andres Girardot @ Andres Girardot on Feb 8, 2010 12:07 PM

Jordan and Kenneth, thank your for your input of this matter.... Your answers are a great point to start investigating which method is better depending on ours needs and end user requirements....

Actions

Kenneth Barrentine Feb 6, 2010 11:15 PM

2. True and yes. PDMW cannot manage configurations to represent different part numbers within one document.

4. No, but beware renaming a project is not allowed. Also, no duplicates for projects, this is a "REAL" annoyance.

5. The decision is yours however, you cannot force properties to be filled out.

7. VPN

Workgroup is a very basic and simple system. Your choices and options are rather limited. Get it up and running and experiment a little.

hth

Actions

6 Replies

Jordan Tadic Feb 6, 2010 3:43 PM
Mark Correct
Correct Answer
1. I always recommend using the part number as the file name. The golden rule in a WPDM vault is that every file name must be unique. The same rule applies to part numbers, so it makes sense to use the part number as the file name. This also makes browsing and searching more uniform as well.

2. You can certainly use configurations in your part and assembly files that exist in a WPDM vault, but you're right, it does not consider them to be separate part files. The big thing about this is you cannot have a separate revision history for each individual config (i.e. if you make a change to one of the configs in a part file, the entire part file gets revisioned). A way around this is to create a separate drawing file for each unique configuration. You can then revision manage each individual drawing file that will be referencing an individual config of a part file.

3. I assume you're aware that 'projects' in WPDM are simply a fancy name for folders. Don't be too worried about scattering part files across multiple folders within the vault. There is no replication of part files in WPDM, which is a beautiful thing.

Example: If you have an assembly and its part files are stored in a project (a.k.a. a folder), and then you have another assembly in another project that is referencing some of the first assembly's part files, WPDM will NOT make a copy of those part files in the vault. Instead, it will simply use those part files in their original location. However, it WILL display a shortcut icon of those particular parts within its project folder for easy access (as if they actually were copied to that project). Once you try this out, you'll understand what I'm saying. It works very nicely.

Here's the golden rule when it comes to projects... Create many projects and sub-projects to minimize the amount of files that are contained within any single project/sub-project. This will maximize your vault's performance. It's the same as the Windows operating system. It's faster to browse through 10 folders with 100 files each than it is to browse through a single folder with 1000 files in it.

4. Maximize projects to minimize files per project as explained above.

5. The custom properties that are important to WPDM are the custom properties that are important to you. It is imperative that you standardize on the custom properties that you'd like to have inserted into each of your SolidWorks files. And it is also a good idea to have these figured out before you install your vault. Once you pick the custom properties that you'd like the vault to add to each file, it's going to automatically give you the opportunity to add that property to each file every time you check it into the vault. The benefit of picking a set of properties and sticking to them is the ability to search by custom properties within the vault.

Without adding any custom properties, WPDM will always at least try to add these basic properties to each file in your vault: number, description, revision, owner, project, status (if life cycles are enabled), note.

6. This must be done through custom programming. Contact your reseller to see if they have an API resource available.

7. The vault will reside on a server somewhere. To access it, you'll need access to that server directly or via VPN. There is no multi-site replication for WPDM as there is with EPDM.

8. There are a lot of things to consider when implementing WPDM. Typically, it forces companies to think in a much more structured and organized way than they have in the past. To help facilitate all of these concerns, your VAR should offer a WPDM implementation service. There is a large packet of survey questions to get you thinking about the things that need to be considered when implementing WPDM, so I would suggest that you contact them to see if they can provide you with further assistance.
Like • Show 0 Likes0
Actions
- Andres Girardot @ Jordan Tadic on Feb 6, 2010 9:48 PM
  Mark Correct
  Correct Answer
  Jordan,
  
  That was a great response and I really appreciate the amount of information you are providing.
  
  What worries me the most is the use of configurations with part or assembly files. From your experience which approach will be easier to implement and for new configuration managers and/or engineers to manage and use
  
  a - Create configurations within the part and/or assembly and revision manage individual drawing files, or
  b - Create single part or assembly for each configuration.
  Like • Show 0 Likes0
  Actions
  - Jordan Tadic @ Andres Girardot on Feb 7, 2010 9:07 AM
    Mark Correct
    Correct Answer
    Personally, I would choose option A, but it's totally up to you. I don't think it's a big deal to make a separate drawing for each configuration. You'd still have to make a separate drawing for each individual part file anyways. The main reason I’d choose A over B is because configurations are too beneficial to do without. I’m not sure how you’re using them, but if I had a part family that consisted of 10+ configurations, I would hate to have to make the same design change to 10+ files rather than just updating all the configs at once within a single part file. You’ll just have to decide how valuable configurations are to your workflow.
    Like • Show 0 Likes0
    Actions
  - Kenneth Barrentine @ Andres Girardot on Feb 7, 2010 1:29 PM
    Mark Correct
    Correct Answer
    I would choose "b".
    
    If you go with "a" it will just add confusion and complexity to the end users. Especially with what they will see in the vault and checkin/out window. But experiment before a final decision is made. Present your findings to the end users.
    
    Think about what Jordan said. Would you rev all ten items of a family if only one had a geometry change? I know I wouldn't.
    
    A family of ten items = 10 unique items, family means nothing in this case.
    
    Configurations are great for toolbox items and assemblies, they're just not an efficient way to manage revisions of unique items.
    Like • Show 0 Likes0
    Actions
  - Andres Girardot @ Andres Girardot on Feb 8, 2010 12:07 PM
    Mark Correct
    Correct Answer
    Jordan and Kenneth, thank your for your input of this matter.... Your answers are a great point to start investigating which method is better depending on ours needs and end user requirements....
    Like • Show 0 Likes0
    Actions
Kenneth Barrentine Feb 6, 2010 11:15 PM
Unmark Correct
Correct Answer
1. File names can be anything allowed by Windows. The file name becomes relevant when sending out to vendors, so using the part number for filename is the preferred practice. You can start off with names and once an assembly/parts is ready to assign a number checkin latest versions and rename inside vault. This will preserve any in-context relationships. Make sure to remove named versions from local workspace.

PDMW has an option to not display the filename (labels). This allows for instant recognition of any document without a number property filled in, assuming you are displaying the number property label in the vault.

2. True and yes. PDMW cannot manage configurations to represent different part numbers within one document.

3. One filename per vault is allowed, no duplicates. The projects in the Vault do not behave like folders in Windows. There are no real walls. The projects are just organizational and performance tools.

4. No, but beware renaming a project is not allowed. Also, no duplicates for projects, this is a "REAL" annoyance.

5. The decision is yours however, you cannot force properties to be filled out.

6. Not realistically possible. PDMW is a closed database. Even if it was "open" the big drawback is that only SolidWorks files are listed with a quantity in reporting window, assuming you export the BOM from the Vault. Generics are only considered as an "attachment". Not only is this an annoyance it's a major drawback. You might have more luck going straight from SolidWorks to ERP but, there again, no generics would make the trip which could possibly make the BOM incomplete.

7. VPN

Workgroup is a very basic and simple system. Your choices and options are rather limited. Get it up and running and experiment a little.

hth
Like • Show 0 Likes0
Actions

HOW TO AVOID FUTURE PROBLEMS WHEN MOVING TO PDM WORKGROUP

Outcomes

Related Content

Recommended Content