File Name and Sub-Project Naming Best Practices

[tmalinski]

Since I've been using PDMWorks, (about 2 years) I have utilized a file naming and sub-folder strategy that just isn't working well for me anymore. My current file name structure is too long winded and is hard to adhere to, but it does help me find things!
job# - Description - Detail# - Description.sldprt
In PDMWorks my project and sub-projects have a similar name structure;
job# - Description

Do most of you that utilize a short number coded file name structure use a visual database management tool other than SW Explorer? Explorer isn’t bad, but I can only view 1 file at a time for a visual reference. When I’m searching for a specific file mixed in with hundreds it’s faster to view the file name in the list. But there lies my problem when I eliminate descriptive names. In SW Explorer I can use my arrow key and scroll down thru the list while viewing, but seeing only one file at a time is less than optimal.

I am a photographer outside of my day job, and I use PhotoShop Bridge. It is a visual database index management software that lets me gather the location of hundreds of images by keywords and other fast search criteria. It saves an image cash for fast viewing in bulk like a light table for slides. I then double click to launch 1 or several files to work on. This is what I’m missing in SW Explorer or Windows explorer. Turning on thumbnail view isn’t bad, but most times I can’t see enough detail when I have several similar models.
Any thoughts or suggestions? Is there a better way that I am just not aware of?


Tom Malinski
Sr Design Engineer
OKay Industries
New Britain CT

 

[MFDO]

Prior to PDMworks, we used your part numbering method. Because same part could be named differently with a misspelled/different description, we decided only to use numbers to identify files. I.e. Project# - part#. Because there can be only one identical file # and the system prompts otherwise.

To implement this we had to standardise our numbering method. We had to identify all the possibilities we could face and spread lavishly in an array of numbers like 000, 00 000 etc. e.g. In the Main assembly 00 001there is an Assembly 04 000 which can have 04 001 to 04 099 subassemblies and they could have 04 101 to 041 999 parts in them. Also we have categorised the location are of group of sub assemblies in 10s and at once you see the number we know where to look and which belongs where. At the beginning some were sceptical, but since there were enough provisions to insert any part or an assembly now the system works fine.


Michael Fernando
Tool and Die Designer
SWX 2007 SP2.1 X64
PDMWorks 2007
Logopress3
FastForm Advance
FormatWorks

 

[tmalinski]

Thanks for your imput.
I have used a system similar to what you described in my past and it did keep things organized as long as it was adhere to by all in the department. I could use a simple Job# / Detail# for part models, but then Assemblies, SubAssemblies, and drawings become more difficult. Also, our standard is to combine as many details onto D size sheets as we can fit. So drawing sheets now have to be coded also.
In my past AutoCad days, we used coded Block names within one drawing. Every detail and assembly would be blocked. This worked well, maybe I can try a similar structure but for SolidWorks file names instead.
I suppose this kind of structure is unique per company standards, and maybe it's proprietary because it took a lot of effort to create. I am surprised there isn't any best practices naming structure from Solidworks for different industry standards. At least it would give us a head start to tweak rather than creating a new naming structure from scratch.

Tom Malinski
Sr Design Engineer
OKay Industries
New Britain CT

 

[MFDO]

Find an appropriate way for you to use parent assembly # in front of detail #. I.e. Project# assembly# part#. Define number of alpha numeric characters a file can have. Don’t let use description at the tail end and words like old, new…

Since we were following strict and a good manual drawing control system before PDM works, the ground work had been in place and for us the implementation was smooth.

If I’m not mistaken, at the implementation of PDMWorks, I was told that PDMworks won’t support very well if you have multiple parts in one drawing sheet. But multiple sheets will support multiple configurations. So the basic rule is one drawing file should contain only one part/Assembly file.

We don’t use multiple parts in one sheet method and whenever we received outsourced/takeover CAD data in one sheet, it only brought chaos. We spent time separating them and save them as individual drawings. This way it was much better when it came to revision control and file finding/opening.


Michael Fernando
Tool and Die Designer
SWX 2007 SP2.1 X64
PDMWorks 2007
Logopress3
FastForm Advance
FormatWorks

 

[fcsuper]

Just some thoughts from my perspective:

-I'm not sure why it was mentioned that PDMWorks doesn't handle multiple parts on single drawings/sheets very well. I don't have issues with it. I would make decisions about this based on company needs and efficiency in SolidWorks itself.

-Don't use smart numbers if at all avoidable.

-PDMWorks is geared towards folders based on projects, however Folder organization is actually arbitrary in PDMWorks. I don't know that any method really is any better than any otehr method. The only issue to consider is that the current version PDMWorks Find function works best if individual folders have fewer files within. This of course has nothing to do with how those files are organized once they are checked out and on the local hard drive. Is there any reason the system you've picked isn't working? Many you are trying to store too much information into the project names? Try to dumb down your system instead of making it smarter. Trust the software to know where everything is at.

Like I said, just some thoughts.

Matt
CAD Engineer/ECN Analyst
Silicon Valley, CA
sw.fcsuper.com
Co-moderator of Solidworks Yahoo! Group

 

[tmalinski]

Whats interesting is establishing a File Name structure that suits families of parts, assemblies, & sub-assemblies for customer products, and for the multiple tools and tooling component parts, assemblies, & sub-assemblies that need to be designed to make the customer parts. When a job is checked out of PDMWorks to a folder on my system I can easily have 200-300 files. This is a mix of all the files as I mentioned above. Part of the file naming structure for customer parts and tooling should to be related, but not necessarily identical.

Our company applies our own internal P/N to customer products so if I'm working on P/N 309 then my tools fall under Job 309 so all file names can have that number in common. What gets messy is when I have multiple P/N's of(customer parts) and multiple Tools all working together under the same project.

In my AutoCad days, this was not an issue, one drawing file with blocked dumb geometry contained everything.

If I were to have a master outer assembly file just used as a dumping ground for everything, I could then easily find or see exactly what file I needed, rather than scrolling thru file names in explorer.

Any help or suggestions is appreciated

Tom Malinski
Sr Design Engineer
OKay Industries
New Britain CT

 

[tmalinski]

fcsuper, you suggested "Try to dumb down your system instead of making it smarter. Trust the software to know where everything is at. "

I tend to agree with this.
I was pondering an all visual process. In the real world you don't usually look up names and numbers for stuff your looking for especially with familiar objects. You just look for it, visually recognize it, and you have it. With some exceptions of course...
But in my case with families of related tooling what if I simply named all of my files with a project number and a sequential number, like 309P_001, 309P_002, etc...The sequential number would just be the order that they were created in. It would not matter if it was a part or an assembly. Drawings would still inherit the part or assembly name it depicted. What makes this work is having a visual reference of all parts and assemblies in one main assembly file. You would open the assembly, visually locate your part and open it as required. This may have some limitations due to file size, but the idea could be refind. This way I'm not over-structuring the file name

Any thoughts?

Tom Malinski
Sr Design Engineer
OKay Industries
New Britain CT