PDM, Is anyone successfully using PDM but not always working with latest versions of all the files?

[bnemec]

The longer we use PDM the more it seems to be built on the premise that the version in local cache should always be latest and that every where used of a file will always be using latest version. Also learning in many ways that not doing that will cause PDM to fight you in many many ways.

Is anyone else successfully using PDM with ~30+ users and they don't always have latest and do not revise all of the where used to pull latest version when a part is revised? I'm wondering if this is possible.

Thank you.

[matt]

You have to be super careful when doing that and understand the file management rules completely. PDM is just a way to enforce existing rules. Using old revisions of a file is really just breaking the "thou shalt not have multiple files with the same name" commandment. Breaking rules can be done, but you have to be really careful.

[bnemec]

You have to be super careful when doing that and understand the file management rules completely. PDM is just a way to enforce existing rules. Using old revisions of a file is...

Not old revisions, old versions, big difference.

... is really just breaking the "thou shalt not have multiple files with the same name" commandment. Breaking rules can be done, but you have to be really careful.

Hi Matt, thank you for the reply. But the point you are trying to make is just confirming that Solidworks PDM is not the right tool for us.

This is simple revision in process stuff. It appears to me that software companies like to think that revising a part is an atomic process, like flipping a switch a part is either rev A or rev B there is no moment in time where the concept of the part exists as both. In addition the other parts and/or assemblies that use the part are either not yet in production or are at steady state and not also in change. That's just not possible in reality. It is not uncommon for a part to be under change for one ECR while the where used are being released for another non-related change or even a new part number release that cannot wait for the child part's changes to be implemented.

I used to wonder why some companies I've ran into didn't revise parts, they always made it a new part number. I'm beginning to think it is because their systems were not capable of handling the concept of a part being "under change"

In our example the revision is considred implemented when BOMs and Routings are updated in the "ERP"/MES. However, the concept of the new revision may exist days, weeks, or even months before that. Since the part is used in many places it's in the parts tree/contains tab for several users at a given time.

For a simplified example, part "bracket" is going to be changed by an ECR, the model is in WIP as potential changes are evaluated. The file was last released as revision 01 at version 4 lets say, but now the latest version is 9. At the same time a weldment (assembly file, not a part file) "frame" has been revised by someone else and is about to be released. Frame.sldasm uses bracket.sldprt. When Frame is released it MUST be using version 4 of bracket.sldprt because revision 02 has not been implemented.

It's safe to assume that these parts are being manufactured at any given day. So even though the model may be in flux between the released revision and what may become the next revision. The released pdf, tooling, routings, etc. are still being made according the the last released revision(and version).

That is normal, day to day process. No law breaking.

[matt]

Not old revisions, old versions, big difference.
...

Hi Matt, thank you for the reply. But the point you are trying to make is just confirming that Solidworks PDM is not the right tool for us.

You can do that kind of thing, but you have to have a process even beyond the process of the software and be aware of your surroundings. Version or revision doesn't matter if the file name is the same. If you want to work on different (whatever) of the part at the same time, you're going to have to solve the file name issue. Putting revision/version in the file name is ok, but I would only recommend it for obsolete data. If it's not obsolete, you might think of new part numbers for versions (assuming file names are actually part numbers).

I'm not trying to defend any particular software, but the generic PDM method is pretty much the same everywhere, and once you've got the files out of PDM, you've still got to deal with SW file management. The big rule there is that you can't have two different files with the same name open at the same time.

This is simple revision in process stuff. It appears to me that software companies like to think that revising a part is an atomic process, like flipping a switch a part is either rev A or rev B there is no moment in time where the concept of the part exists as both. In addition the other parts and/or assemblies that use the part are either not yet in production or are at steady state and not also in change. That's just not possible in reality.

If revA is released, then any edit that happens to it is automatically revB. As soon as you start editing a released document, it uprevs. There is no middle ground. There can't be a middle ground.

The rev levels need to happen in order even if the ECRs don't. If you have current rev of C when D is obsolete, that's chaos. There's no rule about ECRs needing to go through sequentially, but there is a rule about rev levels always ratchet up 1. So ECR 101 gets leap frogged by 100. 100 goes through first and gets the next rev level, say C. 101 eventually comes through and gets the next rev level, D not B. And you have to make sure C is built on B and D is built on C.

