PDM, get file - references by referenced version as default

[bnemec]

I've asked this to our VAR a couple times, there's an SPR (in which I have little faith), and I asked it in old forum, but would like to ask here too. How can we make default behavior to get files by referenced version, not latest?

I know it can be done, but it needs to be selected every time. Unless the user is getting a specific version of the top level file, then get by referenced version is selected; we need that every time.

Also, there are times when latest version is cached, but no reference file dialog, such as opening a file from open file dialog so I don't think there is an option in that case. But I've been wrong a lot.

image.png

[Merovingien]

this is not correct,

PDM has a lot "unsolidworks behaviors" (bom, exclude part, etc...)

but with the rule of "a build part" is one part-number,
when the part evolve, all the evolutions must be backwward-compatible.
if not, this has to become a new part, to keep previous (old) assembly using that part alife (with no problem).

example of a plate with 2 holes at each side,
if you add one hole in the center, the part is backward-compatible.

if you remove one of the two holes, the part become a different part.

also, if you considere the approch of "Library file".
have the lastest reference is always in majority of case the best behavior.
because, if in one library-part you had corrected a false description, or added a "new mounting configuration".

if you don't get lastest file, you will not see the good evolution.


and if you work on a machine that has already been build, you have to choose "referenced version".

[bnemec]

this is not correct,

PDM has a lot "unsolidworks behaviors" (bom, exclude part, etc...)

but with the rule of "a build part" is one part-number,
when the part evolve, all the evolutions must be backwward-compatible.
if not, this has to become a new part, to keep previous (old) assembly using that part alife (with no problem).

example of a plate with 2 holes at each side,
if you add one hole in the center, the part is backward-compatible.

if you remove one of the two holes, the part become a different part.

also, if you considere the approch of "Library file".
have the lastest reference is always in majority of case the best behavior.
because, if in one library-part you had corrected a false description, or added a "new mounting configuration".

if you don't get lastest file, you will not see the good evolution.


and if you work on a machine that has already been build, you have to choose "referenced version".

I think I follow what you say and I've heard that over and over, mostly from VARs. Here's the kicker that has never been answered for us (which should have have been a warning sign to us), latest versions aren't always the "Good evolution" they could be pending changes that have not yet been implemented or even approved. Usually the VAR jumps right over to well don't show working versions to all the users. It's the design engineers that are needing to decide if they use new or as referenced, they need to see all versions.

I'll try to be clear and concise, it's hard for me to explain so that others understand, but I'll try. One user is working on a new product that has a lot of common parts in it and they are about to release their top level assembly and drawing for review. At the same time some of those common parts are somewhere along the revision process for an entirely separate ECR, clearly we don't want to use the latest versions of those files as those changes are not implemented. As referenced is the safer option as it won't be automatically trying to implement unreleased versions.

Maybe better if I say, this isn't a case of I want to use and old version of x on assembly A for ever while assembly B uses latest. Rather this is more, we shouldn't be releasing stuff that shows sub components at newer versions that shouldn't be used yet.

Does that make any sense or am I speaking gibberish?

[jcapriotti]

Perfect sense and one of the weak areas of PDM. There isn't an easy way to do this and we just end up living with the risk as we have the setting "Always works with latest" set. Ideally we need a "As Released" button option. Then pick which parts we want to set to Inwork and revise. Maybe an option to load latest release:

As Built
As Built Release
As Latest
As Latest Release

I've put in an enhancement request many moons ago.

[bnemec]

Since Reference Dialog settings was mentioned by @jcapriotti I'll just paste what ours has been for the Design group. This has been working ok I think. The high lighted setting was the last one I cleared out a couple months ago, I was severely warned about having that not checked by our VAR but it seems to be helping, at least not hindering.

image.png

I should mention the Solidworks PDM Add-in is a big help here as it adds clarity of local version and referenced version. Getting everyone to actually use it and set up those columns is another obstacle. I found the reg key for those settings and I've tested on my own machines exporting and importing it but I haven't worked up the nerve to push it out yet.

[jcapriotti]

@bnemec

I want to use that setting but there was too much risk with hundreds of users opening files and not getting the latest and instead opening the last cached version. In that mode I really wish it would prompt the user for which version instead of relying on the user to right click and pick.....most user double click.

[bnemec]

@bnemec

I want to use that setting but there was too much risk with hundreds of users opening files and not getting the latest and instead opening the last cached version. In that mode I really wish it would prompt the user for which version instead of relying on the user to right click and pick.....most user double click.

