Non-PDM SolidWorks Filing Structure 1

[phlyx]

Our company has just begun using SolidWorks in a production environment and we design and build custom and production machinery. We are looking at the SolidWorks PDM package but until we make a decision there I am trying to put an assembly/part/drawing file structure in place so we don't shoot ourselves in the foot.

What I was proposing was that all fabricated parts reside in one common folder, all drawings reside in another folder (and this fold is shared so shop people can view them), all purchased parts in a common folder organized by vendor, and assemblies reside in a seperate project folder that taps into the other folders for parts.

Any suggestions or hints in this area? I am sure we're not the first to face the fact that non-control has created a mess of duplicate files all over the place... :O(

~ Phlyx ~

 

[EdDanzer]

This was discussed in thread559-45542.

 

[phlyx]

Thanks..... must not of worded my search properly. Is there any way to remove a thread?

~ Phlyx ~

 

[SBaugh]

Nope, other than red flagging your thread.

Regards,
Scott



Scott Baugh, CSWP
3DVision Technologies

http://www.3dvisiontech.com

http://www.scottjbaugh.com

faq731-376

 

[Jaswu]

I might be wrong but Thread559_45542 did not appear to cover folder structuring in PDM/Works. Based on my limited experience here is my advise. We too design and build custom machinery mostly one of kind automation machinery. We have components folders oranized by vendor and a folder per machine. What we call a project sometimes consists of multiple machines so we create a "project" folder with it's children machine folders below it. Below is a simple diagram of how we structure it. A machine folder will contain both parts and assemblies. I don't propose that this is the best way of doing this but simply that it works for us. It allows us to navigate thru the projects/machines in an efficient manner. It allows us to allow read or write access to users per machine. Below each project we create on drawings folder. One of the most useful tools is the search feature which is very effective regardless of how you structure the folders. Also look into using property fields. Although not all the fields are searchable thru the search feature PDM/Works does keep track of them and makes them a part the reports.

Project1
Machine1
Machine2
Project1Drawings
Project2
Machine3
Machine4
Project2Drawings
Components
Mcmaster
SMC

Before you go on creating a bunch of folders keep in mind that the more folders you create the more administration overhead you create for yourself.
Although not complete the benefits behind folders are: 1. Visualization of grouped parts 2. Read/Write controls 3.Hiding(hiding folders increases performance on larger vaults) 4.Mass file copying(when saving latest option is enabled)

The draw backs to folders are(keep in mind these are more pronounced as the number of folders increases): 1. Assigning read/write 2. Time consumed in setting up projects(this one is not really a big deal except when you creat a folder and only one part ends up going into it,) 3. Hidding and unhidding folders.

In any case no matter how you decide to do it PDM/Works should eliminate most of your unwanted file duplications.


Hope this helps.

Good luck.

sam

 

[phlyx]

Thanks Sam, the one thing we ran across is where the location of fabricated parts are. If you have a part that is used on several machines then does your example mean there are several copies of the same part? The problem I saw with that is revision level control. You end up with a monumental task keeps mutiple parts current. Your structure is in line with what we were proposing but we were thinking of putting all fabricated parts in a common folder and the machines/projects just reference or link to these. That way an update to part covers all bases.

This would be the structure :

PROJECTS
Job001
Sub-Assembly001
BOM.XLS
Assembly001.SLDASM
Customer Documents
Job002
etc...

FABRICATED PARTS
10001.SLDPRT
10002.SLDPRT
10003.SLDPRT

DRAWINGS
10001.SLDDRW
10002.SLDDRW
10003.SLDDRW
Assembly001.SLDDRW

COMMON HARDWARE
FASTENERS
Custom-Screw001.SLDPRT
FITTINGS
Special-Fitting001.SLDPRT

PURCHASED PARTS
SMC
SMC-1234-1234.SLDPRT
SMC-1234-1235.SLDPRT
McMASTER
McMASTER-123456789.SLDPRT
McMASTER-011111111.SLDPRT

This way all the assemblies just link to fabricated parts, common hardware (things outside of toolbox), and purchased parts which there is only one copy of anything that everything references. So updates cover the spectrum.

Any thoughts? :O)

~ Phlyx ~

 

[TheTick]

One thing that may help is an understanding of how SW goes about searching for referenced components. This is detailed pretty well in the help.

Look in the help file under "search --> file locations for external references".

"Great ideas need landing gear as well as wings."--C. D. Jackson

 

[phlyx]

Did the help thing but I still question if parts (SLDPRT) are stored in the individual project folder for which it was created and then it gets used on dozens of other projects, then locating "where" that part file actually exists becomes another episode of Indiana Jones. Why not just create all the parts in a single directory and then link to that part from the assemblies in the seperate project folders? Backups are easy then, searching is easy and revisions are a snap.