[bnemec]

You can do that kind of thing, but you have to have a process even beyond the process of the software and be aware of your surroundings. Version or revision doesn't matter if the file name is the same. If you want to work on different (whatever) of the part at the same time, you're going to have to solve the file name issue. Putting revision/version in the file name is ok, but I would only recommend it for obsolete data. If it's not obsolete, you might think of new part numbers for versions (assuming file names are actually part numbers).

I'm not trying to defend any particular software, but the generic PDM method is pretty much the same everywhere, and once you've got the files out of PDM, you've still got to deal with SW file management. The big rule there is that you can't have two different files with the same name open at the same time.

Before PDM, filenames were part numbers plus the revision suffix. There was no version control, no check in, no check out (designers/engineers had read write permissions for all the CAD files in file share). That was not ideal, obviously, but users knew which revision they were looking at because it was in the file name.

Now, with PDM, we went to serial numbers for new files. Part number and revision are variables on data card. Versions are a mystery to many. So any one user will only have one version of the file on the computer at a given time, this is desirable.

- User Joe may be working on the part and will have latest version in cache or the new version that is not yet checked in.
- User Sally may be working on releasing a revision to an assembly that uses that part, she needs to have the version that is last released (as that is what we are actually making) in local cache or the assembly print will show the not yet released version of the piece part Joe is working on.
- George is working on releasing a new assembly for prototype, he needs to talk to Joe to determine if he should use the latest version or the current released version.

This is our process, and has been the process for at least fifteen years. PDM has made that process very very difficult with how versions are cached. I've heard a hundred times how PDM is intended to be used, unfortunately we don't live in such a clean, ideal environment. We are to the point now where I need to find out >IF< the benefits of PDM will outweigh the overhead of using it. The irony is that file and rev control with version history are the main benefits of PDM to us; they are also the biggest problems.

We have been trying to come up with ways to make it so that the latest version is always the correct version. We have not yet come up with a valid solution. Someone else here mentioned they just always use latest and hope for the best. We have ran that scenario and can see that it will wreak havoc. We are trying to use branch and merge when we know the change will take a long time to implement or if it's a potential change that will need to be evaluated with samples/prototypes. To use the branch and merge process for every change would put us under water.

[bnemec]

If revA is released, then any edit that happens to it is automatically revB. As soon as you start editing a released document, it uprevs. There is no middle ground. There can't be a middle ground.

The rev levels need to happen in order even if the ECRs don't. If you have current rev of C when D is obsolete, that's chaos. There's no rule about ECRs needing to go through sequentially, but there is a rule about rev levels always ratchet up 1. So ECR 101 gets leap frogged by 100. 100 goes through first and gets the next rev level, say C. 101 eventually comes through and gets the next rev level, D not B. And you have to make sure C is built on B and D is built on C.

There must be middle ground, just because an engineer is editing a file does not mean the changes are implemented. I agree the >FILE< is no longer rev A, no question about that.

Rev C is still active production. Rev D is not obsolete, is it not yet implemented, it is pending. This is normal.

Yes revisions always increase, never go back, that's not what I'm talking about. I'm saying the part that is being manufactured as rev C and the latest version of the files will become rev D has where used. Some portion of the where used is also being revised and is about to be released. The print for that parent file being released today needs to show rev C of that component so it matches actual production, it cannot show rev D because rev D is pending. For that to happen the person releasing the parent assembly must have the rev C version in local cache.

Before PDM changing to the new revision of the component parts was manual with a replace file 123-A.prt with 123-B.prt. Now the model shows whatever version is in local cache. It is very complicated as you say. I'm trying to figure out if anyone has 20~30 users trained to the point where it's working.

[matt]

Before PDM, filenames were part numbers plus the revision suffix. There was no version

Your problems aren't that unique. Most companies find a way to work with the process.

Let me just say that revisions in the file name for released data is barbaric. If your choice is to go back to that, you're in for some serious eye opening. It CAN work, but each user has to robotically follow the rules for uprevs. And you will lose history with that.

