×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

More PDMWorks Talk!
9

More PDMWorks Talk!

More PDMWorks Talk!

(OP)
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.

RE: More PDMWorks Talk!

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

RE: More PDMWorks Talk!

(OP)
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.

RE: More PDMWorks Talk!

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

RE: More PDMWorks Talk!

2
"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

RE: More PDMWorks Talk!

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

RE: More PDMWorks Talk!

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. :)

RE: More PDMWorks Talk!

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. :D

RE: More PDMWorks Talk!

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

RE: More PDMWorks Talk!

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.

RE: More PDMWorks Talk!

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.

RE: More PDMWorks Talk!

(OP)
"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.

RE: More PDMWorks Talk!

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?

RE: More PDMWorks Talk!

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

RE: More PDMWorks Talk!

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.

RE: More PDMWorks Talk!

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?

RE: More PDMWorks Talk!

(OP)
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.

RE: More PDMWorks Talk!

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.

RE: More PDMWorks Talk!

(OP)
"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.

RE: More PDMWorks Talk!

" 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.

RE: More PDMWorks Talk!

(OP)
"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."

Nope what you bring up is not a rant at all.  The truth is that it's pretty much a fact of life that that is we are up against.  It clearly needs to change.  There seems to exist a significant amount of get it done now and future consequences be damned mentality here.  And the consequences are like quicksand because the same trangressions are seemingly perpetuated with each new job.  Many of the practices that are causing headaches for us are rooted in the world of 2D and haven't been properly purged and/or updated to the current paradigm.  Hence the effort at a move towards implementation standards (both PDM and SW).

It (the problems being encounter) isn't really apparent to people because our design cycles are pretty short in duration being anywhere from a week to a month or two.  We own our design work and all SW files throughout the scope of the effort.  The product we work with doesn't call for a multi-pronged collaborative effort by multiple designers on the vast majority of jobs.  Therefore guys don't always understand why things are so messed up when someone other than the original designer goes to execute an ECN on a job.  Sometimes even when the original guy does the ECN things aren't what they expected.

"Your argument is a reason not to use configs at all - not a reason to not use them because of PDMWorks. More semantics."

I can see where it might be perceived that way but for the record I'm all for using configurations in SW.  My point is really that sometimes using a separate file instead of a configuration makes better sense.  Maybe one has to be clairvoyant to know when that's the best course at times though.  That's another conversation I suppose but without a doubt I think that would be interesting if not enlightening at the least.

I did an implementation of SmarTeam PDM awhile back and it handles configuration very nicely.  It's kind of whining on my part more than anything I suppose because it can be made to work as you've done but it would provide more flexibility to the end-users if the software provided the functionality without having to tailor a system to it in order to use configurations.  You admitted yourself that it wasn't an easy undertaking.

Thanks for the feedback!

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

RE: More PDMWorks Talk!

"My point is really that sometimes using a separate file instead of a configuration makes better sense.

I completely agree. We only use them where a few dims are changing or a hole is being suppressed/unsuppressed. Making part files complex for the sake of it is a dangerous game.

While I'm on the subject of complexity. Has anyone used top down assembly design with PDMWorks? We haven't tried it yet, mostly because I'm a bit wary of top down assemblies in general, but also because I wasn't sure if I'd spotted all the "gotchas" with them when they're used with PDMWorks. Has someone got any good horror stories?

"I did an implementation of SmarTeam PDM awhile back and it handles configuration very nicely."

I haven't dealt with Smarteam, but I can appreciate that the increase in flexibility it offers would go a long way. I found the lifecycle setup in PDMWorks to be the most restrictive part. I would like to make the drawing checking/approval system we have a bit more formal, but I just can't see a way to integrate it into PDMWorks robustly.

"Thanks for the feedback!"

No probs

RE: More PDMWorks Talk!

Just offering my two cents worth …

As far as comparing PDM Works and SmartTeam and WTC (there are others out there, yes I know but I’ve only looked at these three at one point in my career) … while they’re all good, PDM Works differs fairly significantly (IMO) from the others.  PDM Works was created solely for the purpose of managing SW files.  It was never intended to be the all encompassing tool for managing SW files, Multi-user interface, Project Management, ECN/ECO control, etc. as SmartTeam & WTC do.

