to PDM standard or not

[Peter De Vlieger]

I specially didn't want to ask this in the PDM section of this forum because I don't want just those that are actively using it to pipe in but everyone that ever had experience with it.

Background info
We use Solidworks mainly for Routing (piping to be exact) and have been using it since 2009.Our library (self made) is extensive.Except of the actually piping fittings there is hardly anything that get re-used without modification that are particular to the project at hand.
The company keeps growing and where as in the beginning there were just 3 users, we now are with 7 full time piping designers working on projects going from a something that fits into a container to complete Biogas energy plants, or in other words, from project barely 6 figures to well in excess of 8 figures, and that's just our part.

Question
1/How stable is PDM? Us having Solidworks premium, I'm talking about the one that comes with it (PDM standard) not the PDM PRO.

2/Is there anyone that use routing and that is using (or has tried) it and what are your experiences like?

3/How long did it actually take to not just have the initial setup done but actually have something that aids instead of being a hindrance? In other words, let's cut through the marketing BS and actual state real life situations. E.G.: Routing gets sold as if one can use it production wise straight out of the box when it took us weeks to get it up and running (with lots of self study and try and error) and several years to actual have a solution that works stable for our needs.

4/ How much maintenance/policing does PDM take? As in, how much time has to be spend by someone to keep it up and running smoothly, correcting things, fixing things, etc. Or in other words, even in the best situation does it only take an hour or so a week or is it something that needs lots of babysitting even when everyone is playing by the rules.

I know it's all rather open ended and I don't expect anyone to take the time to write an essay. If there are any posts or reviews that you know of a simple a link would be greatly appreciated or even a search term that I can enter in google without having to wade through the usual company/marketing BS that SW is so plentiful in spewing.

[AlexB]

I'll start off by stating I'm a PDM Professional CAD Administrator currently.

1) PDM is quite stable, but will only be as stable as your network or connection to your cloud hosting server if you go that route. There are a lot of factors to consider regarding the network infrastructure and stability but we've been using PDM for over a decade and it's been very consistent.

2) I have tried to set up routing by hosting the relevant files (databases, tag schemes, cable/electrical parts, etc.) and it worked pretty well once set up. So, with that said, I imagine copying all of your existing files to PDM and redirecting all of your solidworks clients would be relatively painless to get up and running. This could certainly be implemented and tested before fully turning all of engineers over to PDM for production use.

3) PDM in general takes quite a bit of time to set up. With PDM Standard, you're limited to something like 1 workflow with 10 file states and 20-ish transitions. The other limit is you must use SQL Express (free) but that limits your database size to 10GB which is more than enough for a small company for many many years. It takes a long time to plan the data you want to track along with the states you'd like your file to move through (Editing, Review, Release, etc.) with the permissions, data cards, and variables to accompany them. Once it's configured and tested, moving your files into the vault and beginning to use it should be a few days at most.

4) Once a system is properly set up, it typically takes very little policing to keep things tidy. For me, this stuff is usually caught during the Review process before a file is released. The bigger issue at hand is training people to work within the system and stop using files outside of PDM. Engineers can get set in their ways and it can cause problems if they try to circumvent the system that is in place.

So, PDM is not for everyone, but it is a nice system that allows only one engineer at a time to edit a file with the check-out/in and version control. Moving an existing system to PDM is no small feat so you will need support of your managers, peers and IT to be successful. Your VAR should offer the service to aid you in implementing a PDM system and transition your files into it so requesting a quote from them will give you a good starting point.

Not sure if this was helpful but good luck!

[JSculley]

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?

[Frederick_Law]

First why PDM? What are you trying to get from it? What problem you need to solve?
With PDM, users still can't work on same assembly and file at the same time.
File management is only as good as user has implemented. Crap in, crap out.

[jcapriotti]

We've been using PDM for 14 years. No piping or routing though, just big assemblies with thousands of parts. Our products are not one offs, we maintain them for years with parts over 30 years old.

The setup doesn't take real long. Migration and data cleansing and the planning around it is the big time sink and key to a successful implementation.