You're missing something key. It seems like you don't have a way to deal with stuff that in process but not released yet. Even PDMW could deal with that. I still can't get a copy of the SW PDM(Conisio), so I can't get at those details, but there has to be some mechanism for making in-process stuff invisible. That's a basic PDM function.

WE used to have released rev levels and then intermediate revisions like A.1, A.2, A.3. So as soon as you release A, any edit to it becomes A.1. But A is the latest release. A.1 is the WIP.

People should always use the latest released version unless they have a specific reason for doing something else, and non-CAD people should have no access to unreleased data, unless they are in the approval loop.

Have you asked for professional help? I mean really, you need to take a SW PDM consultant to lunch and solve your problem. What I read it isn't that hard. Some people may have to learn something new, which I know is traumatic, but you can't seriously be thinking of throwing out PDM just because there's a switch somewhere or a technique you're missing. I used to do this kind of troubleshooting/education for companies, but I haven't played with Conisio in years. Hire somebody for a day. You're not saving any money by avoiding it.

[bnemec]

Your problems aren't that unique. Most companies find a way to work with the process.

Let me just say that revisions in the file name for released data is barbaric. If your choice is to go back to that, you're in for some serious eye opening. It CAN work, but each user has to robotically follow the rules for uprevs. And you will lose history with that.

I won't argue that point. It is what we had before PDM. Frankly it was working better than what we have now, but it was certainly not ideal. The part about robotically follow the rules for uprevs is accurate. But now the users MUST robotically get the correct versions for the file and all of it's components and subcomponents every time the open the file, this is proving more difficult than upreving when the revision was in file names. I'm not saying we want to go back to revs in file names.

You're missing something key. It seems like you don't have a way to deal with stuff that in process but not released yet. Even PDMW could deal with that. I still can't get a copy of the SW PDM(Conisio), so I can't get at those details, but there has to be some mechanism for making in-process stuff invisible. That's a basic PDM function.

I hope I am missing something because when we had that set up those users that couldn't see in process stuff couldn't access any file in WIP at all. They need to access the released version. For the most part we don't have any non engineering users accessing PDM. PDFs are published out as a release task.

People should always use the latest released version unless they have a specific reason for doing something else,

This is exactly what we're talking about, PDM defaults to the latest version in the server, not the latest released version. In effect, that behavior implements, in part, changes before they are released because the changes can be seen in the parent parts that are released while child parts are in WIP. I've been begging for the default to be get latest released version but it's not possible without bad work arounds. The closest we have is to get files by referenced version which the users must remember to do manually.

Have you asked for professional help? I mean really, you need to take a SW PDM consultant to lunch and solve your problem. What I read it isn't that hard. Some people may have to learn something new, which I know is traumatic, but you can't seriously be thinking of throwing out PDM just because there's a switch somewhere or a technique you're missing. I used to do this kind of troubleshooting/education for companies, but I haven't played with Conisio in years. Hire somebody for a day. You're not saving any money by avoiding it.

I probably do need professional help, but not from a CPAP but a Psy.D

The professional help says always use latest version and every revision requires the entire where used tree to be revised. I truly hope there's a switch I'm missing.

you can't seriously be thinking of throwing out PDM just because there's a switch somewhere or a technique you're missing.

There are questions being asked along the lines of, "Is the tool doing more good than harm?" The answer is not crystal clear, I should be able to point to a definitive "Yes". If we can get over the hump of dealing with which version CAD users have in local cache I think we'll have it made.

[matt]

This is exactly what we're talking about, PDM defaults to the latest version in the server, not the latest released version. In effect, that behavior implements, in part, changes before they are released because the changes can be seen in the parent parts that are released while child parts are in WIP. I've been begging for the default to be get latest released version but it's not possible without bad work arounds. The closest we have is to get files by referenced version which the users must remember to do manually.
....
I truly hope there's a switch I'm missing.

Ok, I feel better about this now. It's almost certainly something simple. I'm pretty sure we could do this with ProductCenter 20 years ago and PDMWorks 10 years ago, and it's just a switch when you are opening the file, or pulling it from the vault into cache that will allow you to get an incremental version other than the latest release.