Yes, understand that. For now we've pared back to just CAD users in PDM for the most part.

[jcapriotti]

Might take a custom add-in at this point to get the needed functionality......however we are moving to Windchill so I've already got my .net tied up in that migration.

[Diaval]

... I found the reg key for those settings and I've tested on my own machines exporting and importing it but I haven't worked up the nerve to push it out yet.

Be careful about pushing out column settings in a registry file. PDM keeps some user column set customization details in the database and applies it to a client at login which would update the client registry settings and overwrite settings you may have tried to set.

[bnemec]

... I found the reg key for those settings and I've tested on my own machines exporting and importing it but I haven't worked up the nerve to push it out yet.

Be careful about pushing out column settings in a registry file. PDM keeps some user column set customization details in the database and applies it to a client at login which would update the client registry settings and overwrite settings you may have tried to set.

Yes.
Those kinds of unknowns are exactly why I don't like fidgeting around in the registry.

[Diaval]

You should ask your VAR to get added to SPRs 471886, 465803, and 901888.

[jcapriotti]

Those kinds of unknowns are exactly why I don't like fidgeting around in the registry.

I live in the registry trying to figure this stuff, it's practically a hobby.........I break the registry so you don't have to.

[bnemec]

You should ask your VAR to get added to SPRs 471886, 465803, and 901888.

@Diaval , How in the wide world did you find those SPR numbers?!
I "Voted" for a couple of them in my ERs in customer portal, the first number I could not find. Submitted support case to VAR asking to be added to the last two and a description of the 471886.

Do you know the difference between a customer using the "Vote For" an SPR from EH system in the customer portal and when the VAR adds a customer to an SPR?

I have had several questions/issues this week concerning versions. A couple were because the reviewer failed to do a "Get Referenced" so they had a mix of old versions and latest that were newer than what should be used in the drawing and model being approved. It's nice to be able to have all the version history at our fingertips, but it's a tough concept to fully understand how it impacts daily tasks.

Thanks for those numbers, however you found them.

[Diaval]

You should ask your VAR to get added to SPRs 471886, 465803, and 901888.

@Diaval , How in the wide world did you find those SPR numbers?!
I "Voted" for a couple of them in my ERs in customer portal, the first number I could not find. Submitted support case to VAR asking to be added to the last two and a description of the 471886.

Hey so sorry but I had a typo in that first number. It should be 417886. I have a bit of mild dyslexia with longer number strings and sometimes transpose the numbers without realizing it.

I am familiar with this issue in PDM so knew that there were a few enhancement requests related to allowing Get to use reference versions as default.

Do you know the difference between a customer using the "Vote For" an SPR from EH system in the customer portal and when the VAR adds a customer to an SPR?

If I understand this correctly, enhancement requests are handled a bit differently than bugs by SolidWorks. Customers can directly add themselves to enhancement requests to ask for new features. But when an issue is considered a bug, the customer has to go through their VAR as the first point of service to be added to a bug SPR. I wasn't sure if your VAR could push a bit harder on any of the enhancements though. Might not hurt to ask.

I have had several questions/issues this week concerning versions. A couple were because the reviewer failed to do a "Get Referenced" so they had a mix of old versions and latest that were newer than what should be used in the drawing and model being approved. It's nice to be able to have all the version history at our fingertips, but it's a tough concept to fully understand how it impacts daily tasks.

This is always a bit of a tricky issue. Because PDM is designed to use a workflow of continuous development, it can be a bit difficult implementing processes that will ensure that newer, unreleased versions of parts don't get added to assemblies and drawings, while still allowing the same developers read/write access to work on development of newer versions/revisions of parts and subassemblies.

Some user training will always be needed around ensuring to get Referenced versions of any references when starting work on a change. It's also good to ensure the State column is visible on the check in dialog so that the user can evaluate any reference that is not in an approved state to ensure they are using the correct version of that file instead of a newer, unreleased version.

With Branching and Merging in PDM Pro, it is also possible to do development on a separate copy of the files to prevent references from using the wrong versions of the approved files. Then when the development work is completed, the source file can be moved to a workflow state for merging and re-released as the new approved version/revision.

I am really interested in hearing how others manage this issue of ensuring references to approved versions don't accidently get updated to use a version currently under development.

Thanks for those numbers, however you found them.

Glad I could help. The more customers who complain about this issue, the better chance we have at pushing SolidWorks to implement the enhancement.

[jcapriotti]