I'm biased and extremely comfortable with it, but even if I were a one man company I'd use it for version control and backups.

[SPerman]

even if I were a one man company I'd use it for version control and backups.

I am the exact case Jason describes here. I use PDM standard. Honestly, in some ways it is a pain in the @$$. But I won't always be a one man show, and even now it is worth the hassle for revision control and to keep me from accidentally changing something that is released.

I hired someone to setup the server for me. Based on the hours billed it wasn't too much work. My data preparation, on the other hand, took weeks.

[bnemec]

We've been using PDM for 14 years. No piping or routing though, just big assemblies with thousands of parts. Our products are not one offs, we maintain them for years with parts over 30 years old.

The setup doesn't take real long. Migration and data cleansing and the planning around it is the big time sink and key to a successful implementation.

I'm biased and extremely comfortable with it, but even if I were a one man company I'd use it for version control and backups.

@jcapriotti By maintain do you mean you're still shipping new orders of that product on a regular basis or is it providing service parts? Interested in your use case.

@Peter De Vlieger
I would agree about setup doesn't take real long, >IF< you know how you're going to use it. Granted we have PDM Pro so there's much more to uncover than in standard, but we're three years in and still trying to figure out how to fit our processes to PDM or PDM to our processes. If your CAD processes are not fully constrained by outside forces and you can align your processes to the PDM "Best Practices" that will be nice.

[AlexB]

@jcapriotti By maintain do you mean you're still shipping new orders of that product on a regular basis or is it providing service parts? Interested in your use case.

I'm in the same situation that @jcapriotti is in. We've been manufacturing the same things for decades and some product lines require part updates due to material availability changes or manufacturing improvements. These are typical sustaining engineering activities but they support an established product.

@Peter De Vlieger
I would agree about setup doesn't take real long, >IF< you know how you're going to use it. Granted we have PDM Pro so there's much more to uncover than in standard, but we're three years in and still trying to figure out how to fit our processes to PDM or PDM to our processes. If your CAD processes are not fully constrained by outside forces and you can align your processes to the PDM "Best Practices" that will be nice.

This is something that I think is overlooked on a lot of initial implementations. I just spent the last 6 months creating a new process in PDM because Revisions were never properly set up in our vault. It would be so much nicer if this were set up from the start. It's not hard to create a revision scheme so I'm not sure why it never happened.

[jcapriotti]

@jcapriotti By maintain do you mean you're still shipping new orders of that product on a regular basis or is it providing service parts? Interested in your use case.

Service parts mostly. But we do have some parts of our products that just never really change much nor get replaced. We may make new assemblies for a similar and hopefully better design but a lot of the core parts could be from the 70s, 80s, and 90s. Most really new stuff is related to electronics and cosmetic stuff the customer sees.

[bnemec]

Service parts mostly. But we do have some parts of our products that just never really change much nor get replaced. We may make new assemblies for a similar and hopefully better design but a lot of the core parts could be from the 70s, 80s, and 90s. Most really new stuff is related to electronics and cosmetic stuff the customer sees.

I see. I was thinking your products life cycles were more similar to ours but sounds like you ship once then send maintenance or upgrade parts.

Sorry Peter, I'll try to stop hijacking your thread now.

[SPerman]

Also, it is still a dss product, so don't expect it to be any better than SW.

Sometimes the file explorer gets confused. The data card is correct.

[bnemec]

Also, it is still a dss product, so don't expect it to be any better than SW.

Sometimes the file explorer gets confused. The data card is correct.

image.png

If standard is anything like Pro with the vault view/ search result columns, vs where used and contains tabs, vs data card tab vs version tab ( think I have them all?) Oh, yeah, and the Solidworks PDM add-in view. Anyway, endless variability here based on version, configuration, and local file property data.