I always looked at fab parts files as if they were "actual" parts in a stockroom. They all sit in one bin and you pull them out of there to use them on each project. Then when you want to use it on something else you just have to go to that one stockroom bin to find them. We have the problem now of people "copying" parts into seperate jobs. Then you end up with dozens of identical part files with identical numbers scattered all over and if you need to revise them you loose your sanity trying to find and change every one of them :OÞ

~ Phlyx ~

 

[TheTick]

We are implementing PDM just now.

Before that, we had a system of storing files in their respective project folders when parts were under development. Once released for production, parts are renamed with production part numbers and moved to a directory for released parts.

All CAD issues aside, this type of segregation between parts under development and released parts is a key concept. "Release" is a sacred line that can't be violated. Unreleased parts do not get used on released assemblies, ever. If one needs to use a released part for a development project, it's in the "vault". It gets used as-is, where-is, and not copied.

"Great ideas need landing gear as well as wings."--C. D. Jackson

 

[phlyx]

Good point! Definitely "in process" parts are segregated from production parts because they are not static parts and have several levels of examination and approval before releasing. They are given temporary names and would be held with the projects while in development. Also, without PDM parts being revised also need to be locked.

The structure I plan on (without PDM) holds all drawings (SLDDRW) files in one folder and this folder is read-accessible by anyone and the parts and assemblies are only accessible from engineering (or production to grab SLDPRT files for FeatureCAM).

Since the general public has no access to actual parts it becomes less critical to lock down part files being revised.

Or we could just break down and buy PDM..... ::sigh::

~ Phlyx ~

 

[TheTick]

http://www.cpuandsimplepdm.com

 

[Jaswu]

PHLYX,
If you have a part that is used on several machines then does your example mean there are several copies of the same part?

No. PDM/Works allows a document to exist in only one folder but it can be referenced in an "infinite"(Theorically) a amount of places. This holds true for any folder structure created in PDM.

One thing I would recommend is creating a test vault then you can try some of these things out and see for your self how they work. YOu will have to load it on a seperate machine. If I'm not mistaken the PDM/Works vault license allows you to load as many vaults as you like. On the login window of PDM/Works you can point it whichever vault you like for a given session.

Did the help thing but I still question if parts (SLDPRT) are stored in the individual project folder for which it was created and then it gets used on dozens of other projects, then locating "where" that part file actually exists becomes another episode of Indiana Jones. Why not just create all the parts in a single directory and then link to that part from the assemblies in the seperate project folders? Backups are easy then, searching is easy and revisions are a snap.

Here is an area where you might benefit from having a test vault. Check in a part then allow it to be referenced to multiple assemblies and see who the search feature in PDM/Works works.

Hope this helps.

sam

 

[phlyx]

Thanks Sam.... The situation is that we do not yet have PDM. I just started here several weeks ago and getting my feet wet trudging thru the muck. Currently when engineers would start a new project with similar parts as a closed project they would copy all the parts and drawings into the new project folder thinking this made life easier.... NOT!

So I am looking for a pre-PDM step that will help us out and make things easier when we do convince management to cut a check for PDM. My goal is to clean up the mess that currently exists by migrating all SLDPRT files into a common directory making sure that the one there is the most current and then making sure that all the assemblies now reference that part in that folder. Same goes for the SLDDRW files but in a different folder.

Had to revise a part the other day and it was a tremendous task finding all the copies out there. Any suggestions to help clean up this mess????

~ Phlyx ~

 

[JJCPE]

I am also looking for a pre-PDM step and have the advantage of no muck to trudge through. I'm a project manager in charge of a series of medical device product development projects for which no formal system exists to handle the electronic files. We'll purchase PDMWorks when the time comes, but for now it's more important to set up the conceptual life-cycle, file name conventions, revision handling, vaulting etc.

The first project is lightweight, with only a handful of parts (well, maybe two hands full), and can be managed easily as a test case.

I want to Keep It Simple, Smart. The engineers and designers are working from several different geographical locations, so file transfer via email will rule the day. The development process will create several prototypes before the design will be committed to CNC programming and mold making.

In the prototype stage there will be several parts that are created via stereo lithography directly from electronic files (no drawings), as well as machined parts that will be sent to prototype shops as models (the shops will create their own drawings or sketches to build the parts).

There will also be models of off the shelf parts for which there will be no drawings, so while I can understand the idea of the drawings driving the system, (parts don’t exist without drawings, or some sort of document that drives purchasing – maybe just an isometric or perspective view with notes and title blocks driven by custom document parameters?).