I am really interested in hearing how others manage this issue of ensuring references to approved versions don't accidently get updated to use a version currently under development.

We always work with "Latest". We have just been risking it for years. Normally it's not an issue as a new design would get new part/assy numbers. Every once in a while it comes up and we just have to work around it.

I've been on SolidWorks for years about needing a way to get "Latest Release". Of course, you still need a way get latest Release on most files but not on some others you're revising. Branching looks like it could be a solution however we are moving to Windchill so little dev work is being done on PDM except to make small changes. Windchill does have some functionality around getting latest versions in a certain states but it's UI is like deciphering hieroglyphs without a Rosetta stone.

[bnemec]

I might have found how to turn off automatically get latest while I was working on another task. Not saying I’m ready to check this box just yet, but it is in my mind to test behavior. If this were checked for the Solidworks file types then a PDM addin hook to the EdmCmd_PreGet command (I’m not seeing a PreOpen command) that would get referenced files by version.

This could also be a big help to us in the cases where there are dozens of drawings using some “optional” part. In that case it takes several minutes for PDM to get all the refs because it gets all the drawing nodes, then gets every part in all those drawings as well.

[jcapriotti]

I might have found how to turn off automatically get latest while I was working on another task. Not saying I’m ready to check this box just yet, but it is in my mind to test behavior. If this were checked for the Solidworks file types then a PDM addin hook to the EdmCmd_PreGet command (I’m not seeing a PreOpen command) that would get referenced files by version.

This could also be a big help to us in the cases where there are dozens of drawings using some “optional” part. In that case it takes several minutes for PDM to get all the refs because it gets all the drawing nodes, then gets every part in all those drawings as well.

image.png

Interesting way to address it. I would've hoped that the API would let you do this without going to that setting.

Does the Get call not let you exclude getting the references? In the UI you can manually unselect the references. Then before/after in the API, get the reference list and get the "Released" version of each.

[bnemec]

Interesting way to address it. I would've hoped that the API would let you do this without going to that setting.

Does the Get call not let you exclude getting the references? In the UI you can manually unselect the references. Then before/after in the API, get the reference list and get the "Released" version of each.

I have not been able to find any way to prevent the getting of latest when there is no copy of the needed file in local cache. The thing with this setting is it probably only has effect on right click Open specifically, it still does not cover all the other ways a file will be opened by SW, especially when SW is the default program. Double click, click a link in an email notification, etc.

Or you're saying forget that setting because the PreGet hook will be called EVERY TIME the get command is ran. I wasn't thinking of that. Which could cause the need for some logic to make sure its less hindrance then help. I really only want to have an affect when the files are gotten "silently" as in open an assembly and you don't have local cache. In that case there's no ref file dialog, it just does it. In the case where the ref file dialog does show up I want it to default to get by referenced. Oh I see, you're saying before any get, even if the user double clicks an assembly file in vault view, then the get command is fired, my add-in would display the RFD and since I displayed it I could set default behavior of get by referenced, Then, once all the files are cached the get command that fired PreGet would continue but there would already be local copies of everything so it would take no action. I wonder if that would work. Thanks rubber duck!

[bnemec]

I'm really getting tired of this:

[berg_lauritz]

With Branching and Merging in PDM Pro, it is also possible to do development on a separate copy of the files to prevent references from using the wrong versions of the approved files. Then when the development work is completed, the source file can be moved to a workflow state for merging and re-released as the new approved version/revision.

So branching automagically only takes the latest released version?
How does it behave, when two or more individual changes are made to the same assembly? Does the merge work fine in this case? @Diaval

Edit: Is this SPR also connected: 532438 ?

[jcapriotti]

So branching automagically only takes the latest released version?
How does it behave, when two or more individual changes are made to the same assembly? Does the merge work fine in this case? @Diaval

Edit: Is this SPR also connected: 532438 ?

For any individual file, last merge wins. Until SolidWorks develops a way to merge the contents of two files, merge in PDM is just creating copies of the master file and then replacing it with the copy later. You can do the same manually.

[bnemec]

So branching automagically only takes the latest released version?
How does it behave, when two or more individual changes are made to the same assembly? Does the merge work fine in this case? @Diaval

Edit: Is this SPR also connected: 532438 ?

hopefully @Diaval jumps in but from what I can tell, Branch always uses the latest, will not use old version even if you have old versions in local cache. If I'm testing it write and not missing some option the merge will always use the latest version of the branched file(s) and put them in as a new version of the master.

Always using the latest on branch seems ok, I think, because I think the master would be in Released state so we would want to be using latest version. As I type that exceptions come to mind...