The developer (a former employee or manager of a SW Reseller, Training & Tech Support Center) saw the need after being in the business for a while and listening to the complaints & grumbles of SW users.  His customers (me included) were complaining for the need of a simple tool to help in the management of files.  Most of us didn’t like the size and complexity of the other PDM systems (as well as the cost of these systems) and just wanted something to manage files and multiple users.  PDM Works initial concept was for any user to load the software and (almost) begin using immediately, unlike other more cumbersome systems.

Think of this analogy:  A customer wants to take photo’s but doesn’t want to spend a lot of money, doesn’t have time to learn how to use a manual 35mm camera (I’m age-dating myself), doesn’t want to worry about focusing, light conditions, film speed, etc. … Viola - the invention of the IDIOT CAMERA.  Take it out of the box, drop in the film, and start using it right away.  That’s PDM Works (kind of, IMO).

I give kudos to those of you using (or trying to use) PDM Works in conjunction with your ECN/ECO process.  In fact I’m going to sift through all these posts and make a presentation of the information to my manager so that we can utilize PDM Works better.

But as far as I know, PDM Works isn’t going in the direction that most of you are hoping it’ll go.  At least not now … I think I heard rumors that they’ll be attempting that in a couple of years.

I completely agree with NathanN in that it’s not your setup of PDM Works that is flawed, it’s in the discipline of your SW users.  With any PDM system, it’s easy to “go around the backdoor” to where the files are kept and make changes, thus circumventing the system.  This is where training is required to make users go through PDM Works to open files instead of going directly to the directory where they’re located (I know first hand, since I was one of those offenders).

But that’s just my opinion …

RE: More PDMWorks Talk!

Cheeseburger,
    We knew that the Engineers would want to go around the system. So the administrators had IS lock the location that the PDM Works files are kept. The only way into a file is through the PDM. The Engineers currently want open access to all files. The administrators write protect released documents from them. Our manager wants to find a way to allow Engineers full access and at the same time keep revision control.

Bradley

RE: More PDMWorks Talk!

(OP)
"I completely agree with NathanN in that it’s not your setup of PDM Works that is flawed, it’s in the discipline of your SW users.  With any PDM system, it’s easy to “go around the backdoor” to where the files are kept and make changes, thus circumventing the system.  This is where training is required to make users go through PDM Works to open files instead of going directly to the directory where they’re located (I know first hand, since I was one of those offenders)."

Cheeseburger,

Just to clarify, our users do understand the concept of vault and "working directory."  When working on files related to an ECN the files get checked out of the vault to the appropriate working folder and the ECN is completed and checked in according to the current process which is admittedly a loosely defined instrument.  Believe it or not though, we know for certain that our problems have nothing to do with circumventing the system through the "backdoor."  If anything the opposite is true based on our investigation.

The types of issues that we deal with on the SW front relate to improper use of configurations (see previous comments between myself and NathanN), incomplete understanding of in-context features, etc.  They are without a doubt contributing to our woes with PDMWorks.

PDMWorks issues though are significant as well.  However these aren't as obvious to those of us charged with attempting to fix the problems that we're up against.  For instance we have many problems with assembly models that are checked in to PDMWorks in pristine condition only to come out of the vault for an ECN change a short time afterward loaded with rebuild errors.  We've traced these issues and are able to categorize them into two groups which can certainly fall into the "lack of discipline" arena:

1. Poor naming practices with SW files
2. Lack of clear understanding in regards to the scope of a model change (e.g. a part model change affects several assemblies)

Number 2 to me is a clear limitation of the PDMWorks interface because the user has to dig for the information.  This is tedious and prone to errors IMO especially where a component is common to a large number of assemblies.

The user errors in my opinion though are that one needs to be aware and go through the process of ensuring that the changes to a given model do not affect any additional files that may not be obvious.

So you are absolutely correct, additional user training is required but my purpose in initiating the discussion is not to ask people to tell me that "your users need training." Thanks but we already knew that.  What I'm really interested in is how do people make this work in their respective groups?

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

RE: More PDMWorks Talk!