- Data card typically shows data for local version, unless you don't have a version in cache then I'm pretty sure it shows latest version data.
- Search View results >make sure you have search all versions unchecked or it will silently include old version data in the result set. I've added the "found in version" column to the search results column set.
- If you have the data card controls set to "update all configurations" that only works when the update is done from the data card or from transition action. If the user or some other force updates the custom property that the variable is mapped to then the configs will have different data even though data card is set to update all configs. Its not a magic setting.
- Has the search result set or vault view updated recently? switching between tabs usually updates the data in the data card, where used, contains, etc. tab sometimes. But the view above that updates based on the setting in admin tool or when the search is refreshed. This is especially problematic for the users that insist on using vault view/search tool for PDM stuff while the file (or something that uses it) is open in Solidworks rather than using the SW PDM Add-in like I beg them to do.

When people would send me little screen shots like what you have it only tells me a 1/3 of the story, I need to know to explain to them why the data being presented is different and appears to be contradicting.

[Peter De Vlieger]

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?

The problem we're facing that we want to solve is the slowness of opening files. As you can imagine we use big assemblies. We created a workflow that is very modular just to prevent having massive ASM's but none the less sometimes we still have big ASM's that take a while to open/save.

We have a dedicated server on site that is solely for Solidworks files and that only us Solidworks users have access to. We got highspeed servers, highspeed connections, decent workstations with decent graphic cards and even our VAR can't find anything that we do wrong or could do better hardware wise. There for the only thing left, the only thing ouir VAR could recommend, is instead of working on files on the server is working on the files locally. Now storing files locally by manual means is complete rubbish and bound to lead to problems. This isn't 1974 but 2022 after all.

However using a PDM system combines the two. The files are stored on the server but when working on files they are stored locally. There is a distinct ,and supposedly safe, means to not run into problems with what is the latest (and correct) version and seeing that only at the moment of putting something in the vault or pulling it out the vault addresses the server, it should mean that the burden on the server is less + the access times would be better while working on the files because the files are stored locally once they have been pulled from the vault.

I can see that if everyone at the end of the day is uploading the latest version to the server that it would create a bottleneck but even so, it would mean only issues at the beginning of the day and end of the day.

HOWEVER, there is one thing that all this doesn't take into account. Namely, while some of us are working on big projects, projects that one or two designers are working on full time for several months and in some cases more than a year there are those of us that work on smaller projects. Projects that only take months, weeks or even days. On top of that is the fact that it isn't rare that we have to work on several projects, making small adjustments or big alterations, in a single day. And with several I mean up to 6 utterly different projects in a single day per person. Anything from altering material or diameters of piping to modifying general arrangement layouts. There for I kind of worry about the bother of signing things in and out of the vault. What use is it if the files open faster if the time gained is lost by the hassle of accessing the vault? Or is this just not an issue and am I just being paranoid because I have no experience with PDM?

[Peter De Vlieger]

File management is only as good as user has implemented. Crap in, crap out.

AND that's is what I'm worried about.
I don't want to have to spend lots of time on setting up something that causes lots more work for me and that frankly would barely help anyone.

[Peter De Vlieger]

@Peter De Vlieger
I would agree about setup doesn't take real long, >IF< you know how you're going to use it. Granted we have PDM Pro so there's much more to uncover than in standard, but we're three years in and still trying to figure out how to fit our processes to PDM or PDM to our processes. If your CAD processes are not fully constrained by outside forces and you can align your processes to the PDM "Best Practices" that will be nice.

Which is what I'm worried about.
In the beginning no one in the company would know what it can and can't do. What needs to be in it and what not. So sure, the initial set up, with VAR guidance and assistance (and additionally paid for) will only take a few days. However, I suspect that only then we'll see all the issues.

Also I'm worried about the fact that Solidworks has the tendency not to cater to what the user needs (let alone wants) but that they expect the user to conform to what Solidworks dictates are the "best practices" no matter how utterly against logic or common sense they are.

[JSculley]

The problem we're facing that we want to solve is the slowness of opening files. As you can imagine we use big assemblies. We created a workflow that is very modular just to prevent having massive ASM's but none the less sometimes we still have big ASM's that take a while to open/save.