For merging, we consider the file that's being merged in to be a "test" or "prototype" of the proposed changes, so there could be iterations on that part that would make revisions of that file as it goes through workflow. There could also be sibling branches if we want to test or prototype multiple options in parallel. In that case, only one branch would be merged. Either way, making some version the latest version isn't terrible, hopefully it's not a regular occurrence to want an older version in this case.

How does it behave, when two or more individual changes are made to the same assembly? Does the merge work fine in this case?

If there are multiple changes made to a file in parallel only one will win. CAD files cannot merge changes like text files can do. So if a file is branched to A then that same file branched to B whoever merges last will win. So if B merges then A merges; B's changes will be lost and A will go. This can get messy because it could be possible that the master could be released for production (depending on your workflow and drawing publishing) after B is merged and before A. So B's changes could be implemented for a while, then the master go from Released back to WIP for A to be merged, that that point B changes would be revoked and A would be implemented. Confusing.

[Diaval]

So branching automagically only takes the latest released version?
How does it behave, when two or more individual changes are made to the same assembly? Does the merge work fine in this case? @Diaval

Edit: Is this SPR also connected: 532438 ?

The branching dialog has the option to create the branch using latest version or referenced version for referenced files.

PDM is only handling the reference tree and file metadata with branching and merging. It is not able to do any kind of merging of SW features inside the files themselves.

Because merge is only looking at the reference tree of the source and branch files directly involved in the merge, care would have to be taken when making multiple branches of a files that will have different changes made when needing to merge them together. Multiple merges back to a single source file overwrite the changes made from the previous merge.

In the merge, the physical source file is replaced with the physical branch file for all files in the ref tree using the default Merge option. References are updated based on the selections made by the user in the Merge dialog for each reference (Merge, Use source, Merge as new, Create as new).

The administrator has the ability to define how the variables are handled in the branching and merging of the files similar to how they can be defined for Copy and Move Tree operations.

Branch files are treated as independent with their own lifecycle in the vault. The only difference between Branch and Copy Tree is that branch will maintain an internal PDM source/branch reference for each file in the branch to enable the ability to merge the file back to the source. Because of this, when you merge, it is important to know what variable values should be taken from the original source file and what should be taken from the branch file. For example, the Revision variable should always be taken from the source file to keep the variable value in sync with the actual PDM revision of the source. Any variable values that have been updated for the change in the branch file that should be reflected in the final version should be set to copy from the branch file on the merge.

SPR 532438 is about needing the ability to select what ref tree should be retrieved when opening files from the vault in SW. Currently PDM always gets latest without any option to tell it to get me the referenced version or even better the option to tell it to get latest released versions based on a defined Released state in the PDM workflow.

[Diaval]

I'm really getting tired of this:

image.png

This is just PDM saying that the selected PDM operation will be running a Get and will overwrite the modifications in memory on the file,

[bnemec]

This is just PDM saying that the selected PDM operation will be running a Get and will overwrite the modifications in memory on the file,

I understand. Since we must manually get by referenced version every time we open an assembly it get's old. I was taught that the UI shouldn't pop up dialogs unless the user is off the normal, expected workflow. Users follow path of least resistance. If there are popups on the regular, expected process users are trained to ignore them and click "ok" then when there is a legit need for a popup they click "ok" before reading and understanding.

[Diaval]

I understand. Since we must manually get by referenced version every time we open an assembly it get's old. I was taught that the UI shouldn't pop up dialogs unless the user is off the normal, expected workflow. Users follow path of least resistance. If there are popups on the regular, expected process users are trained to ignore them and click "ok" then when there is a legit need for a popup they click "ok" before reading and understanding.

Ah, I understand now. If this is your standard workflow I can see how frustrating it would get to be prompted with this all the time. Sounds like this dialog needs a "Don't show this message again" option. Check out SPR 784509

[bnemec]

Ah, I understand now. If this is your standard workflow I can see how frustrating it would get to be prompted with this all the time. Sounds like this dialog needs a "Don't show this message again" option. Check out SPR 784509

you are like a Rolodex of SPRs!

[Diaval]

you are like a Rolodex of SPRs!

image.png

I like to keep tabs on enhancements that have been requested.

[bnemec]

Does anyone have any word about if this feature is added in newer versions of PDM? We are getting hammered with lost time and errors due to CAD users having wrong version cached when viewing, reviewing or editing and checking assemblies in. I hear discussions in the room every day about cached version, some of them indicate an understanding of what's going on and some do not.

