Drawings - multiple sheets vs. multiple files

I'm evaluating SolidWorks. Our typical drawing sets consist of anywhere from 3 to 100 pages, one part per page, with about 30 pages being typical.

My thought is that we'd do all drawings in one file, and put each part on its own sheet. The benefits that I see are:

-Pages can number incrementally (automatically)

-Project related properties are stored in the drawing file

-Printing is simple

The alternative is that every part has its own single-sheet drawing file. I imagine that printing would be more difficult, and I'd have to enter project related properties in each file. What about page numbers? If I needed to add a page right in the middle of the set, would I manually have to renumber all pages (files) after that?

Does anybody here use multiple sheet drawing files--is there a major hit on performance in drawings with multiple sheets?

I look forward to your responses. Thanks.

Brian

Reply to
Brian Mears
Loading thread data ...

Brian, IMHO (in my humble opinion), it is not nearly as practical in SolidWorks to try representing multiple parts in a multiple sheet drawing as it is to represent one part per drawing . . . with some exceptions. I'll talk about the exceptions last.

I believe you WILL notice a substantial performance hit to a drawing that has 6 or more sheets, and much, much more so for 30 sheets or more. In addition, if you have a problem with ONE part, it will affect the entire drawing . . . slowing down the rebuild for every sheet. And I can't even imagine how you would deal with revisions in your system.

Regarding the "benefits" that you see to storing many project parts in one drawing file:

- I'm not sure whether what you're saying is that you're aware that one can easily set drawing templates up to automatically increment the sheet number and give the total number of sheets in the drawing (and automatically update all sheets as well if you add a sheet). But whether you do it as your company is wont or not, that capability is no especial benefit reserved to one way or the other.

- Project related custom properties can be stored in a drawing or in the part itself, and there are advantages and disadvantages to doing it either way -- again, not particularly specific to your way of keeping numerous parts in one drawing or otherwise. You are maybe not aware of how easy it is to change custom properties and to customize Part files and Drawing templates. There are numerous ways, from free macros to not-so-free add-ins to simply cutting and pasting from an already prepared spreadsheet into a design table in the part file to including custom properties in the Part or Drawing templates that you use. Once you understand it, it's falling-off-a-log easy. Getting to understand it well might take more than a day or two. Figuring what's best for your way of doing things requires understanding it well.

- Printing is pretty simple anyway, and can be facilitated by batch print macros or VB routines which are common and mostly free. Not always free of glitches, but free anyway. What is more important than whether your parts are all in one drawing is whether your printer and printer drivers are friendly and relatively bug/glitch-free.

I use multiple sheet drawings all the time . . . but typically to describe either sheet metal parts (I show the flat pattern on the 2nd sheet) or parts with multiple configurations (dash-numbered parts) or mirror-image parts, or assemblies with multiple configurations. There's no reason NOT to use multiple sheet drawings, but as I said in my 2nd paragraph you WILL run into some substantial drawbacks of using huge numbers of sheets in one drawing.

Hope that helps, Mark 'Sporky' Stapleton WaterMark Design, LLC

formatting link
Charlotte, NC

Reply to
Sporkman

Brian,

I worked with a large assembly model at my last job and it was absolutely necessary to only use one sheet per file. There were exceptions with the fact that children views cannot be put into a separate file from their parent (think section views). In your case, I'll assume you are using dash numbers for the parts, I would also advise you not to put all those sheets in one file. For one, it's like putting all your eggs in one basket, and if something were to happen to that file you'd be up the creek. There will also be performance issues because everytime you save SolidWorks is going to want to update all those sheets. And guess what SolidWorks wants to do when you want to open that file? Update all the sheets. I would also advise you not to take the 'one file' route for revision change reasons. It would be too cumbersome.

To sum it up: Use separate files for each sheet!

Reply to
Jeff N

Brian,

Be aware that if you use the single file method the BOM's are a bit of a pain. I use a single file for multiple drawings where the first sheet is the assembly or sub-assembly and the other sheets are detailed views of the parts in that assembly. The BOM on the first sheet will list the item numbers and quantities just fine; however, (short of an awkward workaround) when you put a BOM on one of the part sheets it will not reference the BOM on the first sheet but will use a new item number and list the quantity of the part being detailed on that sheet (in other words the quantity will be one). I am curious to know how those who do one part per file do their BOM's. How are item numbers and quantities kept straight??

Reply to
Brad Goldbeck

can you enlighten me, why would you have more than one bom per drawing?

can you expand on this?

Reply to
kenneth b

We generally farm quite a few parts out to local machine shops. In most instances the assembly information is not given for confidentiality reasons. My main issue is not the item numbers but the quantity. If I want three pieces made to satisfy the quantity needed for the assembly, I don't want to have to manually enter the quantity (and I don't know the API well enough to write a macro).

You have an assembly drawing with a BOM. Next you have a part drawing that a machine shop will use to produce a part for the assembly. How do you tie the two together so the correct quantity of parts are made when all the shop gets is the part drawing and not the assembly drawing?

Reply to
Brad Goldbeck

imho that's excellent reason not to have piece part drawings in assembly drawing. with separate piece part drawings you can have;

  • title block, p/n (- dash) & description
  • general & specific notes that apply to that individual part
  • no missing sheet numbers (e.g. 1 of 1)
  • a bom (our main use here is sheetmetal parts with pems)

our purchasing dept uses an MRP system for generating po's. quantity per is in the system. you could "save as" the assy bom to excel and give that to your purchasing dept.

my .02

Reply to
kenneth b

I have heard of this before (putting qty on the part drawing). BUT, I am a bit confused as to why this is desirable. IMO, a drawing should contain all necessary information to build THAT PART. Anything else just ends up being more work down the road.

If you include a qty on the part drawing, what happens if that part is used in multiple assemblies? (assembly A uses 10 part Xs and assembly B may use 2 part Xs)

What if you order 10 assemblies? Now your qty must be multiplied by 10 (manually).

We do as Ken. When there is a request for an assembly, purchasing places an order for the required number of parts. The vendor/manufacturer of that part has no idea where the part is going or how many are required 'per assembly.' They only know they need to make x number of parts. An MRP system can be used to automatically tally up the required quantities and/or due dates.

Reply to
Arlin

When you only make the assembly once, it saves some time in the shop to have the qty req'd on the part drawing. If the part is used again in another assembly, it will probably be copied with its part drawing and assigned a new number.

Obviously, this doesn't make sense for everyone.

Reply to
Dale Dunn

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.