I would do this frequently. Pull out the latest release, then make changes toward the next rev, and at the end of the day check it in as a A.1. Then at the end of the next day check it in as A.2. Until it is finally released at B. Do you have the incremental revision scheme set up?

I just went back and found this. This is the setup page we had in PDMWorks which showed the Primary and Secondary revision schemes along with a Working Copy designator. This is maybe the piece you're missing. The Working Copy designator allowed a rev to be overwritten every check in with a new working rev until you're ready for release. PDMW was the kind of stuff you got for free with the Pro version of SW. So something you had to pay for has got to have this kind of functionality.

[bnemec]

Ok, I feel better about this now. It's almost certainly something simple. I'm pretty sure we could do this with ProductCenter 20 years ago and PDMWorks 10 years ago, and it's just a switch when you are opening the file, or pulling it from the vault into cache that will allow you to get an incremental version other than the latest release.

I would do this frequently. Pull out the latest release, then make changes toward the next rev, and at the end of the day check it in as a A.1. Then at the end of the next day check it in as A.2. Until it is finally released at B. Do you have the incremental revision scheme set up?

I just went back and found this. This is the setup page we had in PDMWorks which showed the Primary and Secondary revision schemes along with a Working Copy designator. This is maybe the piece you're missing. The Working Copy designator allowed a rev to be overwritten every check in with a new working rev until you're ready for release. PDMW was the kind of stuff you got for free with the Pro version of SW. So something you had to pay for has got to have this kind of functionality.

537268 fg2219.jpg

We are using a simple, single variable, revision scheme that is controlled by the PDM Workflow. The file starts life at rev 00 and the first time it is released it is 00. When it goes to WIP the revision on data card shows 01. Checking file in does nothing to the "revision" only the workflow states and transitions have an affect on the reivision.

I could be confused, but it sounds like you're incremental revisions .1, .2 etc were for each check in? We don't have that as part of our "revision" Solidworks PDM keeps a list of "versions" for each file. Every time the file is checked in with changes the version in incremented. So that sounds a little bit like what called incremental .1, .2, .3 etc. component of the revision

Our trouble is that PDM automatically gets what you would call the latest incremental for the CAD users. We want it to get the latest release (you would call it 'A' I think)

[matt]

Our trouble is that PDM automatically gets what you would call the latest incremental for the CAD users. We want it to get the latest release (you would call it 'A' I think)

Ok, well, you know what you need, I think. That setting has to be there somewhere. If I had the software here I'd find it for you, but ...

[VicFrauenfeld]

@bnemec, what does your VAR say about these questions? Are you talking to them about your questions?

[bnemec]

@bnemec, what does your VAR say about these questions? Are you talking to them about your questions?

oh yeah. After we get through boiler plate responses of "always use latest version" and "revise all the where used along with any part change" it turns to tech support finding SPR numbers. We're added to a few.

The fallout of having files not using latest version of every component down the tree is far reaching and we keep finding more places. The where used tab is especially problematic as what it shows in only a partial where used. Even when "Show all versions" is selected, that is just for the root child file. The first layer of parents are a specific version and from there on the where used results are specific to that version of the first layer of parents. The result is 1)Users don't realize they are not looking at the full set of where used. 2)Users don't trust the where used in PDM. 3)Users "Browse to" every first layer parent to be able to see where used result set for "all versions" which is a lot of work.

[Austin Schukar]

Have you read through this blog? Seems to be of some use in your situation.

https://www.goengineer.com/blog/control ... dworks-pdm

[bnemec]

Have you read through this blog? Seems to be of some use in your situation.

https://www.goengineer.com/blog/control ... dworks-pdm

If not that one specifically then others much like it. I just studied again and nothing new to me in there.

The settings are either force latest or use whatever. The only way to default to use latest released version is to hide "working versions" and check the always get latest box. The latest available to the user is the latest released version. That won't work for CAD users as they need to see all versions. Once they can see working versions the default on get is to get latest. There is manual option to get by referenced, which is what I'm harping on the users to do all the time. Even that is not ideal as any components that are released and referencing an older version need to be updated. That process is rather tough training for many and the monitors aren't big enough to get enough information in the Solidworks PDM Add-in. I keep reminding them that they need to show columns of PartNumber, State, checked out by, referenced version, local version. And they need to understand what all of that means. What we really need is the option to get latest released version by default.