Some users are pushing to clear cache daily. We looked into clearing cache options with our VAR, working through scenarios and it would boil down to clearing cache every time the file is unloaded in SW. Not having cache is not the solution; getting referenced version of the files every time an assembly is opened is the solution.

I have a couple saved email drafts to send to our VAR about getting some kind of push going, but I know that will take many hours of our time as we must justify the request, yet it still might end in a "NO" from Solidworks.

[jcapriotti]

Does anyone have any word about if this feature is added in newer versions of PDM? We are getting hammered with lost time and errors due to CAD users having wrong version cached when viewing, reviewing or editing and checking assemblies in. I hear discussions in the room every day about cached version, some of them indicate an understanding of what's going on and some do not.

Some users are pushing to clear cache daily. We looked into clearing cache options with our VAR, working through scenarios and it would boil down to clearing cache every time the file is unloaded in SW. Not having cache is not the solution; getting referenced version of the files every time an assembly is opened is the solution.

I have a couple saved email drafts to send to our VAR about getting some kind of push going, but I know that will take many hours of our time as we must justify the request, yet it still might end in a "NO" from Solidworks.

I wouldn't hold my breath. I think a custom add-in would be required. We wrote one for CVD files which we use for ECOs. Since there there is no file behind it and its just ECO meta data, we wanted the data card to always reflect the "Latest". The add-in clears the cache on the CVD after they check it in. I think it also intercepts them trying to "Get" versions, just insures they have nothing cached.

[bnemec]

I wouldn't hold my breath. I think a custom add-in would be required. We wrote one for CVD files which we use for ECOs. Since there there is no file behind it and its just ECO meta data, we wanted the data card to always reflect the "Latest". The add-in clears the cache on the CVD after they check it in. I think it also intercepts them trying to "Get" versions, just insures they have nothing cached.

I'm turning blue...

[AlexB]

I wouldn't hold my breath. I think a custom add-in would be required. We wrote one for CVD files which we use for ECOs. Since there there is no file behind it and its just ECO meta data, we wanted the data card to always reflect the "Latest". The add-in clears the cache on the CVD after they check it in. I think it also intercepts them trying to "Get" versions, just insures they have nothing cached.

I've actually played around with this a bit with a PDM add-in. It will essentially get the latest production release of a part/assembly unless you specify an Engineering Change number(s) then it will get the very latest draft of those since they're the in-process pieces you want in your assembly. I haven't fully debugged it though since there seem to be a lot of cases of assemblies referencing an older released revision of a part as well. I was discouraged after a while since there isn't an easy way to determine every use case and program it in to the software.

I wish the company that created the software would be the ones writing this stuff...

[bnemec]

I've actually played around with this a bit with a PDM add-in. It will essentially get the latest production release of a part/assembly unless you specify an Engineering Change number(s) then it will get the very latest draft of those since they're the in-process pieces you want in your assembly. I haven't fully debugged it though since there seem to be a lot of cases of assemblies referencing an older released revision of a part as well. I was discouraged after a while since there isn't an easy way to determine every use case and program it in to the software.

I wish the company that created the software would be the ones writing this stuff...

Yes, we have looked into various methods of getting the reference tree by referenced version. One obstacle is there's so many things a user can do that triggers (or should trigger) a get file action. Everything from double clicking to opening files from the open file dialog, or replace file dialog, Connisio links in emails, it seems nearly endless the entry paths. I think the only way to handle all of them is right at the get file hook. I've poked around using the EdmCmd_PreGet hook but I'm not smart enough to determine if that is really going to accomplish what I want or if anything I do (such as get the all the references by version) will be overridden by PDM after I return from the add-in. Perhaps the Post-get would be better but then I'm likely getting many of the files twice; PDM gets the latest if there is no local copy then my add-in would get any files that are not the referenced version. But what if the file is open in Solidworks? What if a where used of the file is open so SW has the file loaded? Then eDrawings, I'm lost as to how or if it uses referenced files, I have the setting for file types that viewing doesn't need to cache referenced files, but AFAIK that only applies to right click -> View File in vault view. What if the non CAD user has the .sld% file types set to open in eDrawings and they just double click? What does PDM do then? What if the referenced file is already open in eDrawings? Will it be locked? I just don't have the means to know how to deal with all the what-ifs that I ran into during planning stages of the add-in. The more I researched the more unknowns I ran into, tricking PDM into getting referenced file versions is just beyond my abilities. If someone wants to give me a price on writing an add-in that will work for all the various cases I would be happy to discuss that option with them.

[jcapriotti]

I'm turning blue...

You must be in Offline mode.

[bnemec]

You must be in Offline mode.

I $#!* you not, I just replied to another email concerning versions and updating where used and what version to have of what.... Nearly every day. It's like I'm speaking Greak or Latin or Groot to them.

It used to get my blood pressure up, but now I've come around to the point of "comfortably numb".

I've found that the occasional meme at the top of the reply helps me to feel better. Something like:

Edit: I just got the blue folder ref. nice. Fortunately, with the work from home wound down we have fewer users on crappy VPN connections.

[jcapriotti]

Yes, we have looked into various methods of getting the reference tree by referenced version. One obstacle is there's so many things a user can do that triggers (or should trigger) a get file action. Everything from double clicking to opening files from the open file dialog, or replace file dialog,

I wonder if the DB is structured for doing this efficiently. Say I want to "Get Latest Released", the codes needs to retrieve all version with the highest "Revision" label. On a really large assembly this could be time consuming as it must query each file's history.

In Windchill, this seems to be handled by what they call "'Baselines" which is a snapshot of the BOM structure when it releases. You can retrieve "latest" or "baseline" or 'latest release". The GU stinks and the users get confused on what to select but the capability is there.

That said, to make this work efficiently, you would probably need a custom add-in along with storing data in a second custom DB.

[jcapriotti]

I $#!* you not, I just replied to another email concerning versions and updating where used and what version to have of what.... Nearly every day. It's like I'm speaking Greak or Latin or Groot to them.

That's why we use "Always works with latest". There is a small window for error with assemblies but with hundreds of people, there is a greater risk they are opening an old cached version.

[bnemec]

That's why we use "Always works with latest". There is a small window for error with assemblies but with hundreds of people, there is a greater risk they are opening an old cached version.

We worked through a few examples of that and it would wreak havoc on our assemblies, due to transients of migrating our entire data set into SW (many SW models needing to be redone but they already used in many places) as well as continuous flux of our data set due to legit ECOs.

Users are opening drawings and assemblies much more often and they'll just get latest (which gets latest of the entire ref tree) then most of the time the assemblies are bad with rebuild errors. We just need PDM option to "Always work with referenced version"

We're putting together a financial impact for our VAR to hand off to SW to see if we can get something. I'm scared we're going to find out that there will be endless problems if we cannot just always work with latest.

[mike miller]

We worked through a few examples of that and it would wreak havoc on our assemblies, due to transients of migrating our entire data set into SW (many SW models needing to be redone but they already used in many places) as well as continuous flux of our data set due to legit ECOs.

Users are opening drawings and assemblies much more often and they'll just get latest (which gets latest of the entire ref tree) then most of the time the assemblies are bad with rebuild errors. We just need PDM option to "Always work with referenced version"

We're putting together a financial impact for our VAR to hand off to SW to see if we can get something. I'm scared we're going to find out that there will be endless problems if we cannot just always work with latest.

Are you saying there is no way to force an assembly to use the referenced revision and not latest? That seems like pretty basic functionality.

Teamcenter defines it as "precise" vs. "imprecise". A precise assembly (or component) stays at the specified revision and does not change unless it is explicitly commanded. Imprecise assemblies update based on the active revision rule.

[bnemec]

Are you saying there is no way to force an assembly to use the referenced revision and not latest? That seems like pretty basic functionality.

Teamcenter defines it as "precise" vs. "imprecise". A precise assembly (or component) stays at the specified revision and does not change unless it is explicitly commanded. Imprecise assemblies update based on the active revision rule.

Oh yes, we can get the files by referenced version, but It must be done manually in SW PDM Pro. It seems the "Best Practice" is to always work with latest version, as if always work with referenced version isn't really supported.

Edit: After rereading your question I would have to say you are correct, there is no way to force PDM to cache the referenced versions of parent files. Can only force to cache latest version.

With the 101 ways to load a parent file it's difficult to get the users to always manually get the referenced files by referenced version first. Some users kinda get it but there are a few that just do not understand it. One of the 101 ways that I saw a user doing the other day that I didn't think of when considering an API solution is drag from vault view/search tool into an assembly. I never got into the habit of doing that but to maybe half our users that is the DeFacto method of adding a part or subassembly to an assembly. Well of course PDM will use any locally cached versions and get latest of the rest; both of those are wrong, we need it to get referenced of all the referenced files.

[jcapriotti]

I think an API call is going to have interrupt these actions and prompt you for what you want.

So if the part has 12 versions and versions 5 and 10 are Revs A and B:

• As built version (5/12) Rev A - Released
• Latest version (12/12) Rev B - In Progress
• Latest Release version (10/12) Rev B Released

The last is most important to us and is missing.

[bnemec]

I think an API call is going to have interrupt these actions and prompt you for what you want.

So if the part has 12 versions and versions 5 and 10 are Revs A and B:

• As built version (5/12) Rev A - Released
• Latest version (12/12) Rev B - In Progress
• Latest Release version (10/12) Rev B Released

The last is most important to us and is missing.

close.

So if the part has 12 versions and versions 5 and 10 are Revs A and B:

• version 5 is an old rev
• version 10 is current "released" rev
• version 12 is known to the world as rev C even though PDM calls it "working document" because that version hasn't been stamped with a revision yet. The notion of a drawing not having a revision doesn't fit here.
  
  More about what that means but unfortunately, this gets messy quick
  
• because of inventory, vendor lead times, customer requirements, etc. there may be a long time between when Des Eng releases a revision to when it is implemented. Typical is a couple days to a couple weeks; min and max that I've seen is a few minutes to a couple of years.
• It is not uncommon for rev A to be current production, rev B is "released" but not yet phased in, and version 12 is, unfortunately, the next change request.
• we do not use old revs, many people assume that when I mention get referenced or old versions. We are not using old revisions, the shop cannot make old revisions and the reason the phase in takes so long some times is slow moving inventory needs to be purged or scrapped before the new rev is phased in.
• consider a new usage of that part being released; it's uniqueness has nothing to do with the part we're talking about, it's just using the other part. This assembly being sent to review should be using the rev that is in current production, so it should be referencing version 5 (rev A), not 10 and not 12. There are several reasons for this that I'll just not go into right now.
• deleted, I'm rambling...

[jcapriotti]

close.

[/u][*]because of inventory, vendor lead times, customer requirements, etc. there may be a long time between when Des Eng releases a revision to when it is implemented. Typical is a couple days to a couple weeks; min and max that I've seen is a few minutes to a couple of years.
[*]It is not uncommon for rev A to be current production, rev B is "released" but not yet phased in, and version 12 is, unfortunately, the next change request.
[*] we do not use old revs, many people assume that when I mention get referenced or old versions. We are not using old revisions, the shop cannot make old revisions and the reason the phase in takes so long some times is slow moving inventory needs to be purged or scrapped before the new rev is phased in.

Exact same issue here. We have "Engineering Release" and "Manufacturing Release" but we can't work that into the CAD file workflow. since the files need to undergo more ECOs while the factory "catches up". Engineering can be on release revision "E" while the factory is still processing release "C". The CAD file workflow can't have both in PDM, so we handle it with the PDFs. We create a separate PDF of each revision and they have a workflow that flows from "Engineering Release" to "Manufacturing Release" to "Archive" as ECOs are processed.

Windchill handles this better, each "Rev" of a file/part is separate and have their own workflow state. The ECO sets the files state as certain tasks are completed.

Mfg mostly works from the PDFs, rare they want to open a model except to program CNC stuff or export DXF files.

[bnemec]

Exact same issue here. We have "Engineering Release" and "Manufacturing Release" but we can't work that into the CAD file workflow. since the files need to undergo more ECOs while the factory "catches up". Engineering can be on release revision "E" while the factory is still processing release "C". The CAD file workflow can't have both in PDM, so we handle it with the PDFs. We create a separate PDF of each revision and they have a workflow that flows from "Engineering Release" to "Manufacturing Release" to "Archive" as ECOs are processed.

Windchill handles this better, each "Rev" of a file/part is separate and have their own workflow state. The ECO sets the files state as certain tasks are completed.

Mfg mostly works from the PDFs, rare they want to open a model except to program CNC stuff or export DXF files.

Ah yes, same page. The PDF is how we go about this as well, they are saved with the rev number from PDM in the filename.

Where we are running into problems is not when opening or saving pdf of the drawing; what's getting us is working with all the where used of these files. Remember, all our part numbers can be considered as a "standard part" so they are used in parents that have been released for months, parents that are under ECO and parents that are in prototype phase; usually all at the same time.

[jcapriotti]

Ah yes, same page. The PDF is how we go about this as well, they are saved with the rev number from PDM in the filename.

