More PDMWorks Talk! 9

[RawheadRex]

I am contributing to the development of a set of standards regarding the proper use of PDMWorks at my company. They've had PDMWorks for a couple of years before I joined earlier this year but it's apparent that the tool was never properly implemented after the installation as problems with files retrieved from the vault is significant. The types of specific issues encountered are too numerous to get into. But needless to say, the time for putting standards in place is overdue.

I've peeled through a good portion of the PDMWorks related posts from the past year or so and read discussion of different aspects of the software that were very helpful. However I didn't come across any overly enlightening discussion of a few topics that I believe are relevant to application of "best practices" in PDMWorks where I work. Therefore I'm hoping that people can comment on how they manage/deal with the following:

1. Managing part models that are used in multiple assemblies. This is a major headache for us as we deal with a large number of components (both purchased & manufactured) that get used in multiple assembly models. PDMWorks doesn't really have the ability to generate a list of assemblies where a given part is used "on-the-fly" (I am aware of the "where used" tab in the document info window but this is cumbersome at best IMO) when checking out that part for revision. By definition, any assembly where the part in question get used should be part of the ECN (at least where I am anyhow) but PDMW doesn't recognize automatically that these assemblies are affected. I administered a SmarTeam installation in a former "life" and am used to this happening automatically in that world. Do I have to slog through those tabs and figures this out the hard way and check out the affected assemblies manually? How do people deal with this?

2. What is the philosophy regarding "check out" versus "open" and then "take ownership" with files? E.g. I open an assembly file with its references using PDMW and then "take ownership" of the assembly itself and just the components that are affected by an ECN. Anything inherently good or bad with this approach?

3. Staying with the example in my second question, say I have changed three out of seven components in the assembly (and therefore the assembly itself as well) but I opened one of the components that isn't included in this group perhaps to simply look at something but the file gets updated and saved somehow. Upon "check in" PDMW indicates to me that this "unchanged" (from my perspective) file is newer than the vault version (upward green arrow is displayed). Assume that I don't know for certain why that is the case but I'm quite sure nothing should have changed with this part. I know that if something did change on a this part that isn't specified in the ECN then the scope of the ECN just increased by some unknown percentage. If one uses their imagination they might see how this can propagate in a far ranging manner. Checking everything out seems like overkill in my opinion and could actually "mask" a change that wasn't accounted for in the ECN (e.g. a component not listed in the ECN that contains in-context geometry to another component that is affected). How do people handle these kinds of scenarios?

4. What types of customizations has anyone written or used with PDMWorks Advanced Server? I have the API manual and a couple of ideas that I think would assist the cause of my group if we were to purchase this module. The things is that the exposed API functionality doesn't appear to me to be very mature in terms of being able to enforce "business rules" by writing an application that runs along side PDMW and SW.

Thanks,
Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

 

[badboggs]

IMO you shouldn't use PDMWorks in conjunction with an ECN process. I wouldn't even advise you to use it for Revision control. The best implementation I've worked with it in uses it strictly for file managment. They use it to make sure multiple engineers don't overwrite each others work.

As far as hardware goes, many of the companies I've worked at actually store their hardware outside of the vault. This seems to work pretty well. You don't want to have to update them everytime you work in an assy.

I'm also interested in other ideas on this matter.

Boggs

 

[RawheadRex]

Boggs,

So then would it be safe to assume that you do revision and ECN control strictly as a parallel process using something like PDF'S? If I understand you correctly then you probably only maintain one version of any given part number in SolidWorks format (SLDPRT, SLDASM, and SLDDRW).

I'm open and interested in hearing all options. If I can evaluate a process someone else uses and envision it working in our group's environment then I will pitch it to my boss as a suggestion.

Storing hardware outside of the vault in a central write protected location is a good idea to a certain point IMO. That was something we tried at my last company but the theory didn't really work out in the way that we'd originally thought. We put the standard parts in the folder but it made more sense to copy out whatever hardware to the project work folder. That kind of made for a lot of uncontrolled files sitting in our engineering work area which ultimately wasn't that big of a deal at that company. Unfortunately I don't that's something that will fly here.