I mention the Solidworks PDM Add-in because that's the only place to get a good view of what's referenced and what's local. The contains tab in vault view will show the referenced version but it will not show the local version of the files.

[Austin Schukar]

I gotcha. Thanks for the context.

.......

We are to the point now where I need to find out >IF< the benefits of PDM will outweigh the overhead of using it. The irony is that file and rev control with version history are the main benefits of PDM to us; they are also the biggest problems.

We have been trying to come up with ways to make it so that the latest version is always the correct version. We have not yet come up with a valid solution. Someone else here mentioned they just always use latest and hope for the best. We have ran that scenario and can see that it will wreak havoc. We are trying to use branch and merge when we know the change will take a long time to implement or if it's a potential change that will need to be evaluated with samples/prototypes. To use the branch and merge process for every change would put us under water.

Couldn't (shouldn't) Branch/Merge solve all of your issues? Or is this related to enforcement? Branch/Merge would keep the original referenced file at its latest released version, while you're able to make edits to the new one without worries that those new branched versions are being erroniously referenced. Do the extra steps for Branch/Merge really add that much overhead? When compared to the amount of issues that your team is having with referencing working files, I'd think that Branch/Merge would be well worth its weight in gold.

[bnemec]

I gotcha. Thanks for the context.



Couldn't (shouldn't) Branch/Merge solve all of your issues? Or is this related to enforcement? Branch/Merge would keep the original referenced file at its latest released version, while you're able to make edits to the new one without worries that those new branched versions are being erroniously referenced. Do the extra steps for Branch/Merge really add that much overhead? When compared to the amount of issues that your team is having with referencing working files, I'd think that Branch/Merge would be well worth its weight in gold.

I don't know. There are always so many unexpected things, every leap of faith I've made with this software (and steps I thought were secure too I suppose) have left me with bumps and bruises. I'm not sure how many more, "Well try this" we can handle here; I won't go into examples now.

Maybe branch and merge for every change could work, but there's so many unknowns. Half the users are so confused with versions they've forgotten what they had known. Trying to push branch and merge on them might make things worse, it's not a straight forward process. There are a bunch of details and scenarios we would need to work through.
- Part number, for example. For inhouse stuff I don't want the print of the next potential revision to have the production part number on it, they'll get confused and run the wrong one.
- Rev table on branched print? is the branched model and drawing going to show the next potential rev or is it a new part starting at rev 00. Remember, that for everyone outside engineering the data is about a physical object, not about the file. So in PDM I get that the branched file is a new file, new ID, fresh rev counter, etc. To the rest of the world a branched file for potential revision is the same part just a pending revision. Yes, we can put "FOR PROTOTYPE ONLY, POTENTIAL CHANGE" watermark in the print to help with this. If we do decide we need the branched files (model and drawing) to be the next revision then how do we set the system rev counter? Only way I know to do that is API. Sure I can put whatever on the data card, but the system rev counter for that file is what I need to set.
- automated rev table, we have PDM set to do the revision table (one of those steps I though was secure turned out to be a mistake, should have have left it manual...) anyway if the drawing is branched the drawing may have rows for several revisions on it, but unless we figure out how to set the system rev counter for the branched file the next row added will be for rev 00, which is incongruous above 04.
- merging, if the branched files are not ramped up to the next rev with revision table on print showing the next change then we'll have some fenagling to do before merging the drawing or don't merge the drawing and redo the changes on the original after it updates based on the merged model.
- on average day we release just under 100 files, roughly 3/4 of those are files that have gone from Released to WIP to Review to Released. So it's not something users do couple times a week, it's several times a day, adding a few minutes to that process for each file would figure out to an annual cost that's not much fun to report to the director.
- how will users know that the part has pending changes? the original file will still be in Released state, the only way to know is to right click and check for associated branches. If that could be put in a column in vault view/search tool and made obvious in the Solidworks PDM Add-in I would be less worried. Based on things I see users doing know I'm fairly certain we would have lots of redundant branching going on and concurrency races. As it is now it's obvious when one change leapfrogs another. If there are two branches by separate people on one file whoever merges last wins and just a hunch, but half the time they will not realize what they've done. ... unless we don't merge drawing, then it might be a bit more obvious, sometimes.

So I really do not know. I don't know If branch and merge would solve all the problems by allowing everyone to blindly just use latest version. I don't know if the added cost of the steps required to make the tool work will be offset by the gains provided by the tool. I don't know if there are still issues that this doesn't fix. I don't know if our users can all understand how to use the process and watch for it.

Based on what I'm hearing in the thread so far all successful PDM use cases always use latest version of files. Not having latest version in local cache is a rare situation and not part of the normal day to day. Anything attempt at not always using latest version of files will end in failure. Is that accurate?

[jcapriotti]

@bnemec We elected to "Always use latest" because it was too easy to not see that you had the latest in cache. Ideally PDM should prompt when opening files that you don't have the latest in the cache and ask, but doesn't. So we took that decision away from the users. Engineering sees latest version in all states, Downstream users and Mfg only sees latest "Release" state versions.

We have the same situation for engineering, we have a large assembly with many sub components in which various sub-components can be on several different and unrelated ECOs. These ECOs can be released in any order, not in which they were created.

Example
Say we have a released assembly:
CAD0001.sldasm Rev A "Bracket Sensor Assembly"
CAD0002.sldprt Rev B "Bracket"
CAD0003.sldprt Rev G "Plate"
CAD0004.sldprt Rev D "Sensor"

We have two ECOs at the same time:
ECO1: Changes "CAD0002 Bracket", no assembly change.
ECO2: Changes "CAD0001.sldasm" and "CAD0003.sldprt "Plate"

ECO2 releases first (Assembly and plate bump revision):
CAD0001.sldasm Rev B "Bracket Sensor Assembly"
CAD0002.sldprt Rev B "Bracket"
CAD0003.sldprt Rev H "Plate"
CAD0004.sldprt Rev D "Sensor"

So the problem is, since we "Always work with latest version", the new revision B assembly 'shows' the in process version of the bracket (CAD0002) even though this part isn't released yet. Depending on where ECO 1 is at the time ECO2 released, it may or may not show the change occurring on ECO1.

It's a risk we live with. Since all revisions must be backwards and forwards compatible, the risk is minimal as the changes to the bracket are usually minimal (form, fit, function), otherwise it would get a new part number, which would require the assembly be added to ECO1.

[bnemec]

@bnemec We elected to "Always use latest" because it was too easy to not see that you had the latest in cache. Ideally PDM should prompt when opening files that you don't have the latest in the cache and ask, but doesn't. So we took that decision away from the users. Engineering sees latest version in all states, Downstream users and Mfg only sees latest "Release" state versions.

We have the same situation for engineering, we have a large assembly with many sub components in which various sub-components can be on several different and unrelated ECOs. These ECOs can be released in any order, not in which they were created.

.......

It's a risk we live with. Since all revisions must be backwards and forwards compatible, the risk is minimal as the changes to the bracket are usually minimal (form, fit, function), otherwise it would get a new part number, which would require the assembly be added to ECO1.

That is a good point that we (me and colleagues) aren't giving enough attention to, that the revisions are forwards and backwards compatible.

[AlexB]

I wish I'd seen this discussion sooner. I am in the same boat as @bnemec in that we must use the latest released version of a component. Our process dictates that until a part is released, then any assemblies that use it, even in parallel unrelated development of other assemblies, must not refer to an unreleased revision. There is some grey area here with certain parallel projects that feed into one another.

Now, I understand that backwards/forward compatibility must be taken into account and that is done here. However, our document control personnel will not allow an assembly to be issued where there is an unreleased component used in the assembly.

In order to combat this, I looked into PDM Professional settings and cannot find anything like what is needed to solve this. So... I turned to the API. I've got something functioning that looks into the file history of all the components/assemblies used in the selected assembly and allows you to get the version that refers to the latest "Issued" version. It requires more testing to ensure that it actually gets the necessary files at the necessary versions but it's something. I do wish that it was included as a function of PDM and I didn't have to implement it myself but that's what you get sometimes.

[bnemec]

I wish I'd seen this discussion sooner.

I wish I had seen it before we bought PDM.

Your post is why I started the thread. I cannot believe that we are the only company that has indefinite product lifecycles, with all the parts able to be used where ever and anything can be revised while there are active orders and inventory.

I think that if I'm ever forced to go job hunting for another design engineering role I'll look for someplace that makes one off machines and every part is only made once and the CAD files never reused or maintained. Better yet, if I'm forced to go job hunting I think I'll just go back to welding in a fab shop.

I am in the same boat as @bnemec in that we must use the latest released version of a component. Our process dictates that until a part is released, then any assemblies that use it, even in parallel unrelated development of other assemblies, must not refer to an unreleased revision. There is some grey area here with certain parallel projects that feed into one another.

So I'm not the only customer who's "doing it wrong". Suppose there are others? Maybe a support group?

Now, I understand that backwards/forward compatibility must be taken into account and that is done here. However, our document control personnel will not allow an assembly to be issued where there is an unreleased component used in the assembly.

Unless I misunderstand here, we are a bit different in this. We frequently must release assemblies that have components that are in WIP, but they should be using the last released version, not the new version. To do this the user who checks the assembly in before sending to review state must have the latest released version. That option is not available and they must do it manually. But really only makes sense to do it for files that are in WIP so they can be checked out by the user, otherwise the changes aren't pushed to the server anyway (half my users still don't get this). So if the parent file is not in WIP the children should be cached by referenced version, not latest, not latest released.

In order to combat this, I looked into PDM Professional settings and cannot find anything like what is needed to solve this.

Preach!

So... I turned to the API. I've got something functioning that looks into the file history of all the components/assemblies used in the selected assembly and allows you to get the version that refers to the latest "Issued" version. It requires more testing to ensure that it actually gets the necessary files at the necessary versions but it's something. I do wish that it was included as a function of PDM and I didn't have to implement it myself but that's what you get sometimes.

I'm curious about what your UI looks like. Did you make your own Get Reference File Dialog, a tree view with columns? There's so much already done in the existing ref file dialog (columns and what not) but no option to get latest version in a special state but I'm not smart enough to add functionality to or change behavior of the existing dialog.

Are you covering the case where the user just double clicks an upper level assembly or drawing from the vault view or search tool? Also don't forget the PDM File Viewer that comes up with the Where Used command from the Solidworks PDM Add-in. There's so many ways that users can open a file; trying to cover all those cases is a big challenge, trying to force all of the users into just one or two of those methods is like herding cats.

We have a couple users that I secretly use to help me come up with test cases just by watching the many ways they can drive a train right up off the rails. If something can be broken they will, and silently so you don't see it until months later.

[AlexB]

Unless I misunderstand here, we are a bit different in this. We frequently must release assemblies that have components that are in WIP, but they should be using the last released version, not the new version. To do this the user who checks the assembly in before sending to review state must have the latest released version. That option is not available and they must do it manually. But really only makes sense to do it for files that are in WIP so they can be checked out by the user, otherwise the changes aren't pushed to the server anyway (half my users still don't get this). So if the parent file is not in WIP the children should be cached by referenced version, not latest, not latest released.

I should clarify that this means we cannot use a Version of a file that has not been released. We are still able to modify it while other groups are still using the last released version.

I am using the built in UI for the BatchGet functionality. This is the same window that pops up when you select Get on any assembly with the tree, reference version, local version, etc. The only difference is that I specify which version of each component in the tree to get based on the History of state changes.

[jcapriotti]

Out of the box, the only options I see is:

1. Use the Branch/Merge function. Maybe some usability issues to deal with as its newer functionality. Also the UI is a bit involved,
2. Create copies then have a coordinator/power user replace the released versions and re-release a new revision. We don't do this on ECOs but longer projects we often copy and prefix files with a project number. Then we checkout and replace the released version when it does get an ECO to release. This kind of what branch and merge does.

[JSculley]

The longer we use PDM the more it seems to be built on the premise that the version in local cache should always be latest and that every where used of a file will always be using latest version. Also learning in many ways that not doing that will cause PDM to fight you in many many ways.