Where we are running into problems is not when opening or saving pdf of the drawing; what's getting us is working with all the where used of these files. Remember, all our part numbers can be considered as a "standard part" so they are used in parents that have been released for months, parents that are under ECO and parents that are in prototype phase; usually all at the same time.

Yeah, we don't have a good solution for this either. I think Windchill handles this somewhat with it's "Baseline" feature which we aren't using yet. It's a snapshot of BOM "references" and their states/revisions that is created when an ECO reaches a certain state (where ever you set it). So you could create a baseline of a BOM with all current "Engineering Release" revisions. Then call that back up in the future. These are usually created when an ECO releases the parts/drawings, etc.

[berg_lauritz]

close.

So if the part has 12 versions and versions 5 and 10 are Revs A and B:

• version 5 is an old rev
• version 10 is current "released" rev
• version 12 is known to the world as rev C even though PDM calls it "working document" because that version hasn't been stamped with a revision yet. The notion of a drawing not having a revision doesn't fit here.
  
  More about what that means but unfortunately, this gets messy quick
  
• because of inventory, vendor lead times, customer requirements, etc. there may be a long time between when Des Eng releases a revision to when it is implemented. Typical is a couple days to a couple weeks; min and max that I've seen is a few minutes to a couple of years.
• It is not uncommon for rev A to be current production, rev B is "released" but not yet phased in, and version 12 is, unfortunately, the next change request.
• we do not use old revs, many people assume that when I mention get referenced or old versions. We are not using old revisions, the shop cannot make old revisions and the reason the phase in takes so long some times is slow moving inventory needs to be purged or scrapped before the new rev is phased in.
• consider a new usage of that part being released; it's uniqueness has nothing to do with the part we're talking about, it's just using the other part. This assembly being sent to review should be using the rev that is in current production, so it should be referencing version 5 (rev A), not 10 and not 12. There are several reasons for this that I'll just not go into right now.
• deleted, I'm rambling...

What about putting it into a different 'state'? Does that not apply here?

When rev B is done by engineering it goes into a state that is basically released until another party does the final release. Is this not really possible?
i.e. we do have i.e. a ready to release state for our CNC parts. It's reviewed, approved, BOM knows about it... We have regular times throughout the year when this will get released (if it's not urgent) - i.e. once a month - and the only thing we do is to 'release' it.

I know that this does not fix your problem of loading it correctly... :-(
We face the same problem here - but at least you can see & sort it better.

[bnemec]

What about putting it into a different 'state'? Does that not apply here?

When rev B is done by engineering it goes into a state that is basically released until another party does the final release. Is this not really possible?
i.e. we do have i.e. a ready to release state for our CNC parts. It's reviewed, approved, BOM knows about it... We have regular times throughout the year when this will get released (if it's not urgent) - i.e. once a month - and the only thing we do is to 'release' it.

I know that this does not fix your problem of loading it correctly... :-(
We face the same problem here - but at least you can see & sort it better.

We had tried involving the other departments into the workflow to help with this. Several problems came up, here's a couple, the first one could have been figured out but numbers two and three were show stoppers.
1) There's already other data systems that other departments live in, it's hard to claim a net gain when their action is just adding more workload for every part number they touch. If I would have known what I was doing when we set up PDM here we may have been able to do this with some API to transition files using calls from the other data systems triggered by actions those users already do many times a day. Maybe in a perfect world...
2) We thought we could keep it simple with just a single state between Des Eng release and Mfg Eng release. Well then after trying a bunch of things we wound up with a Purchasing Doc Control state and Mfg Eng Doc Control state. Then we needed something to deal with prototype/quote release for purchased part and when a purchased part is released. It just kept snow balling. Files left in states because there was no transition that would work for the process. We wound up making new workflow with just a few states then a bunch of WF jumps with auto transitions to them. That's why "Released" in PDM just means to get changed it needs a rev.
3) Files would be hung up in the other states waiting for the previous change to be implemented while new ECOs were needing to work on them.

What we learned is PDM is >FILE< management. Sometimes it can be made to be a >PART< management system but not with what we're throwing at it. PDM is for Files (metadata included). Yes, we represent objects such as physical parts or concepts such as ECNs or whatever with files and use PDM to manage those files. But the data and behavior of those objects are not fully encapsulated in a file and metadata. So, inevitably there's going to be some function boundary between PDM and whatever manages the rest of the object attributes and behavior. The best place to draw that boundary line will vary from place to place as there are so many things involved. But, I could be wrong about all that I've only been working with it for a couple years now; my perception is still evolving.