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.

 

[RawheadRex]

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

 

[NathanN]

"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

 

[Cheeseburger]

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 …

 

[Standing]

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

 

[RawheadRex]

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

 

[ctopher]

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.

 

[automationbabe]

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.

 

[JNR]

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

 

[RawheadRex]

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

 

[ecorreale]

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

 

[RawheadRex]

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&quot. 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.

 

[kcarpenter]

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.

 

[LENEW]

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.

 

[Spinnerman]

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

 

[Cryo1]

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.

 

[Standing]

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

 

[LENEW]

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?

 

[Jerm99]

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?

 

[LENEW]

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

 

[ctopher]

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.