Our "solution" is that we are setting up a read-only "protected files" project in PDMW with all of the generic SW files that we use in our products.

Thanks,
Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

 

[automationbabe]

RawheadRex-

We share the same task of putting standards together, and it seems we come from a similar background when it comes to document control, etc.

Best practices will be defined for where you work and with whom you work with. One solution does not suit everyone, so I wish you the best of luck. Practices also tend to be a work in progress due to changing technology and such, and sometimes need to be flexible to adapt.

Regarding your post, here are my thoughts that may or may not be relevant.

1. Managing shared models: I'm not familiar with SmartTeam and it's capabilities, but you are correct in the fact that we would have to individually select each affected item that needs to be updated due to a child component changing. IMO, the nature of the change determines how and when files are updated. If it is a must have change for safety, then update them all immediately. If its a minor change that doesn't affect form, fit or function, only if time allows do you update all affected parts. Otherwise it can be considered a running change. Documents are updated on a as-need basis and the ECN is not complete until all the changes are complete. However, the proper procedures and documentation need to be in place in order for something like this to work effectively. Other things to consider is if parts and drawings are being opened/checked out in as-built status or latest, and if the MRP system (i.e., part made obsolete) reflects the change. This may be a subject that you would talk to the "upper" heads about by explaining PDM and SW limitations, and the potential cost involved in maintaining a system according to their tried and true system.

2. Ownership philosophy: This is almost a personal preference as one cannot check-in an updated file without taking ownership first. Since it appears that you have an ECN process in place, set some rigid guideline that whoever processes the ECN must take ownership, or check the part out, prior to any modifications. This is a visible cue to other users that the part is changing.

3. Read-only setting: We used to have the exact same problem as you on this, and the following helped us a lot. In SolidWorks, under Tool/Options/External References, make sure that the "Open referenced documents with read-only access" and "Don't promt to save read-only..."(the latter is optional but will save many headaches) are checked. This will force the user to reload the part for write access, which should force them to update the ECN if necessary. PDMWorks will not allow parts to be checked in that have read-only access. This also applies to in-context parts. It will also clean up your check in dialog box because parts that are read-only, updated or not, appear greyed out. Down side to this, which is not too bad, is if you have a crash and have to open the model again. You then have to make sure that all the modified parts are at write access before you can check them in.

4. Advanced Server: Havent set this up yet. Want to get basic standards and practices in first before jumping into this. But I can see how it will help. I will keep you, or you keep me posted, on how it turns out. As for all rules, someone will always find a way to break them or go around them. I can't stress training and enforcement enough on this topic. Unfortunately, my boss is one of the biggest offenders...sigh.

As if I haven't said enough, these are a few other comments that are related that should also be considered:
- Define a ruling party. Is it the model? the drawing? or the MRP/ERP system that has the final say in how a part gets purchased/made? IMO, its the drawing since most places do not buy from models or fab to models or assemble to models. And a drawing cannot be updated without the model being updated as well.
- PDMWorks can be used for revision control with careful planning, but as badboggs pointed out, its primarily a design management tool. There is a difference between a version of a model and a revision of a model.
- Common parts: I know there was a thread started in here mentioning it. I think about part numbering schemes...

I've implemented some of what I've mentioned, still pitching the rest. Change is not easily accepted. Sorry it was so long-winded, and I hope it was clear. Not an easy task ahead of you, so Good Luck! and let me know what you come up with.

automationbabe

 

[NathanN]

"IMO you shouldn't use PDMWorks in conjunction with an ECN process.  I wouldn't even advise you to use it for Revision control."

I disagree. In fact, I'm puzzled as to why you think it isn't good for revision control. Sure, there are differences between the version of a model and the revision, but a suitable revision scheme should be able to accomodate this. We chose a 2 part revision number, eg A.01, B.01, B.02. The letter designates the revision, while the number designates the version. When a new revision of a document is released, it only has the first part of the revision number, because manufacturing just want to know what the revision is. The second part is only for the Design Dept, and is only used during the design process. Once the drawing has been checked, the revision letter is bumped,and secondary number is removed. When used in conjunction with lifecycles, the scheme works very well (though it still isn't perfect).

Another complaint I have heard often on these forums is that configurations do not work well with PDMWorks. I only partially agree with that point of view. We use configurations AND revision control, and it works. IMO, the part numbering scheme that your company uses has a big effect on how well configurations work. We managed to get our part numbering scheme changed when we implemented PDMWorks. If your part numbers aren't suiable, then you can easily get into trouble.

Nathan

 

[badboggs]

Nathan,

I'm glad you found a way to make it work. I like the idea of a sub-number for each major rev. It does become a problem if you only have the A. Then everything becomes A+ and it is hard to define if the item is at A or B because it is different. With your method it becomes more managable.

One question I have for you is at witch level do you consider a revision complete. For instance at which level is a rev A actually A. And when is it actually B. I guess what I'm asking is if you had to deliver a print to a customer and they wanted Rev B which one do you give them? I'm assuming it would be just B? Or B.01?

Thanks,
Boggs

 

[NathanN]

I'll go into a bit more detail.

For new products the first check in has revision is -.01. The "-" was chosen simply because we needed something before "A". During the design process the "-" is kept constant and only the number is changed. eg the second check in would be -.02. This allows us to keep the design history for the part and keep the revision letter at a managable level.

During the design process the drawing's lifecycle status is "In Design". When the designer wants to get the drawing checked and approved, he changes the lifecycle to "Pending". The owner of the document changes to an Admin whose job is to approve the drawing. When the drawing is approved, the lifecycle is set to "Released" and the owner set to nobody. The revision number changes to "A".

If a revision needs to be made to the part, the lifecycle is set "In Design" again, and the revision is set to "A.01" on the next check in. When the change is approved, it will become revision "B".

Only the documents with the "Released" lifecycle are visible to manufacturing, so they only ever see documents with major revisions (A, B, C, etc...) and never any of the intermediate revisions (A.01, A.02, B.01, etc...).

Feel free to email me if you want more info.

 

[NathanN]

Actually, another thing...

IMO, working copies should never be allowed. They are the spawn of the Devil. If you're not very careful, it can very easy to have documents referencing working copies that no longer exist. If you open the file "As Built", what is it going to open? Working copies aren't allowed at my work, though I do allow people to overwrite the latest revision (against my better judgement).

Sorry, I just had to get that of my chest. I feel much better now.

 

[badboggs]

I haven't yet worked with Lifecycle. I suppose I had better get some reading in. I like the idea that you can limit which files certain people can view.

Boggs

 

[automationbabe]

NathanN -

I'm glad you are able to make PDMWorks work with you and your group. But that is why I threw in the comment about careful planning. Without it, or a system, it won't work the way it can.
I like the what you have set up at your place. Been trying to get the same thing done here. Tell me, do you sync your model revisions with your drawing revisions? This is an on-going discussion where I work, and would like an outside opinion.

 

[ctopher]

I will always try to sync my models rev with the dwg rev, but it will not always let me do it. If just the dwg is changed, PDMW will let me checkin the dwg at the next rev...but not the model because it was not updated. If it is a simple part or assy, sometimes I will save it again just to match the dwg rev. If it is a complicated model, I won't mess with it. Either way it works fine, PDMW is just a file mngmt tool...not a rev control tool.

 

[RawheadRex]

"Tell me, do you sync your model revisions with your drawing revisions? This is an on-going discussion where I work, and would like an outside opinion."

Excellent question! This is another thing that we're trying to get fixed here. I think the intermediate revisioning scheme mentioned earlier helps the problem somewhat but when I go to check out a drawing file that's at Rev D and the model's at some other different revision level everything is thrown into question. Not to mention that it is counter-inuitive to whomever is trying to execute an ECN.

More thoughts and comments please.

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

 

[MadMango]

At my company, we made a leap of faith. We decided that the 2D drawing would rule as far as revision/version was concerned. We placed all the drawing title block information in the part models. This forced users to check out models each time a change had to be made to the drawing. This helped to some degree in keeping the drawings and model revisions in sync... but still wasn't 100%.

Our leap of faith was trusting the PDM software (in our case WTC's ProductCenter) to manage the files properly. PDM systems won't handle ECN operations. IMO you have to have a well defined ECN process in place before you even consider PDM.

MadMango
"Probable impossibilities are to be preferred to improbable possibilities."
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[badboggs]

Well that depends on how you use the PDM system. As I said earlier my current clients use it purely as a file management tool. It makes it much easier for multiple engineers to work on the same project at the same time. And I am loving the search functionality. I like how once a part is named with the correct number you can find it very quickly. I can't tell you how long I've watched some people search thru their solidworks heirarchy looking for a drawing manually. Now you are guaranteed to open the latest and greatest.

Boggs

 

[NathanN]

There's really no difference between a drawing referencing a part and an assembly referencing a part. Would you try to keep the revision of an assembly and its parts the same? Of course not. What about a drawing that references 2 or more parts. Should all the parts have the same revision as the drawing? No. So why force all the part/drawing combos to have the same revision? It's just not going to work unless you have a "one drawing per part" rule, which is too restrictive IMO.

We chose to trust PDMWorks. The revisions of drawings, parts and assemblies are free to change independantly. Some simple rules can then govern whether a document's revision should change.

1. If a document is explicitly changed, its revision should be bumped.

2. If a file is implicitly changed AND the change is significant, it's revision should be bumped.

A few notes are probably required to make the rules clearer. Explicitly changing a file is defined as checking out a file, making changes then checking the file back in. Implicitly changing a file refers to the changes made to referenced document propagating into the original file.

 

[automationbabe]

NathanN -
I'm assuming you are opening all of your drawings in As-built status then?
I don't see how the one drawing per part rule is too restrictive. A part needs a drawing in order to make it. An assembly, in essense a part, needs a drawing to assemble it.
I can agree with you about not keeping the models and drawings "exactly" synced, but I think a level of sychronization is needed somewhere. I consider the main revision, i.e., A.00, an actual part revision. The drawing can be reved to A.01 for a drafting error, typo, whatever. And the model can be reved to A.01 for things such as adding material properities, changing the color, adding a config that doesn't affect the drawing. As soon as a feature changes, or specifications on the drawing change is when I feel both need to be reved to next level B.00 in order to keep them relatively synced. I hope that's what you were refering to.

Currently, we have our drawings at letter rev levels and models at numeric revision levels. This is confusing at time. Unless you know what you're doing, and are not in a rush, you will get what you should get. I've seen this back-fire many times though. I don't agree with this setup, but it was in place pre-me. Any thoughts? I would like to see it change.

I like the drawing as the ruling system as well. You can always grab the as-built version and know its correct to that drawing. Then there are no worries as to what revision the model is at, but this doesn't work for all scenarios...and there are times when a sub-assy/part is newer and you want that loaded immediately.

Anyone playing with PDMWorks 2004?

 

[RawheadRex]

I have suspected since I was put onto this PDM Standards project that utilizing the secondary revision field is the tool of choice to assist with versioning of drawings and part/assembly models at the same revision level. However I hadn't been too successful at developing a clear picture in my mindseye of exactly how to apply my feelings to a tangible solution.

To me, what "automationbabe" outlines in her example using the numeric portion of a revision to maintain some semblance of synchronization between drawing and part/assembly model, makes the best of what I personally consider to be a situation without a good clear solution. Thank you very much "babe" (please excuse using the more familiar version of your handle)! I plan to pitch what you've outlined to my boss.

To expand and state my own opinion on synchronization of drawing and model, I've given a fair amount of consideration to the issue and believe that every effort ought to be made to achieve parity between drawing and part/assembly model. At a glance, when someone notes a discrepancy in the revision level between drawing and model the possibility exists that problems could arise (especially when considering opening of a drawing "as built" versus "latest revision" - see below).

Regarding the practice of opening files "as built" or "latest revision" I have found that opening drawings and assemblies "as built" does make some sense. However my boss happens to disagree and believes the opposite is the best path to take. Where this is concerned we have spoken at length and come to the conclusion that each is a slightly different method of arriving at the same location. Theoretically he and I agree that when dealing with the latest revision of a drawing for example then either selection ought to yield the same result. The reality is that we've got a fair number of cases where we have to deal with incidental issues where vaulted data is concerned. These are mostly due to poor standards of usage.

Where "as built" vs. "latest revision" is concerned can anyone please explain any clear advantages/disadvantages regarding this option?

=====
"I like the drawing as the ruling system as well. You can always grab the as-built version and know its correct to that drawing. Then there are no worries as to what revision the model is at, but this doesn't work for all scenarios...and there are times when a sub-assy/part is newer and you want that loaded immediately."

I would think that this is the only way it makes any sense (drawing revision rules). As for the "but" in the second sentence above, this would be a case where one wants to open using "latest revision." What I plan to advocate is that -

1. Drawing revision rules
2. Intermediate drawing revisions must have a tangible drawing change associated with them (e.g. spelling error correction in the drawing notes) that is explicitly noted in the PDMWorks "Notes" field.
3. Intermediate part/assembly model revisions must have a tangible change associated with them (e.g. custom property update) that is explicitly noted in the PDMWorks "Notes" field.
4. Maintain synchronization of drawing and model revision where practical and possible.

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

 

[NathanN]

Hi Automationbabe

"I'm assuming you are opening all of your drawings in As-built status then?"

No, we use "latest revision". "As built" is only be used if we want to see what a previous revision looked like. I can see what you're getting at though. This is what I meant when I said we decided to trust PDMWorks. Its fine for a drawing to reference an older revision of a part. Because the assumption is that the latest revision of the part won't change how the drawing looks. This is covered by rule 2 that I posted earlier.

"I don't see how the one drawing per part rule is too restrictive. A part needs a drawing in order to make it. An assembly, in essense a part, needs a drawing to assemble it."

I can think of a few instances where it is restrictive.
A part file with multiple configurations, each representing a different part, will often have multiple drawings.
A very complicated part may need more than one drawing to provide enough info to make the part.
One drawing may reference multiple parts.

"I can agree with you about not keeping the models and drawings "exactly" synced, but I think a level of sychronization is needed somewhere. I consider the main revision, i.e., A.00, an actual part revision. The drawing can be reved to A.01 for a drafting error, typo, whatever. And the model can be reved to A.01 for things such as adding material properities, changing the color, adding a config that doesn't affect the drawing. As soon as a feature changes, or specifications on the drawing change is when I feel both need to be reved to next level B.00 in order to keep them relatively synced. I hope that's what you were refering to."

Your system doesn't work when configurations are used. I'll give you an example.
A part file contains 2 configs that represent "PartA" and "PartB", and each config has a drawing file associated with it. If PartA gets revised, but PartB doesn't, the part file still needs a revision increment. So PartB gets a revision bump even though it hasn't been changed. This must then flow through to the drawings, which will both have their revisions incremented. Poor old production, who couldn't care less about how PDMWorks operates, are now getting "new" revisions of drawings that are exactly the same as the previous revision. Ick. Imagine if you had 50 configs all representing parts. :-(

"Currently, we have our drawings at letter rev levels and models at numeric revision levels. This is confusing at time. Unless you know what you're doing, and are not in a rush, you will get what you should get. I've seen this back-fire many times though. I don't agree with this setup, but it was in place pre-me. Any thoughts? I would like to see it change.

I'm a bit confused. Do you mean that parts have revisions 1, 2, 3... and drawings have A, B, C...? How would this even work with PDMWorks? We use the same scheme (which I mentioned earlier) for parts, assemblies and drawings. I think it would work with your setup. To be honest, there's very little difference between how you think things should be done and how I think they should be done. At my work we wanted to use configs a lot, so we didn't really have an option to synch our revisions. If you don't use revisions, then its not a problem.

"Anyone playing with PDMWorks 2004?"

Yup, we're using it. The ability to map custom properties for SWX and AutoCAD is the biggest improvement.

RawheadRex, don't worry too much about "as built" and "latest revision". Once you've settled on a system it should be a lot more obvious which one you should use.

 

[RawheadRex]

"This is what I meant when I said we decided to trust PDMWorks."

It's obvious that you have a system that:
1. Your users understand
2. Is implemented and policed properly

To that end, I have to say that I am envious. Unfortunately the vault data is in such a state of chaos where I'm at that trust is simply not an option (at this point anyhow). Intuitively one ought to have the ability to open an assembly using "latest versions" without encountering any errors with lost mates, faces, in-context features, etc. We consistently deal with exactly that though each time something is pulled from the vault.

"A part file with multiple configurations, each representing a different part, will often have multiple drawings."

This is probably just semantics but I'll bring it up anyhow. I would argue that if the configurations are unique enough not to be covered using a tabulated or multi-sheet drawing then individual files are required for configurations specific to any given unique part number. Different organizations see things differently so perhaps it doesn't apply to your situation which I will concede is very likely the case.

"Your system doesn't work when configurations are used...."

I notice that previously you've expressed the notion that PDMWorks does in fact play well with configurations to a certain in contradiction to this being a limitation that is openly acknowledged by SW support and VARs. Obviously you've devised a system where you cause PDMWorks and SW configurations to coexist in a way that works for you.

To me though your example can be used to demonstrate quite well exactly why PDMWorks and SW configurations don't play well together. If a single file with multiple configurations represents multiple part numbers that might potentially be revised independent of one another then the PDM software ought to be able to handle this scenario. Other PDM systems handle this without issue because they are "data-centric" as opposed to a "file-centric" like PDMWorks. Thus "PartA" can be upward revised to a new revision along with its associated drawing without affecting the "PartB" revision scheme because each config is managed indepent of one another by the software because they are recognized as separate part numbers. In other PDM software there is an associated database that manages everything including revision levels of file configurations being managed as seperate PN's. PDM Works doesn't manage configurations it manages files and their references.

As I said though I applaud that you are able to work within a system where configurations and PDM do work well with one another. Using your previous example (PartA and PartB) are you saying that the file revision of the part containing the configs can be anything and that the drawing file is the gauge used to determine latest revision for each config? If so then I have the following question, if there is a revision to PartB, when someone pulls that out of the vault are they taking the latest revision of the model containing PartB? If so then Murphy says it isn't inconceivable that something happened during the change to PartA that inadvertently affected PartB. What do you do in that case?

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

 

[NathanN]

" I would argue that if the configurations are unique enough not to be covered using a tabulated or multi-sheet drawing then individual files are required for configurations specific to any given unique part number."

In some instances, certainly. We wanted to have the option of doing it either way.

"I notice that previously you've expressed the notion that PDMWorks does in fact play well with configurations to a certain in contradiction to this being a limitation that is openly acknowledged by SW support and VARs.  Obviously you've devised a system where you cause PDMWorks and SW configurations to coexist in a way that works for you."

Yeah, that's basically it. We decided we wanted to use configs right from the outset, so we setup the system to work with it - including a part number overhaul. It certainly wasn't easy to find a system that I was happy with. Trying to use configs in an existing setup is probably suicide.

"If so then Murphy says it isn't inconceivable that something happened during the change to PartA that inadvertently affected PartB.  What do you do in that case? "

Damn! You've spotted the flaw in my plan. ;-)
Sure, it's possible. It's also possible that someone will alter a part that's used in umpty-million assemblies. Design tables help to mitigate the risk with configs, PDMWorks helps to mitigate the risk with parts used in many assemblies. Your argument is a reason not to use configs at all - not a reason to not use them because of PDMWorks. More semantics. To answer your question, the offending part can be changed back relatively easily with PDMWorks. It would be a lot harder if we didn't have the previous revision. So in this instance PDMWorks is actually the solution, not the problem.

If you will permit me a small rant... Your problem doesn't seem to be a poor setup of PDMWorks, rather it looks like people are not using SolidWorks correctly. If your guys don't understand the implications of changing parts/assemblies in a multiuser environment, then they would be making the same mistakes with or without PDMWorks.