As a project manager, I’ve played with the idea that the product (and therefore the project) can be driven by a ‘master model’. As work progresses, the models are ‘released’ to the ‘master model’, which is an assembly of all the part models, and the product takes shape.

Using kinematics principles, a datum is a surface that establishes the final location of parts which come into contact with each other in one degree of freedom, so one of the ground rules would be to clearly understand, and identify, those features. Obviously, those then become the features used to form the mates within the master model. Therefore, a designer or engineer hasn't finished a part design without establishing those features. The work of inserting the parts into the 'master model (subassemblies and top 'assembly) is simplified, and revisions, configurations, and versions become interchangeable.

How to go about establishing guidelines for naming such features is not so easy to define (I could use some help here).

With a clean sheet to work from (no formal document control exists for development work) I have a maximum of flexibility, as well as a maximum of potential for going the wrong way.

I like the template posted on the SolidWorks website for SolidWorks implementation, but would love to see a section of it devoted to PDMWorks.

Anyone seen such a template?

Can anyone recommend a good book on the subject of PDM (both data and file management)?

Any suggestions?

John

 

[StarrRider]

phlyx

I’ve been up and down this road several times, and it really is easier than it sounds. There are a couple of things to keep in mind.
The first is that if you create a directory for your common files (parts, assemblies, drawings) on your network then sooner or later – something will cause you to change the name or location of those files. In my last position it was a hard drive that crashed. When the drive was replaced, the nutwork people gave it a different name - which caused a lot of trouble with SolidWorks. Eventually – it was fixed but that took a couple of weeks worth of work.
The second is that at some point you (or someone) will want to do some work at home or on a laptop that is not connected to your network.
Both of these things are easily taken care of. First, create a network directory for your files and then Map it to a high letters like X: or Z: so that it doesn’t matter how many drives a machine may have – it will still work. This allows all of your operators to access the files easily and SolidWorks doesn’t care – as long as it can find the files.
Some or all of those files can be copied to a home system or a laptop and a command file (CMD or BAT) can be used to create the appropriate drive letter with a Subst command like this:
Subst X: C:\Docume~1\AllUse~1\Docume~1\DriveX~2

I have been told that there is slowdown when accessing a directory that contains too many files (over 500). I don’t know if this is true or not, but we made a subdirectories for every product line. With our numbering system, that limited the total file count to about 1000 files but most product lines only had 300 or 400 fabricated parts, all purchased parts were on a different mapped drive.

I would also recommend that you place all of your common files on this drive. That includes your Templates, Macros, Excel spreadsheets – everything and anything that SolidWorks uses – and then configure SolidWorks on every machine to use those files. The Major advantage is that everyone will be working on the same page. If something needs to be changed or fixed then the change is made to every system. Another advantage is that your network should be backed up nightly where your systems probably are not.

Lee

Consciousness: That annoying time between naps.

PS - I like your cat

 

[StarrRider]

JJCPE

Please check out the thread that EdDanzer

mentioned. A lot of what you are asking about was discussed there. At least there are some thoughts that you might find revelent about file naming and numbering systems.
To be honest, a lot of this has to do with personal preferences and how you work. Personally, 90% of the files I open are located with Windows Explorer. The same thing is true with the parts that are inserted into an assembly. For me - it is simply easier to do a Flag-E (starts Windows Explorer), move to the right directory, and double click the file or drag it into an assembly. Not everyone works this way.

I do several things that may help you out a little. Most parts have 2 configurations: Default and Detailed. The Default configuration has as little detail as possible. It has the basic shape of the part but everything that can be suppressed is. All of the fillets, flanges, and other misc. BS that I simply had to include are suppressed. The Detailed configuration is used in Drawings but that is about it. SolidWorks is fairly responsive when the amount of detail a part possesses is limited – even with large assemblies.
Assemblies always have several configurations including: Default and Doc. The Default configuration is where 90% of the work is done. The Doc configuration is dedicated to the Drawing. Each part is changed from Default to Detailed so I can make pretty pictures with them. If I am creating a multiple page drawing, I will add additional configurations for each page in the drawing. IE “Doc – Page 2”. This prevents having to worry about what a simple thing like a hidden part will do to the drawing or whether my balloons will be pointing at nothing. I also find it a lot faster to hide things at the assembly level than to hide them in a drawing. This may be a personal preference – I haven’t experimented with some of the things that I learned the hard way back in SW99 – I just keep doing them and marvel when I find something new.

For the other things, I’m not sure if I can help or not. I’ve been making automated machinery for quite a while and SolidWorks lends itself to it. When I start a new machine, I know what most of the major subassemblies will be. The TLA will have a Frame, Electronics, Pneumatics, Skins, and a few fasteners holding them together. Most of these assemblies are created and inserted into the TLA before they have anything in them. They allow multiple people to work on the same project at the same time. All that is necessary is that they open their subassembly before the TLA is opened. When enough detail has been added to the subassemblies, the TLA is opened and mated. Most of the time, the TLA doesn’t have to be opened all that often, once or twice a week at the most.
For us, the Frame assembly is the key. Everything is dependent on it or is bolted to it. Most of the assemblies have it inserted in them at some point or another. Other assemblies (like the Skins) have it as a referenced part that actually holds them together.

Lee

Consciousness: That annoying time between naps.

 

[JJCPE]

Thanks Lee (StarrRider), your discussion of TLA (I assume you mean 'Top Level Assembly') is helpful, particularly the concept of different assembly configurations. I've yet to really use such configurations, but can see how they would be very valuable, and it's nice to know someone has traveled that path before.

By the way, I've marked the thread on Numbering Systems. It was so long I haven't yet read the whole thing, (although I couln't resist tossing in my two cents) and will probably copy it to a word document and try to summarize it.

Do you use PDMWorks? if so, what is your experiance with multiple configurations when using PDMWorks?

 

[StarrRider]

JJCPE

Yes – TLA means 'Top Level Assembly' – at least to me. We had a lot of trouble with controlling Drawings when we first started with SolidWorks. There were 2 Engineers who never created drawing, 2 who did, and an overworked Draftsman who only worked on drawings (not me – I was one of the 2 who did). The problem was that an assembly would be opened and parts would be selected from the screen and hidden or suppressed. The next time the draftsman would open the drawing for that assembly – the Bill of Materials would have changed, Balloons would disappear or be pointing into space – and occasionally – the views would be screwed up (we had one Engineer who insisted on reorienting the assembly for – I have no idea why). As a result, the draftsman spent more time fixing drawings then he did creating them. We implemented the Doc configuration and then our draftsman had to make sure that he saved every assembly in the Default configuration because our 2 Engineers (who never worked on drawing) – well – they couldn’t take the time to see which configuration they were in before they began hiding things.
We implemented the Default / Detailed configurations with SW2001 when our Top Level Assemblies started taking 45 minutes to load and selecting a single part took about a half second. Really SLOW! Purchasing new systems did help a lot - but the writing was on the wall.

I did use a PDM product a long time ago with AutoCAD but I have never used PDM-Works.

Lee

Consciousness: That annoying time between naps.

 

[JJCPE]

Thanks again Lee for the reply.

The bottom line is that discipline is the number one requirement for this kind of work when others are involved.

Since discipline doesn’t come naturally to everyone, it takes some accommodation (or brute force!).

Years ago I worked for a medical device company where document control was EXTREMELY controlled. I started referring to the document control clerk as the ‘Gatekeeper’, always with the understanding that if you are going to control the documents, you should post a sentry at the gate.

I finally realized that when doing creative work, discipline can get in the way. So I came up with the sandbox analogy. Know when you are being creative (playing in your sandbox), and when you are doing the more mundane things that are required to get your creation off the ground (such as releasing your creation through a release, or change order).

When in your sandbox (your own personal workspace), it’s yours, do what you want. But as soon as your creation is passed beyond the sandbox boundaries, focus on the discipline (which is usually spelled out in a procedure somewhere).

I’m now in a situation where there is a virtual team of engineers and designers (not very large). It’s a virtual team because we are all working from different geographical locations.

The company has no procedures that govern the details of how electronic files are handled. I’m not even sure that there is a procedure for the assignment of numbers. As the Project Manager, it’s up to me to establish ‘best practices’, and work things out to get the project done as efficiently as possible.

When the part count gets high enough, we’ll invest in PDMWorks, but for now, we’ll invest in some head scratching to establish practices that will be enhanced by PDMWorks.

I’m a firm believer in the adage: Document what you do, do what you document.

The emphasis is on first doing things well, and then documenting that.

John

 

[EdDanzer]

JJCPE,
I like you sandbox analogy. As I have stated in prior posts, we use Excel to track part numbers by category. For starting out in a development, or small group this may be all you need. Even though I hate it sometimes, the cost is low. The biggest problem is remembering the category to look under when an item has 2 or more common names. Even though the master sheet starts out with reasonable subcategories, some items are hard to define. Probable the worst is how electrical and electronic components are sub divided in our current system. We have 32 primary categories, and many subcategories in each primary category. If anyone would like to see the primary layout I can email the Excel file. Please remember this work was done in 1996.

StarrRider,
If I were the draftsman, I would document the time wasted by the lazy engineers not protecting prior work, and submit it to the CEO. It could amount to thousands of dollars per month.