...
...
...
HOWEVER, there is one thing that all this doesn't take into account. Namely, while some of us are working on big projects, projects that one or two designers are working on full time for several months and in some cases more than a year there are those of us that work on smaller projects. Projects that only take months, weeks or even days. On top of that is the fact that it isn't rare that we have to work on several projects, making small adjustments or big alterations, in a single day. And with several I mean up to 6 utterly different projects in a single day per person. Anything from altering material or diameters of piping to modifying general arrangement layouts. There for I kind of worry about the bother of signing things in and out of the vault. What use is it if the files open faster if the time gained is lost by the hassle of accessing the vault? Or is this just not an issue and am I just being paranoid because I have no experience with PDM?

There is no doubt that loading files locally from fast solid state drives will be better than over the network. And keep in mind that PDM is granular down to the file level. If you and another user both have local copies of a very large assembly and you change three files out of 1000, the other user only has to retrieve 3 files to be up to date. The bigger hit would come when you finally check in the large assembly file, but even then it is only the assembly file itself that the other user would have to retrieve. All the contained parts are already there.

PDM is also very, very, very configurable. You can set it up as nothing more than what you've described: checking files in and out. You can leave all your other existing processes in place. You wouldn't need workflows, revision control, elaborate users/groups/permisions and other PDM stuff that requires more time and effort to set up. That can be added later. You can also set it up side by side with your current system. No need to move everything in to the vault. Just pick a project and copy all of its files to the vault and take it for a spin. If you have a lot of files that are shared across projects, you'll want to keep track of what you touched if it affects other projects that aren't in the vault, but you should know pretty quickly if using PDM is better than what you have currently.

Having said that, if you decide that PDM is working for you, careful planning is required before moving everything in to the vault. The more 'correct' you set it up to begin with, the less maintaining you will have to do after the fact.

Also, if you have processes in place that work for you and users are satisfied with, it is a good idea to keep them if they don't conflict with PDM and if PDM can help automate them, even better.

[jcapriotti]

Which is what I'm worried about.
In the beginning no one in the company would know what it can and can't do. What needs to be in it and what not. So sure, the initial set up, with VAR guidance and assistance (and additionally paid for) will only take a few days. However, I suspect that only then we'll see all the issues.

You need someone who knows the system really well to help with those decisions. We didn't really have that for Windchill and are paying for it. Our outsourced devs know how to configure the system well, but not why.

Also I'm worried about the fact that Solidworks has the tendency not to cater to what the user needs (let alone wants) but that they expect the user to conform to what Solidworks dictates are the "best practices" no matter how utterly against logic or common sense they are.

This applies to most PDM/PLM systems. Best to not try and force your legacy processes into it, but change your process to do it the way the system handles it best out of the box. Not possible 100% but something you should strive for. We had a major failed $30 million SAP implementation for this very reason.

[Frederick_Law]

AND that's is what I'm worried about.
I don't want to have to spend lots of time on setting up something that causes lots more work for me and that frankly would barely help anyone.

Do you have problem with current file "system"?

When I got Vault with Inventor (20 years ago), took me a month or two to redo my files folders. Still using same structure for IV and SW.
Keep is simple. Keep all common, shared part, library parts together. Not over many projects folders.
Look at filenames and create system for them. As simple as possible.
"Smart" filenames are smart until it breaks which is often and soon.

Don't move everything to PDM all at once. Move a few projects and test.
That's what I was testing for 2 months. Check in, check out, Pack and Go. Make sure folder structure stay the same.

[Frederick_Law]

The problem we're facing that we want to solve is the slowness of opening files. As you can imagine we use big assemblies. We created a workflow that is very modular just to prevent having massive ASM's but none the less sometimes we still have big ASM's that take a while to open/save.

Make sure server use SSD. Even split storage into multiple drives.
When ever CAD open a file, it doesn't just open 1 file.
For each file it open, a lock file is created which the server need todo can confirm with local machine.
When a file is save, it save a temp file first. Rename and move the old file. Rename the new file.
This create lots of network traffic hence we always suggest to not do it this way.
Unless you got a really good network admin.

I did some network optimize in XP days to get a ERP system usable. It just a database and only 4 users.

[Frederick_Law]

