I'd recommend you should have PDM standard (a new version of wPDM) which you can prevent identical parts and better revision tracking
if you own pro. or premium SW lic along with manual subscription, then PDM standard is included without any extra cost
Thanks, but as stated, we are trying to avoid using PDM.. WIth only 2 designers and no on-site IT staff.. setting that up and learning to use it properly is going to be way too time consuming at this point.
Also, we are "standard" users, so PDM is not included with our licenses. So really, PDM is not even an option for us. ¯\_(ツ)_/¯
That said... Any other ideas?
Ive been reading a few similar threads.. but most are several years old, so just seeing what ppl are doing today.
So for now how you guys control revisions?
Here is my suggestion:
1) Create a company archive folder for old revision parts
2) Save only current revision on the working server
2) Add revision letter to file name such as Part_A.
3) Then each time you bump up a new revision, save (use PackNGo from an assembly including the new revision parts) the current revision to archive and save new revision the the working server
4) Create a Library folder in the server and one of you will act as admin. Whenever, a new standard part is create, let the admin guy save std parts to the server
5) update standard parts from server to local not another way
still a problem of parts sharing between the project and it's hard to control without PDM system
Well, right now work out of directories on our local systems & after hours everything gets replicated to a cloud box. This setup is far from ideal, but its what was here when I started and it has worked OK thus far.
Like I said tho.. we aren't usually working on the same project so its a rare occasion that we are both trying to open the same assembly or model. So, in that regard, he manages his revisions and I mange mine.. then both get updated to the cloud via after hours automation.
We track our revisions with hard copies of all updated files, so there is the current revision set, which lives in the project's root folder, and the "sunset" or "out-dated" revisions which get bumped to a "sunset" sub-directory of the project root.
We do have a few standardized parts (mostly laser cut / formed parts & nuts / bolts) that get added to a lot of our products. Those files are essentially fixed and do not change, which is why they live in the "standard parts" dir. On a rare occasion they do need to change and so once every month or so, I'll go "hey Joel, I updated 2003934-A" & he'll pull down the updated revision from the cloud, as needed.
These standard parts do not typically change physically, maybe I'll just add a sketch entity to help me place a mate in a new assembly.. something to that effect.. in that case, I think I'm still OK just saying "hay, I updated that file" because nothing there previously was destroyed in the update, so none of his assemblies or mates should be affected.
I'm sure I'll be getting a major "youre doing it wrong," here momentarily -- to which my response is: Why do you think I'm asking this question?!
Again, for any new readers - we do not want to use or pay for PDM.. just looking for the best / easiest alternative.
So basically, you just track back the old revision based on the old 2D hard copies? No need to retrieve old 3D models?
then what's you doing here is fine !
By the way, how you handle sharing parts between projects?
The latest revision of all files live in the project's root folder. All frozen revisions have their own sub directory in the "sunset" folder, which lives in the project root directory
We save a duplicate of each 3D model, assembly, drawing & matching PDFs with complete drawing number & revision in the file names, e.g.,
<project name> <model name> <drawing number>-<drawing revision>.<filetype>
So, my dir tree looks like this:
[user0322@radium]$ ls -R /usr/storage/A-WALL/
A-WALL 2-HOLE BRACKET 1001235-C.PDF
A-WALL 2-HOLE BRACKET 1001235-C.SLDDRW
A-WALL 2-HOLE BRACKET 1001235-C.SLDPRT
A-WALL VERTICAL MEMBER 1001234-C.PDF
A-WALL VERTICAL MEMBER 1001234-C.SLDDRW
A-WALL VERTICAL MEMBER 1001234-C.SLDPRT
A-WALL VERTICAL WELDMENT 1001233-C.PDF
A-WALL VERTICAL WELDMENT 1001233-C.SLDASM
A-WALL VERTICAL WELDMENT 1001233-C.SLDDRW
A-WALL 2-HOLE BRACKET 1001235-A.PDF
A-WALL 2-HOLE BRACKET 1001235-A.SLDDRW
A-WALL 2-HOLE BRACKET 1001235-A.SLDPRT
A-WALL VERTICAL MEMBER 1001234-A.PDF
A-WALL VERTICAL MEMBER 1001234-A.SLDDRW
A-WALL VERTICAL MEMBER 1001234-A.SLDPRT
A-WALL VERTICAL WELDMENT 1001233-A.PDF
A-WALL VERTICAL WELDMENT 1001233-A.SLDASM
A-WALL VERTICAL WELDMENT 1001233-A.SLDDRW
A-WALL 2-HOLE BRACKET 1001235-B.PDF
A-WALL 2-HOLE BRACKET 1001235-B.SLDDRW
A-WALL 2-HOLE BRACKET 1001235-B.SLDPRT
A-WALL VERTICAL MEMBER 1001234-B.PDF
A-WALL VERTICAL MEMBER 1001234-B.SLDDRW
A-WALL VERTICAL MEMBER 1001234-B.SLDPRT
A-WALL VERTICAL WELDMENT 1001233-B.PDF
A-WALL VERTICAL WELDMENT 1001233-B.SLDASM
A-WALL VERTICAL WELDMENT 1001233-B.SLDDRW
If we make a new revision, the previous gets rolled into its respective "Sunset" dir and the new revision takes up residence in the project root.
If an assembly requires one of our few standard parts, the tree above stays unchanged, and the external references in the assemblies will simply point to the "standard parts" directory, which lives in the parent directory of the the project's root, e.g., /usr/storage/STANDARD PARTS
There is probably room for improvement here, but this is working, & just trying not to wrench things up with an all new workflow .
Tony, I have not. Will need to do the reading on how that feature is supposed to function.... Thanks for the pointer.
I am a 1-man band and I implemented PDM Standard when it came out with 2016 (I was thinking about Workgroup PDM). Your VAR can help with the setup. I have done no fiddling with it since I set it up, so your concerns about needing IT are unfounded. The key is to decide on your workflow before you implement. In my opinion, the benefits far outweigh the setup effort.
Bill, I hear ya..
We are a small shop, but owned by a much bigger corp. Corp IT will administer the new network file server and getting them to setup a file share is one thing, but enlisting them to take part in configuring PDM, on the other hand, is a total pandora's box. Looking a boat loads of paper work, change requests, software install requests, conference calls with them and with VAR, process diagrams, maintenance windows, etc. In the end, after all that effort, they'll probably just say, "no." So, we do have IT, they just live in far off lands and give us a hard time whenever we ask for something even slightly outside their preferred scope (which is pretty normal for any big company! ¯\_(ツ)_/¯).
Being a former IT droid myself, I fully understand the value of doing it right, and if I were a 1-man-solidworks-band, so to speak, I would have taken the time and gotten things right from the get go.
Reality being what it is, I came into an existing framework and have survived thus far. We are making progress, and want to keep things simple.
Some good suggestions here from all.. thanks for the feed back!