Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations KootK on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

How do you guys organize your files? 4

Status
Not open for further replies.

fuzzybabybunny

Mechanical
Jul 9, 2009
6
I'm new to CAD design and I'm wondering how you guys organize your files and what are the best practices?

Do you put assemblies, parts, drawings, in separate folders?

C:/Solidworks/Project1/parts
C:/Solidworks/Project1/drawings
C:/Solidworks/Project1/assemblies
C:/Solidworks/Project1/subassemblies

And how do you deal with the versioning?
 
Replies continue below

Recommended for you

This situation:
Code:
Project99-001-01
Project05-000-03
Project67-079-01
Project99-002-06

What benefit does it have over:

Code:
Part001-01
Part000-03
Part079-01
Part002-06

And the project number in a custom property in the top level assembly? From that you can search the top level assembly related to a project and then generate a BOM and find all the parts in that project.

TOP
CSWP, BSSE

"Node news is good news."
 
My guess is that their business is such that they almost never reuse a part. At best they make the occasional similar part by doing a save as and modify. Then all of the parts for a project have the project number prefix, and anyone looking at a part number knows what project it is for.

This goes back to comments about different situations having different optimal systems.

Eric
 
EEnd,

He answered that he does duplicate parts from other projects:
Ray555 said:
Thats correct.

wouldnt want to duplicate parts on the system

I'm not disagreeing with
As Theo' pointed out, there is no one-size-fits-all solution. What works for one discipline/company/person may be useless or nonsensical for another.
I'm trying to see it from his perspective. I'm trying to get the answer to the question: "What does prepending the project number do for him?"

Q. Why don't you wear snowshoes on the beach?
A. Because it makes it really hard to play volleyball.

Q. Why don't you wear flip flops outside when there is a foot of snow?
A. Because it makes your toes fall off when you go to play beach volleyball.
:)

TOP
CSWP, BSSE

"Node news is good news."
 
[lol] ... As long as they are the only bits that fall off.

I can't speak for Ray555, but I give parts descriptive names when designing them, but prepend the name with a project number to distinguish them from other (similarly named) parts. Once happy with the overall assy design, and while creating the drawings, I will add a -partnumber after the project number. The drawing sheet number (without description) matches the part number.

Each to their own.
 
CBL

It would help to know what kind of environment you are working in.
[ul]
[li] 20 engineers? 1 engineer? [/li]
[li]Job shop (many customers)? OR Manufacturing shop (internal customer)? [/li]
[li]PDM? ERP?[/li]
[li]Over 50% reuse? [/li]
[li]Strict revision control, ECRs, etc. or not?[/li]
[/ul]
[flip]


TOP
CSWP, BSSE

"Node news is good news."
 
Small company (1 owner + 7 employees) designing and building spectrometry related instruments. We have a standard range of products, but customers often need custom accessories.

[ul]
[li]1 'engineer' ... me[/li]
[li]Neither (but closer to job shop) ... Customers are usually universities, or independent science labs[/li]
[li]No PDM or ERP[/li]
[li]Probably less than 2% re-usage[/li]
[li]Duhhh ... wot's an ECR [lol][/li]
[/ul]

Other companies I've worked for have had strict systems, but no need for that here. Like I said above, what suits one, will not necessarily suit another.
 
CBL

You just illustrated a simple fact of cognition. There is still a vast divide between the way humans think and the way machines operate. In your system the human mind retains, organizes and operates upon information in the appearance and location of filenames. It depends on the fact that the human mind quickly recognizes patterns that computers cannot without a great deal of difficulty. It also depends on the fact that the human mind recognizes information by simultaneously comparing what is coming in through the eye with what has happened before. A computer must compare any incoming information with a full search of it's memory in order to classify that information.

One of the side effects of this is that when a human goes back to something that was done in the past it will frequently happen that the human will have to "retrace" steps to a certain extent to come back to an understanding of what is being observed. A machine will be less likely to need to do this.

So when you see the word project1 in front of a filename it helps the human mind to reconstruct the context in which that filename should be viewed. There may be other information contained within the file (like custom properties) that you cannot see when doing a simple directory listing. There is a parallel cache of information in your head that is associated with the term "project1" that you can quickly reference and classify a particular file.

When two engineers are working together there is still a good chance that project1 will mean the same thing to both. But when 20 engineers are working together there is little chance that "project1" will mean the same thing because not all of the 20 will have worked in the context of that project or in a particular area of that project.
Some engineers, over time, will start remembering actual numbers when in the middle of a project and attribute to them the same associativity that you do with meaninful (to humans) filenames.

In the good old days of paper drawings in a file one could generally view both the drawing number and the description simultaneously when viewing the title block. Because MicroSoft and most OS will not display anything more than the filename in a directory listing humans gravitate towards meaningful file names. Interestingly the Commodore Amiga actually provided for descriptions to be listed along with filenames. SolidWorks has attempted to rectify this by allowing thumbnail icons with filenames, the drawback being slow listing of large directories. If MicroSoft had allowed for a file description to be listed in the directory listing we might all view this subject completely differently.
[pc2]


TOP
CSWP, BSSE

"Node news is good news."
 
PDM with non-intelligent item number is the way to go. Go to your grocery stores, and you will see all items bar coded with non-intelligent item numbers. I am surprised that so many people still use project based systems. Project based systems are not object-oriented. But industries are heading to object-oriented at full speed.
 
No it isn't, rgrayclamps. Neener neener.

This argument is clearly showing that one size does not fit all. My system, as illustrated above, is the best I've found for my situation, and certainly better than any of the above suggestions. By the way, nothing in my office resembles a grocery store's means of inventory tracking, nor the requisite need for such a thing.



Jeff Mowry
A people governed by fear cannot value freedom.
 
Rgrayclamps,
If you look into bar UPC bar codes they are not a true license plate numbering system, those numbers have some significance to them. will provide more information.

As I stated prior the people who interact with the part numbers after the engineer is done with the design are the customers you need to focus on making successful with part numbering and storage systems. When you go to the store like items are usually grouped together for customers to find and compare products. Inventory and part numbering systems that facilitate this system are the lowest cost to operate and have the best fill accuracy.

Ed Danzer
 
Hi, Theophilus:

Could you list major functions that your system can do while other PDM systems can not?

I read your previous comments, and I just notice that your revision scheme is very inefficient.
 
"PDM with non-intelligent item number is the way to go"
Only for some companies! I have used and been instrumental in setting up such systems in companies which have needed them, but not all companies do.

Some people are right-handed, some are left-handed.
Some use a knife and fork to eat, some just a fork, others use chopsticks, and yet others their bare hands.

There is no correct or incorrect method.
 
Hi, EdDanzer:

Items at groceries or warehouse are not grouped together by their item numbers. Rather, they are grouped together by their location properties (Custom properties in SW).
 
rgrayclamps said:
Could you list major functions that your system can do while other PDM systems can not?

Theo' isn't saying that his system can do more than a PDM system can do. He's using a system that suits the way he thinks and the products he designs ... without the overheads of a PDM system. The point is that his system works for him ... and that is all that is needed.

One mans 'efficiency' is another's burden.
 
Ed said:
As I stated prior the people who interact with the part numbers after the engineer is done with the design are the customers you need to focus on making successful with part numbering and storage systems.

Ed, that is a very important point. That is exactly how our system is designed, for ease of use by the end user. Somewhere along the line, there has to be some intelligence. Either the intelligence is built into the system, or the intelligence is in the people who use the system. I'm a designer at a manufacturing facility. My drawings need to be easily accessed by our diemakers and diesetters. I can't control their intelligence, so the intelligence is built into the file naming system that they need to use. This works very well for us, but it might not work best for everybody.

When I'm at the grocery store, if I can't find the milk, I don't ask what isle the UPC# XXX is in, I simply as for the "milk." So I don't quite think the grocery store analogy makes much sense. IMHO.

Joe
SW Office 2008 SP5.0
P4 3.0Ghz 3GB
ATI FireGL X1
 
rgrayclamps said:
Could you list major functions that your system can do while other PDM systems can not?

I read your previous comments, and I just notice that your revision scheme is very inefficient.

CorBlimeyLimey already addressed this. I'm not in competition with a PDM system here. My goal is file efficient file organization. What's the point in having the nightmare implementation of PDM in a one-man band? I don't get it.