Just wanted to say what we do at our company:
Drawing is being worked on. First rev 1 then rev 2, etc. This dwg is checked in to 'Development'(design/drafting). Only Design/Drafting can issue a working part number, engineers use there own temp p/n. When engineers are complete with the SW design, they check it in under 'Transfer' and 'releases ownership'. Someone in Design/Drafting then takes 'ownership' and renames it to the working p/n. Engineering now does not have access to these models/dwgs to update/change (read only). When D/D goes to rev A for release, the dwgs are checked in to 'Pre-release'. The ECO/ECN is created with the dwgs. Our manager recieves the package and 'updates lifecycle status' to 'Release'. Only My boss and myself have access to 'PDMWorks Administrator'. Also whenever the dwgs are in 'Development' status, they are 'owned' by each persons login name. When they go to 'Pre-release' or 'Release', they are owned by 'Document Control'. The 'document control' login is a seperate password from the users. I know this sounds confusing, but it was the only way for us to have config mngmt and is somewhat idiot proof.

RE: More PDMWorks Talk!

I'm becoming envious....

I work with a bunch of cowboys who have suddenly been thrust into the world of ECOs, redlines and accountability. I come from a background with strict rules regarding accurate information due in part to the people we supplied. My task is to train cowboys to be gentlemen, which should be fun and interesting and a culture shock. I may get strung up for doing this to them...lol

NathanN - I only mentioned "as-built" drawings because I have seen these cowboys update the model and not the drawing. Therefore, the drawing always refers to the same revision when the "latest" is pulled from the vault eventhought changes have been made. Unfortunately, I walked into a world where they deemed the model the ruling system and not the drawings. Our vendors become VERY confused...

A lot of good words of wisdom floating around this subject, and as I stated earlier, the best practice suits the company and users needs. It's good seeing how others are using PDMWorks.

RE: More PDMWorks Talk!

All good stuff, guys.  We use SmarTeam, so do not necessarily share the same problems.  But the rev letter plus number thing works pretty much automatically in SmTm.

Nevertheless it is not the ultimate solution where models are concerned.  If you follow standard "form/fit/function" rules for drawing revision-v-new part number it gets interesting.  For many drawing revisions on detail parts, the actual model does not change, so it is a royal pain to have to attempt to keep model versions and drawing revisions in sync.  You would have to check the model out and check it back in (unchanged) every time you rev. the drawing.

Too many wrinkles to the PDM scene!!!  One of those necessary evils of life......

3/4 of all the Spam produced goes to Hawaii - shame that's not true of SPAM also.......

RE: More PDMWorks Talk!

(OP)
"I only mentioned "as-built" drawings because I have seen..."

Just another perspective on "as built" versus "latest versions" that I've come to in my reading and conversing with everyone here along with knowledge gained through my own testing/research.

In our particular situation I personally will advocate "as built" drawings because certain model changes were not properly propagated to all relavent assemblies.  Therefore invariably when one of our users opens up an drawing/assembly for ECN using "latest versions" they often encounter rebuild errors, dangling dims, or you name it.  This is even to the point where one guy has admitted to jumping back in the model history to a clean version and then recreating all of the subsequent ECN actions in order to get to a reliable starting point.

It probably goes without saying that this has created a lack of faith in vaulted data within our group.  And this is even the case when we're 100% absolutely certain that something was vaulted in error-free condition.  It's all poor process and standards on the part of the group I'm certain but my point is that "latest versions" can be a major headache in some scenarios (such as the one that I'm part of now).

I think that opening files "as built" and then individually updating versions that are out of synch with the latest vaulted revision is a more methodical and predictable course of action to take as opposed to simply opening "latest versions."  It allows a user to step through and understand any root causes to problems in a logical manner that perhaps causes a bit less exasperation (sometimes).

"We use SmarTeam, so do not necessarily share the same problems."