There for I kind of worry about the bother of signing things in and out of the vault. What use is it if the files open faster if the time gained is lost by the hassle of accessing the vault? Or is this just not an issue and am I just being paranoid because I have no experience with PDM?

Check in, out is not too bad.
Try to modify released assembly and parts is and have good reasons.
PDM helps to prevent mistakes.
User can (should) check "where used" before changing files.

Everyone will need to get some rules and process down to setup and work with PDM.

It is alot to do and it affect everyone. Everyone will have something against it because of how they do thing before.
Those need to get iron out.

[bnemec]

Check in, out is not too bad.
Try to modify released assembly and parts is and have good reasons.
PDM helps to prevent mistakes.
User can (should) check "where used" before changing files.

Everyone will need to get some rules and process down to setup and work with PDM.

It is alot to do and it affect everyone. Everyone will have something against it because of how they do thing before.
Those need to get iron out.

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.

[AlexB]

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.

[Frederick_Law]

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.

[bnemec]

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.

[jcapriotti]

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.

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.

[SPerman]

You guys are talking about Version history. Do you mean Revision history?

[bnemec]

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.

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.

[bnemec]

You guys are talking about Version history. Do you mean Revision history?

Revision is pretty much just a number applied to a version.

[SPerman]

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.

[JSculley]

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.

[CT-Simo]

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:
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?

[jcapriotti]

No one uses Branch and Merge? Not part of Standard though.

[AlexB]

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.

[bnemec]

No one uses Branch and Merge? Not part of Standard though.

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.

[AlexLachance]

The problem we're facing that we want to solve is the slowness of opening files. As you can imagine we use big assemblies. We created a workflow that is very modular just to prevent having massive ASM's but none the less sometimes we still have big ASM's that take a while to open/save.

We have a dedicated server on site that is solely for Solidworks files and that only us Solidworks users have access to. We got highspeed servers, highspeed connections, decent workstations with decent graphic cards and even our VAR can't find anything that we do wrong or could do better hardware wise. There for the only thing left, the only thing ouir VAR could recommend, is instead of working on files on the server is working on the files locally. Now storing files locally by manual means is complete rubbish and bound to lead to problems. This isn't 1974 but 2022 after all.

However using a PDM system combines the two. The files are stored on the server but when working on files they are stored locally. There is a distinct ,and supposedly safe, means to not run into problems with what is the latest (and correct) version and seeing that only at the moment of putting something in the vault or pulling it out the vault addresses the server, it should mean that the burden on the server is less + the access times would be better while working on the files because the files are stored locally once they have been pulled from the vault.

I can see that if everyone at the end of the day is uploading the latest version to the server that it would create a bottleneck but even so, it would mean only issues at the beginning of the day and end of the day.

HOWEVER, there is one thing that all this doesn't take into account. Namely, while some of us are working on big projects, projects that one or two designers are working on full time for several months and in some cases more than a year there are those of us that work on smaller projects. Projects that only take months, weeks or even days. On top of that is the fact that it isn't rare that we have to work on several projects, making small adjustments or big alterations, in a single day. And with several I mean up to 6 utterly different projects in a single day per person. Anything from altering material or diameters of piping to modifying general arrangement layouts. There for I kind of worry about the bother of signing things in and out of the vault. What use is it if the files open faster if the time gained is lost by the hassle of accessing the vault? Or is this just not an issue and am I just being paranoid because I have no experience with PDM?

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.

[Frederick_Law]

Some read on Windows SMB Client side tuning:
https://learn.microsoft.com/en-us/windo ... le-server/

Server side:
https://learn.microsoft.com/en-us/windo ... mendations

Make sure to log the changes and results.
Save current settings in a reg file. New settings in another.

[HDS]

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.

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.

[bnemec]

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.

[JSculley]

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.

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.

[bnemec]

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.

[jcapriotti]

We have the non-revision change workflow. It has a review state to insure that no design changes were made. It's only to be used for:

• Add Configurations, usually for assemblies
• Add display states
• Fix errors (Sketch, feature, mate)
• Add missing BOM and/or custom properties
• Add missing material / weight information
• Add reference geometry