You say my revision scheme is very inefficient? In which regard? Hard drive space? I don't get that, either, since hard drive space costs almost nothing. Besides, I've had clients who have requested we go back to a prior revision of a project to branch into a different direction. This system has worked out very well for that sort of thing.



Jeff Mowry
A people governed by fear cannot value freedom.
 
Hi, Theophilus:

That is fine. We have different understanding on revision. You talk about revision of projects while I talk about revision of drawing documents. I try to follow "ASME Y14.35M-1997, REVISION OF ENGINEERING DRAWINGS AND ASSOCIATED DOCUMENTS".

Your following statements make your revision scheme inefficient.

***************************************************
When I bump up a revision of a project, I go to my top-level Drawing or Assembly document--the document which references all parts/assemblies. I go to File > Find References > Copy Files, which will copy all current bits and pieces to the new directory.
***************************************************

When I make a change, I pinpoint which documents (part or assembly, or both) need to be changed, and only revise those documents. Projects have nothing to do with my revision. I do not know if there is a new revision to ASME Y14.35M-1997. According to ASME Y14.35M, only drawing documents have revision.

Thanks for sharing how your system works.

 
Wow, that's a significant difference in how we work (and therefore the needs in our particular work environments).

For instance, I'll bump up my whole project in date-related terms, but I'll rarely work on each document intensively in such a revision--only what's necessary. Regardless, I know the directory at the bottom of my project list is 1) the latest revision, chronologically, and 2) has none of the legacy files that were dropped from use from the previous revision cluttering the new directory.

Also, I rarely make drawings with the sorts of things I design, since the geometry so necessarily relies on the 3D surfaces to be deciphered accurately. As such, the ASME standards are largely irrelevant for my line of work. But this does require that my vendors (prototype, production) are able to work with raw 3D data instead of 2D drawings.

I think when you have multiple minds working on a single project, PDM begins to make sense, as do ECNs and all the other overhead involved in properly tracking documents and revision control. I look at this as inefficient, since more work must go into labor not directly applied to design itself, but the control of the design. In that sense, I'm less encumbered by non-productive activities than I would be in a multiple-user office environment and therefore have a greater percentage of time available for design. (Of course the truth is I must also allocate time to my own IT, purchases, client meetings, etc. that might have otherwise been handled by other personnel in such a multiple-user office environment.)

Different strokes for different folks.



Jeff Mowry
A people governed by fear cannot value freedom.
 
So [!]revisions[/i] is one aspect of file management. Instead of arguing how to do it, we should be looking at what has to be accomplished and then what can the SW tool do out of the box, what can MSoft's OS do out of the box and then go on to implementation.

As a bare minimum:
[ul I]
[li]What exactly does "ASME Y14.35M-1997, REVISION OF ENGINEERING DRAWINGS AND ASSOCIATED DOCUMENTS" require?[/li]
[ul i]
[li]As far as file naming?[/li]
[li]As far as directory structure?[/li]
[li]As far as what should be on the drawing?[/li]
[li]As far as what should be in the model and assy?[/li]
[/ul]
[li]What do Theophilus and CBL require of their systems?[/li]
[ul i]
[li]As far as file naming?[/li]
[li]As far as directory structure?[/li]
[li]As far as what should be on the drawing?[/li]
[li]As far as what should be in the model and assy?[/li]
[/ul]
[li]What does someone in a manufacturing environment require?[/li]
[ul i]
[li]As far as file naming?[/li]
[li]As far as directory structure?[/li]
[li]As far as what should be on the drawing?[/li]
[li]As far as what should be in the model and assy?[/li]
[/ul]
[/ul]
[neutral]

SolidWorks pretty much requires that there not be duplicate filenames anywhere in the folder trees that SW can access. Common sense dictates further that there should not be two identical parts with different filenames.

MSoft will not allow duplicate filenames in the same folder.
MSoft also slows down if there are more than, say, 1,000 files in a single folder although I believe this can be adjusted.
MSoft will not show any information besides a filename and a file type in a directory listing.

TOP
CSWP, BSSE

"Node news is good news."
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor