Drawings packages - best practice
Drawings packages - best practice
We do a lot of projects that are similar to previous projects. So we usually Pack n Go with a new name to a new folder. For various reasons, we have decided to start putting one part per drawing sheet, regardless of drawing size/complexity.
We were going o save the drawings with a 2-digit number added to it to help group drawings together. But that doesn't work, because next time we try to pack n go, it won't carry the drawings.
How does everyone else structure your drawing packages? ...in a way that the assemblies and all related drawings can be PnG'd to the next similar job?
We were going o save the drawings with a 2-digit number added to it to help group drawings together. But that doesn't work, because next time we try to pack n go, it won't carry the drawings.
How does everyone else structure your drawing packages? ...in a way that the assemblies and all related drawings can be PnG'd to the next similar job?
Re: Drawings packages - best practice
Is the drawing in the same folder? What version of solidworks?
I dont recall having issue with different drawing name...
I dont recall having issue with different drawing name...
Far too many items in the world are designed, constructed and foisted upon us with no understanding-or even care-for how we will use them.
Re: Drawings packages - best practice
You may want to consider a completely different approach. Rather than using pack and go for the entire project (which probably duplicates a lot of files that you won't be changing), just pack and go (or Save As) the top assembly. As you work on the new design, any part/assy that you need to make changes to, make the part (and any subassemblies above it) virtual. When the design of that part is complete, save the part in an external file. I typically use a name like WAS XXXXXX, where XXXXXX is the name of the original file. When the time comes to do drawings, you can search for any files in the project folder that start with WAS and then Save As the original drawings with new names matching the WAS XXXXXX format. Use the References button in the File...Open dialog for the drawings to point them to the new WAS XXXXX files, clean up the drawings and move on.
Re: Drawings packages - best practice
Now, we don't PNG the entire job. For example, we always name our main job assemblies XXXX-999. Each main subassembly within the main job is XXXX-9XX. Currently, our drawing packages have all the part drawings included with the subassembly drawing. Those get PnG, to the new job folder, and the job gets "reassembled' in the new main assembly (the new XXXX-999). The way we had been doing this is open each XXXX-9XX drawing, and PnG that to the new folder. It does bring the assembly, parts, and drawing package. BUT, even if you uncheck "include suppressed items" it brings them... and frequently brings other unnecessary assemblies and parts.JSculley wrote: ↑Thu Nov 09, 2023 9:11 am You may want to consider a completely different approach. Rather than using pack and go for the entire project (which probably duplicates a lot of files that you won't be changing), just pack and go (or Save As) the top assembly. As you work on the new design, any part/assy that you need to make changes to, make the part (and any subassemblies above it) virtual. When the design of that part is complete, save the part in an external file. I typically use a name like WAS XXXXXX, where XXXXXX is the name of the original file. When the time comes to do drawings, you can search for any files in the project folder that start with WAS and then Save As the original drawings with new names matching the WAS XXXXXX format. Use the References button in the File...Open dialog for the drawings to point them to the new WAS XXXXX files, clean up the drawings and move on.
The bottom line is, what we would like to do is make a separate drawing for each part. But have a good way to be able to group the drawings for batch printing when someone needs all the drawings for XXXX-931 or what ever.
- Glenn Schroeder
- Posts: 1527
- Joined: Mon Mar 08, 2021 11:43 am
- Location: southeast Texas
- x 1777
- x 2142
Re: Drawings packages - best practice
You said you have one part per drawing sheet, but the rest sounds like you have one drawing file per part. Have you considered all the drawing sheets in a single document? That is what I do (except for my library parts), and it would eliminate the Pack and Go issue.Micallen wrote: ↑Wed Nov 08, 2023 2:36 pm We do a lot of projects that are similar to previous projects. So we usually Pack n Go with a new name to a new folder. For various reasons, we have decided to start putting one part per drawing sheet, regardless of drawing size/complexity.
We were going o save the drawings with a 2-digit number added to it to help group drawings together. But that doesn't work, because next time we try to pack n go, it won't carry the drawings.
How does everyone else structure your drawing packages? ...in a way that the assemblies and all related drawings can be PnG'd to the next similar job?
"On the days when I keep my gratitude higher than my expectations, well, I have really good days."
Ray Wylie Hubbard in his song "Mother Blues"
Ray Wylie Hubbard in his song "Mother Blues"
Re: Drawings packages - best practice
I'm probably missing details of the specific use case, but this sounds similar to what we run into with purchase assemblies where we own the design, to the piece part level. We looked high and low to find a way to make a drawing have sheets from other drawings. Almost like an assembly file has part files, we wanted a top level drawing to be able to "import" or "link" to sheet(s) from other files. In the end we gave up and collated the sheets after they were in pdf format. It's a manual process, but we found it better to not try to do this in SW. It's on my back burner list to write a stand alone tool that given a drawing number will go get that pdf, then the sld files it came from and recurse down the ref tree and grab all the pdfs from all the drawings and put them together into one pdf document. Unfortunately my time has been on other things.
Glenn has a nice idea if most of the parts are unique to each project. I would encourage against putting parts in more than a couple of drawing files. The file reference structure gets nasty otherwise. If you have PDM do not put a common part directly in a bunch of assemblies; your File Reference Dialog along with WhereUsed and Contains will become a nightmare!
Glenn has a nice idea if most of the parts are unique to each project. I would encourage against putting parts in more than a couple of drawing files. The file reference structure gets nasty otherwise. If you have PDM do not put a common part directly in a bunch of assemblies; your File Reference Dialog along with WhereUsed and Contains will become a nightmare!
- Frederick_Law
- Posts: 1952
- Joined: Mon Mar 08, 2021 1:09 pm
- Location: Toronto
- x 1648
- x 1477
Re: Drawings packages - best practice
I treat each job as new job. Since we don't "stock" any part.
Each job has a job number. Usually use the "Order", "Quote", "PO" number from sale.
I add: -00-00-00 after job number ie 25621-00-00-00
First 00 - Assembly
Second 00 - Subassembly
Third 00 - Part
Similar job will be "Pack and Go" and change the "Job Number.
Nothing linking to old job.
Everything under same folder, named "Job Number".
We might have some "Library" or "Common" parts for some customer.
We'll reuse them from "Library" folder.
One Part, One Drawing.
I have addin (Inventor) to pdf, dxf, print everything drawing in folder.
Each job has a job number. Usually use the "Order", "Quote", "PO" number from sale.
I add: -00-00-00 after job number ie 25621-00-00-00
First 00 - Assembly
Second 00 - Subassembly
Third 00 - Part
Similar job will be "Pack and Go" and change the "Job Number.
Nothing linking to old job.
Everything under same folder, named "Job Number".
We might have some "Library" or "Common" parts for some customer.
We'll reuse them from "Library" folder.
One Part, One Drawing.
I have addin (Inventor) to pdf, dxf, print everything drawing in folder.
Re: Drawings packages - best practice
Sounds nice.Frederick_Law wrote: ↑Mon Nov 13, 2023 11:48 am I treat each job as new job. Since we don't "stock" any part.
Each job has a job number. Usually use the "Order", "Quote", "PO" number from sale.
I add: -00-00-00 after job number ie 25621-00-00-00
First 00 - Assembly
Second 00 - Subassembly
Third 00 - Part
Similar job will be "Pack and Go" and change the "Job Number.
Nothing linking to old job.
Everything under same folder, named "Job Number".
We might have some "Library" or "Common" parts for some customer.
We'll reuse them from "Library" folder.
One Part, One Drawing.
I have addin (Inventor) to pdf, dxf, print everything drawing in folder.
Re: Drawings packages - best practice
We do many custom of standard assemblies/parts.
We use Pack and Go and Copy Tree.
I direct people to use Copy Tree (including drawings).
Step 1. UNselect everything!
Step 2. Select ONLY the assemblies/components/drawings that they intend to change.
Step 3. Rename with job specific suffix (In the copy Tree Dialog box)
PERSONALLY I like to start at the top level and do a "save as" and add the suffix and then do a "save as" on components/drawings as I touch them
Side note: Can someone explain the difference of Pack and Go and Copy Tree?
I'm of the understanding that Pack-N-Go is used whenever moving out of PDM and Copy tree is essentially the same but within PDM.
Copy Tree does seem to work quicker.
We use Pack and Go and Copy Tree.
I direct people to use Copy Tree (including drawings).
Step 1. UNselect everything!
Step 2. Select ONLY the assemblies/components/drawings that they intend to change.
Step 3. Rename with job specific suffix (In the copy Tree Dialog box)
PERSONALLY I like to start at the top level and do a "save as" and add the suffix and then do a "save as" on components/drawings as I touch them
Side note: Can someone explain the difference of Pack and Go and Copy Tree?
I'm of the understanding that Pack-N-Go is used whenever moving out of PDM and Copy tree is essentially the same but within PDM.
Copy Tree does seem to work quicker.
Re: Drawings packages - best practice
I am curious what you are asking here. If you Pack'n'Go the model and drawings with a new file name and the file names have the project in the start of the file name, then they group when sorted alphanumerically. Drawing file names should match model files names and they will group as well.Micallen wrote: ↑Wed Nov 08, 2023 2:36 pm We do a lot of projects that are similar to previous projects. So we usually Pack n Go with a new name to a new folder. For various reasons, we have decided to start putting one part per drawing sheet, regardless of drawing size/complexity.
We were going o save the drawings with a 2-digit number added to it to help group drawings together. But that doesn't work, because next time we try to pack n go, it won't carry the drawings.
How does everyone else structure your drawing packages? ...in a way that the assemblies and all related drawings can be PnG'd to the next similar job?
When you Pack'n'Go a new project, just replace the project identifier (see image). You don't even need to put them in a new folder.
Dwight
Re: Drawings packages - best practice
Sadly I do not have an answer for your primary question, rather I have a question of my own.
But yes, I do believe if the drawing file has a different name than the model, It will likely not export with the PnG.
Can you not "Group" the drawings together into a single SLDDRW file and merely print the sheets separately.?
Perhaps I do not understand your requirement..
May I enquire why you would revert to such a laborious and convoluted practice..?
But yes, I do believe if the drawing file has a different name than the model, It will likely not export with the PnG.
Can you not "Group" the drawings together into a single SLDDRW file and merely print the sheets separately.?
Perhaps I do not understand your requirement..
Re: Drawings packages - best practice
pack n go and the other commands inside the RMB "solidworks" menu are not meant for PDM.
I asked sw and they told me that using those commands Inside the vault will lead to problems as those commands manipulate the local cache with db server not aware of what you are doing. So not able to rewrite the parent children relations correctly for the rest of the vault.
I asked sw and they told me that using those commands Inside the vault will lead to problems as those commands manipulate the local cache with db server not aware of what you are doing. So not able to rewrite the parent children relations correctly for the rest of the vault.