Ah, I too have a good deal of experience with this package.  I wish that I could pull off convincing people to switch over to that because as a solution SmarTeam is a package that is less "open" than PDMWorks (i.e. harder for users to break...though to be sure it's still "breakable").  That would work better where I am IMO.

"For many drawing revisions on detail parts, the actual model does not change, so it is a royal pain to have to attempt to keep model versions and drawing revisions in sync."

Correct but in SmarTeam do you guys use lifecycle operations (i.e. moved from "Checked In" to "Released" Vault on initial/ECN release)?  I ask because depending upon the type of change to a drawing (e.g. spelling error in a note) as I recall I can allow overwriting of revisions via user permissions in the "Checked In" vault.

If something needs to happen that moves Rev A to Rev B in the released vault then I personally think that it's a good idea to just update the model revision to B as well even if nothing happens to it.  Having been through the process in the past I have to say that I have found that this is easier to do in S/T.  Honestly I don't really see where the "royal pain" comes in but perhaps you're working in a system with requirements that make it so or I'm recalling the past through rose colored lenses.

Sorry to take the subject off-track to SmarTeam.

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

RE: More PDMWorks Talk!

A couple of replies mention the use of SmarTeam, I’m curious as to how long you’ve been using SmarTeam and if you would recommend it to others.

Thanks,
Ernie

RE: More PDMWorks Talk!

(OP)
Ernie,

We used SmarTeam for about a year or so in my previous "life" before it got torpedoed because a lack of clear and solid support from engineering management (aka visible "buy in").  It is a good tool IMO and I would recommend it to others without hesitation depending upon my perception of whatever the situation might be (sometimes PDMWorks is a more legitimate choice IMO).  There are things that I would caution over though before anyone implemented SmarTeam and those are mainly the following:

1. Be certain to have clear buy in from engineering management (an edict to everyone that the implementation WILL succeed would be quite valuable based on personal experience).

2. Understand what you want and need from PDM and put in the time necessary in upfront planning (this can't be overstated).

3. Be prepared for an extended period of time spent on implementation and assign a dedicated full-time administrator(s) to deal exclusively with PDM.

I'm probably painting a picture that isn't very appealling however I do believe in the power of the tool.  In spite of the associated headaches I personally wouldn't hesitate to go to bat for SmarTeam were I in the position to do so again.

Hope these comments are informative.

Chris Gervais
Sr. Mechanical Designer
Lytron Corp.

RE: More PDMWorks Talk!

I just signed up as a member here so firstly let me say hello to all.

I also may have some information to contribute here...

We here at Invacare have been using both SWX (SolidWorks) and ST (SmarTeam) since 1997.  So I guess we've seen all the bad and good with CAD and PDM.  I have not used or seen PDMWorks up close but from what I've read it's focus is more on smaller companies.  ST is being driven as an enterprise solution because of its strong data management, workflow, collaborative, and customization abilities.  ST is focused more on the mid to large sized companies (like Invacare).  RawheadRex has pretty much it the nail on the head.

I will elaborate more on his points:

1. Buy in from all facets of your company not just engineering are key.  More than likely they (other functional areas) might be impacted by this new tool, maybe not within the first year or so but it may happen.  Buy in from the higher ups (VPs, Directors, Presidents, etc.) is also important.  Because those individuals can help extinguish those few fire starters who might try to burn your best laid plans and really help you drive your vision.

2. Plan, plan, plan, and plan some more.  You most certainly need to put a solid plan together.  Lay out your overall plan in logical phases and tackle those.  Having best practices and processes already defined are also a big help.  But don't be afraid to change them a little to help suit your PDM.  These will help you decide what you want and need in you PDM to start.  Make allowances in your plan for possible changes found or problems during your implementation.

3. Implementation should be straight forward if your plan is sound.  If something goes haywire you should have time to fix it.  HIRE A CAD/PDM ADMINISTRATOR or promote someone!!  I should know because I'm that person and it's more that enough to keep one person busy (there's actually two of us here at Invacare).

Additional considerations:

4. Plan on piloting the implementation before full rollout to verify it meets your needs and all the necessary functionality is working correctly.  This will also allow you verify any customizations you might have done or create ones to suit.

5. Create a test environment (allow for one in your plan if possible).... we’ve found this to be very important.  The last thing you want to do is upgrade your production database only to find things aren't functioning like they were.  We have two production servers (Vault and Web).  Our test environment mirrors exactly what's used in production, i.e. the brand of servers, O/S and SPs, etc.  We generally find that some upgrades have bugs and thusly we negate the downtime and lost productivity that could have been caused by putting it directly into production.

6. Communication through out the planning, implementation, and testing are important.  Nobody likes to be left in the dark especially if it effect them.

It's not an easy choice or task, but it must be done.  Generally speaking I would think that most of your time would/should be spent on 1, 2, and 4.  I know that Invacare's choice in SWX would have surely failed if ST weren’t used.  I try to keep a 3-year plan utilizing ST within the company.  Our current plan is global collaboration to other facilities, Mexico, Florida, and Asia.  Utilizing more workflow is in the near future and beyond that who knows.

I sincerely hope this helps.

Kevin Carpenter
CAD Systems Specialist
Invacare Corp.

RE: More PDMWorks Talk!

I am just starting to make rules for PDMW users. Each part has to have unique name. So how do you make naming rules? I found that a new part outside the vault but with same name as the one in the vault, will be shown green upward arrow. In the meantime, the project name should be unique, too.  So do you use project name as part of part name or not?

Thanks.

RE: More PDMWorks Talk!

I wanted to comment. Our company is phasing in a PDM program called Axalant. Axalant is one stop shopping managing all company product documentation. The way it works is everything with a part number has an "Item" file. Linked to the item is everything (models, manuals, instructions, applications, BOMs, raw material, ECRs/ECOs). That being said, they have yet to integrate SolidWorks into it due to issues unknown to me. We started converting over to SW late last year so the majority of our drawings are still AutoCad. All AC drawings are vaulted in Axalant. Our SW files are maintained by drafting in a write protected directory and the responsibility of the drafting mgr. Drafting personnel are the only ones allowed to write to the directory. Engineering development models are maintained by the individual engineers and are not controlled. Our ECR/ECO system within Axalant (all electronic BTW) is such that the model that drafting works with is the official document once it is approved. Our old part number system used a base number and a dash number for versions of a given design. On AC they could all be on one drawing. With SW we are moving them to separate models and drawings. All changes require an ECR. All ECRs are revision changes. The 3D model does not actually carry a rev letter but its drawing does. The version of the model/drawings is irrelevant as the correct information is on the drawing. We're dealing with aviation parts so some strict FAA controls apply here. When they get SW migrated to Axalant I'll be glad to let you know how it works. I do know it is intented to work the same as the AC file mgmt. Incidently, access to the controlled AC files is open to everyone in the company with Axalant but read only. No one can modify the files but drafting and the admins. The only problem I have with this system is that it can be somewhat cumbersome to access a part file deep in the BOM as I sometimes have to go through several sub-assemblies and 4 or 5 levels of "Items".

After reading the other replies it was interesting to see what other companies are doing and how they're dealing with it.

Living in my own 3D world

RE: More PDMWorks Talk!

Spinnerman,

You'll quickly learn that SW will not function in a multi-user, complex assembly environment. We have top level assemblies that number around 5,000 components. A design team of 12 engineers re-uses components. We are looking for a PDM system to keep our lives sane and our productivity up. Revision control (or the lack of it) has been a major pain with SW as a stand alone module. You'll need a PDM system of some type to keep you productivity up.

RE: More PDMWorks Talk!

LENEW,
These are the rules I came up with for our company.
PDM Rules to Live by:

1.    Get latest parts from PDM.
2.    Work only within your working directory.
3.    Keep your working directory clean.
4.    Take ownership as soon as you know you are going to change, if an ECN is required keep ownership until you give it to Documentation.
5.    Do not check out or take ownership unless you are going to change it.
6.    Do not take ownership of an assembly and all children.
7.    Upon check-in, add short note as to what you did.
8.    Release Ownership (if applicable) during check-in not afterwards.
9.    Do not add suffices and prefixes to part numbers being checked-in to PDM.
10.    Do not check-in junk names; get a part number if it needs to be in PDM.
11.    If you are working on projects that are not ready for PDM, create a sub-directory within your working directory for those models.  Remember rule number 2.
12.    Do not delete relationships and external references.
13.    Clean swSolidWorksBackups directory; defrag your C:\ drive as often as needed.

Bradley

RE: More PDMWorks Talk!

Bradley,

Thanks for your sharing of experience.

Here I have another problem, hoping to get suggestions.

I wanted to check a project in the vault. The original project was organized into several folders, Some for parts, some for assemblies and some for both. I created a project and several sub projects accordingly in the vault for keeping the original structure. I used Bulk Check in function basically. I checked in first several folders with parts without a problem, and the files checked in were given A.1 revision by default. Then I started to check a folder with assemblies, the problems appeared. When checking in an assembly, Bulk Check In always brings all the references with this assembly. Because some of references were already in the vault, so in the check in files list, the duplicate part files bumped into A.2. The assembly was still in version A.1, and some new parts were in A.1. So in this ready-check-in list, some are in A.1, some are in A.2.  Then I clicked Check In Files. Then I got the check in report, saying that the files on A.2 failed to check in, because they were already in the vault, and rest of them (A.1) were checked in. Then I opened vault view, looking at the assembly I just checked in. After I opened its references, I found it is pointing to some of references with A.2 revision (the fact is the files on A.2 never checked in, they did not exist in the vault.).

Anybody encounters this problem? Bulk Check In is a quick way to check many files in, but it does not allow you not choose references. It always takes the references with the assembly. Then the parts in the vault before hand, will fail to be checked in. That leads to the problem.

Any suggestions?



  

RE: More PDMWorks Talk!

Lenew,

I am new to this...just joined tonight.  But spent the evening learning about PDMWorks issues.  I finally found your message.......I am struggling with Bulk Check in of projects at this time with the same reference problem you described.  Did you ever get an offline answer to this?  Or solve it?

RE: More PDMWorks Talk!

Jerm99,
I solved that problem. I do the following:

1. check in parts first. (on version e.g. A.1 )
2. check in assembly. In the ready to check in list, you will see some parts on A.2. Force them to be A.1 by inputing into box of revision.
3. check in.
4. You can see some files failed to be checked in. Those are files which are in Vault already.

That help?

Lenew
 

RE: More PDMWorks Talk!

You should check in assy or dwg first. The parts will check in with the assy or dwg at same time. Don't have to do more steps than needed.

RE: More PDMWorks Talk!

ctopher,
I am talking about keeping parts in a separate folder, instead of in the same folder as assy.

Sure you always can check in assy with all its references, then move parts to another folder. However it will be tedious to take ownership, change project,..., again and again, one by one.

By Bulk Check in, save lot of time.

Lenew
  

RE: More PDMWorks Talk!

sorry, but you wrote you check in parts in first and didn't write anything about seperate folders. It guess it wasn't clear to me.

RE: More PDMWorks Talk!

After discussion with our VAR and looking at last nights threads, I am doing the following:
Background:  800 meg assembly with ~739 parts.  Model comes from a subcontractor.  Previous model from the sub has already been checked into vault...this results in ~300 parts that are already in the vault.  First project checkin was done without regard to revision.  New project has custom properties updated (including revision) on the parts...so the new items are preferred.

Bulk-check-in all parts/assemblies.  Approx 300 failed due to the part already existing in the vault.  Use the upper window of the vault to search the source directory for all items "white upward arrow in green circle)" and check in the item from there.  Upon getting to the check in screen.....choose "revision from file" ...this puts the incoming revision in the blank....compare revision with what is in the vault...and choose to check in or cancel (typically check in)

I havent done the drawings yet...I was going to do them next.

RE: More PDMWorks Talk!

We are not using a PDM and after reading the previous posts I have a question.
First off we don't use "Projects", this is our folder/file structure:
D00-02K (drawings 1 thru 2000)
D02-04K (drawings 2001 thru 4000)
D04-06K (drawings 4001 thru 6000)
and the list keeps going...

Question:
Can PDMWorks run in this kind of file structure?

Thanks,

DT

RE: More PDMWorks Talk!

Yes, you create projects within PDMW of the names you typed.

RE: More PDMWorks Talk!

DT,
Filing projects in PDM Works is really cool. It looks like the following:
Project information
        Project:
Description:
        Parent:

This means you can file your drawings under a project that has a parent. In your example it could look like this:
Project:         D00-02K
Description:  1 thru 2000
Parent:         drawings

Project:         D02-04K
Description:   2001 thru 4000
Parent:          drawings

Project:         D04-06K
Description:   4001 thru 6000
Parent:          drawings

Hope this helps.

Bradley

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources