That’s debatable.
It make the symptoms of the mistakes more obvious and the history data is helpful when back tracing who did what. But I’m far from convinced PDM reduces mistakes in and of itself. Users are still people. The ones that caught on to PDM weren’t causing problems in the network shares, they paid attention to what they were doing. The ones that silently (often ignorantly) buggered things in the network shares are still screwing things up in PDM, it’s just harder to fix in PDM.
I just like the referenced or as-built version system it uses for assemblies. Like if Assembly A was built with version 7 of a bracket, then I modify the bracket to version 8 to put it into Assembly B, then Assembly A is un-changed because you can still get the as-built version of the assembly and it will get version 7 from the vault.
This is a huge difference because to do something similar outside of the vault, you’d have people copying and changing things and potentially causing unintentional references to the old part to point to the new part and losing traceability and accuracy.
Yes, I got some files from PDM and later found out I got the wrong version.
No sure what happened.
Now I need to check and make sure I’m getting the latest one.
Exactly. When asked, “What is your favorite thing about PDM?” my response is “Version History”. When asked, “What is your biggest pain point with PDM.” my response is, “Versions”.
Our users have wrong version most of the time. We’re trying to get to where we can just always use latest but many roadblocks for that. Testing an add-in from jsculley that gets referenced version by default instead of latest or just using whatever is in cache.
From what I can tell it all depends on the design to manufacture and support workflow. PDM is built around the premise that there is a project that gets designed and all the CAD Collaborators are using latest versions of everything. Then there is a design freeze on the whole project and the whole thing goes to be manufactured. Any part in that project that is not unique to that project is a “standard part” or COTS and those components are not revised. In that workflow the boiler plate answer to version problems of “change the group setting to always work with latest version” is helpful.
Except you can see and undo what they did in PDM. Even the most organized and careful users would mess things up on our network. Files get accidentally deleted or overwritten and there is no network recycle bin nor versions that work well. Often I had to get our network guys to restore files and folders and you had to tell them the exact date and time, difficult when you don’t know when something happened. It might be 2 years later trying to figure out what somebody did.
So in my experience, it’s much easier to fix in PDM…I can do a rollback or restore a version and recover from the PDM recycle bin. When we get internal ID issues in assemblies, I can see that user “X” saved over a legacy file (against our standard) and messed everything up.
You guys are talking about Version history. Do you mean Revision history?
Yep, mostly agree with that. Like in earlier post; my favorite part of PDM is version history, my least favorite part of PDM is versions.
Revision is pretty much just a number applied to a version.
To me (and maybe I am not understanding this properly) a revision is a milestone. When a change to a part is required, a new revision is generated. Versions are something that happen in the background and are mostly meaningless until they are committed to a revision.
Every check-in creates a new version. Versions are not meaningless, especially if you want to explore alternate design ideas during the design phase. Just check the current file in and then modify things all you want. If you decide the option isn’t working out, just don’t check it in and go retrieve the previous version and you are back where you started.
Didn’t read the whole thread but my first though was exactly what JSculley wrote
The answers to your questions really depend on your answer to this question:
What problem(s) do you hope to solve or objectives to you hope to achieve by using PDM?
Judging by your answer that currently you have performance issues opening the files I assume you have the files in Windows File Share. Those basically always use SMB protocol that is very sensitive for network latency (not speed) and this is especially problematic when accessing multiple small files; e.g. when opening SW assemblies from file share. I’ve understood that CIFS protocol based file shares don’t have as bad overhead issue but I’ve honestly never seen one in use either; at least to my knowledge.
So yes, in my opinion, PDM Standard will solve your issue at hand. However, note that PDM is also somewhat demanding what it comes to latency so e.g. cloud hosting PDM’s SQL Server especially outside your region also might yield poor performance. SW considers 50ms ping already a high latency case for PDM, which is quote usual for e.g. standard sized Azure or AWS servers.
Consult some expert before migrating files to it so your existing custom properties etc get properly mapped to Variables and indexed on first check-in. For workflow I’d suggest something minimal; e.g. this: https://imgur.com/2pouP7h
When file moves to Approved, it cannot be edited anymore. First visit to Approved sets revision to A and every Approve New Revision increments it (A->B, B->C etc). Revision letter is usually mapped as Custom Property in drawings. Editing is allowed in Under Editing (initial state), Revising and Under Minor Change. Under Minor Change is a bit controversial. It allows doing “minor modifications” without doing a new revision but that gives some dangerous power for designers, which some consider total herecy. But in practice in the field I always see the need for that, and that transition can be restricted e.g. for “lead designers” only.
I only suggest this workflow here because I often see people implementing the default one with “Waiting for Approval”, “Change Pending Approval” and such states which often make absolutely no sense for the design team’s actual workflow; at least in the beginning. Then they anyway later introduce Obsolete state and fast lanes around revisioning, and maybe some business specific states too that actually make sense for them. But PDM Standard has its state/transition count restrictions and you can’t delete any states that any file has been even once, so the lesson here is that you need to start with minimal workflow.
One thing that PDM Standard lacks compared to Pro is Serials. Those are very useful for file naming. How have you managed file naming until now? How about Custom Properties?
No one uses Branch and Merge? Not part of Standard though.
I’ve looked at it, but it’s difficult to maintain traceability (IMO) to the branches from the main part. And with how difficult it is for some users to grasp versions, I don’t want to give them added complexity of branches and merges. It’s similar enough to copying the source file and saving over top of it with a modified version if you like the changes.
We’re trying to figure out how to use it so we can do CAD work during EC evaluation yet leave the files in Released state. I’ve tried B&M a couple of times and it becomes a huge mess. Boils down that it creates more complication than help compared to just using Copy Tree and manually merging the files once the EC is approved. I could list the short comings we’ve ran into but it’s off topic for this thread, AFAIK B&M is only available in PRO and the original question was whether or not to make use of PDM Standard that’s included with the users SW Prem subscription.
I don’t think PDM will make things any faster, if anything it’ll make them slower. Think of it as a database. What use is a database if it’s filled with useless data and isn’t sorted out?
Instead, figure out what causes the slowness, go up your assembly from the root to the top and try and notice when there are performance distinctions like a rebuild. External references are a start, graphics is another easy tweak. unnecessary rebuilds can be “blocked”, etc…
The Evaluate Tool is also a great tool to work with to try and troubleshoot these issues.
Some read on Windows SMB Client side tuning:
https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/
Make sure to log the changes and results.
Save current settings in a reg file. New settings in another.
The nice thing about that setup is that it is easy for an admin to cleanup little things like turning off planes and sketch on files that are released. They don’t change the drawing but make for a messy assembly.
Does it help when you need to save an old file in a new version of SolidWorks? I’ve heard that can be real issue if the version can not be bumped without changing the revision of a released file.
For the O.P. before PDM I would store a pack and go every time I made a big change but could never find the old version I wanted. PDM makes that much easier. One place I worked had the same problem you do with working on the network shares. I also thought PDM could be the fix. It is much better than downloading the entire assembly every day.
Admin can just check the file out in released state (or any state for that matter) to do little fixes, AFAIK there’s no need to change state for admin fixes.
Updating versions can be automated. Again, with correct user logged in when the task/program runs there’s no need to change state. But versions are the double-edged sword; keeping all the assemblies pulling latest version can prove difficult in some cases.
Sounds like signing the admin up to do work someone else should be doing. Much like CT-Simo I created a Non-Revision Change transition for this. If a user releases a drawing and then realizes there is a typo or something, they can simple Non-Rev Change, check out, correct, check in, Finish Change. As long as the files haven’t escaped the Engineering department, non-revision changes are generally used. Once the files are let loose to the outside world, non-rev changes are only allowed if they don’t change the part. For example, if a part drawing is missing an overall length dimension, adding it is a non-rev change. If the part is at a vendor, there is no harm, because the vendor can’t make it without the length.
If you non-rev change a part, you have to non-rev change the associated drawing (if there is one). If you don’t the drawing PDM tree will list the part reference as out of date.
Were had been avoiding letting users do no rev changes at will, but we’re learning it’s just not practical and adding transitions for users to do no rev changes. At least now we have version history so the troublemakers can’t use the “I don’t know how that happened, wasn’t me!” line. So the concern of bad, no rev changes has changed scope.