Is anyone else successfully using PDM with ~30+ users and they don't always have latest and do not revise all of the where used to pull latest version when a part is revised? I'm wondering if this is possible.

Thank you.

If I understand correctly, what you are after is listed in SPR 718692 -- Add option for Check out and Get of assembly to default to as built for references versions

[bnemec]

I should clarify that this means we cannot use a Version of a file that has not been released. We are still able to modify it while other groups are still using the last released version.

Thank you for clarification, I was misinterpreting. What you say is identical to what we do.

I am using the built in UI for the BatchGet functionality. This is the same window that pops up when you select Get on any assembly with the tree, reference version, local version, etc. The only difference is that I specify which version of each component in the tree to get based on the History of state changes.

That sounds very nice. I used the BatchGet in my pdf/dxf add-in to make sure it uses the referenced versions of all the files, so in hopes the output would match what was last checked in. I did not explore recursing though and setting the version on each file based on states of the parent and child refs.

Where do the users launch this get functionality from? Are you adding it to file menu? Any chance of being able to do this from Solidworks while the file is open or are you handling if a file that needs a different version is "Open in another process", usually Solidworks.

When getting the data to determine which version of each file to use, are you using PDM APIs or querying SQL directly? I've found that going straight to the DB is much faster. Although that opens it's own can of worms when updating to new version of PDM, just more testing I guess.

[bnemec]

If I understand correctly, what you are after is listed in SPR 718692 -- Add option for Check out and Get of assembly to default to as built for references versions

That would be a step in the right direction, yes. We are on that SPR and a couple similar ones as well.

The ideal would be:
1) get root parent file by selected version (usually this would be latest version)
2) get children
----a. if parent is in a state flagged as editable (WIP state would have this flag set in the Workflow Editor of PDM Admin Tool)
--------i. if child file in state flagged as released ("Released" state would have this flag set in the Workflow Editor of PDM Admin Tool) Then get latest version
--------ii. else get child file by referenced version
----b. else (parent file not editable) get child file by referenced version
----c. recurse on the child file back to step 2 as a parent *!This must be done AFTER the correct version of the child selected so that we get the correct versions of it’s children.

*Don’t get latest version by default*

Does that look about right @AlexB ?

[AlexB]

Where do the users launch this get functionality from? Are you adding it to file menu? Any chance of being able to do this from Solidworks while the file is open or are you handling if a file that needs a different version is "Open in another process", usually Solidworks.

The open-in-another-application error is checked for by the built in PDM dialog. It follows your PDM Admin settings for what errors/warnings to check for and potentially block behavior until the file is closed.
I've added the function to the right-click menu and the Actions menu in the tool bar when a file(s) is(are) selected.

image.png (25.15 KiB) Viewed 10017 times

When getting the data to determine which version of each file to use, are you using PDM APIs or querying SQL directly? I've found that going straight to the DB is much faster. Although that opens it's own can of worms when updating to new version of PDM, just more testing I guess.

This is with PDM APIs only. No queries directly to the database.
Custom Progress Window

PDM Built-in Dialog

The ideal would be:
1) get root parent file by selected version (usually this would be latest version)
2) get children
----a. if parent is in a state flagged as editable (WIP state would have this flag set in the Workflow Editor of PDM Admin Tool)
--------i. if child file in state flagged as released ("Released" state would have this flag set in the Workflow Editor of PDM Admin Tool) Then get latest version
--------ii. else get child file by referenced version
----b. else (parent file not editable) get child file by referenced version
----c. recurse on the child file back to step 2 as a parent *!This must be done AFTER the correct version of the child selected so that we get the correct versions of it’s children.

*Don’t get latest version by default*

Does that look about right @AlexB ?

This is essentially how it is being done.
It checks the file's history for changes in state to determine when the last released state change was made. This logic needs a bit of work to account for admins going in and updating already released items, but the framework is there. Lots of testing will be needed to ensure things work before potentially deploying this.

You bring up a good point with ii.c. where a sub-assembly's contents may enough between versions to where it may be necessary to check into things further. I can't say whether the out of box behavior will work or not for this... we shall see!