WPDM: Revision & Lifecycle Suggestion? 1

[jstluise]

I apologize in advance if this would be better suited for the Configuration Management forum, but I thought it fit well here since it is kind of specific to Workgroup PDM.

I'm working on organizing a revision scheme for my company since it really hasn't been utilized at all. I realize that what may work well for one company may not work for another, but I'm just hoping to get some ideas from the forum. First, a little background on what kind of work we do:

We are a small R&D (mostly aerospace) company (~30 employees, ~10 SW users) which means we do a lot of concept CAD work for proposals and contracts as well as one-off prototyping. Most projects and contracts we have move pretty quickly, as most R&D work does. The farthest most projects get is prototyping, but we do have a handful of products that have been manufactured and sold to customers (very low quantities). While not having a revision scheme is okay for concept work, we're asking for trouble by not having it in place for parts we're actually building and even selling.

I've done some searching around for ideas about revision schemes as well as thinking about how a revision scheme would fit in with the workflow around here. Because a lot of our work moves so quickly I think keeping the revision scheme as simple as possible will have the best chance for success (i.e. people will actually use it). My thought is to just have a simple pre-release scheme and a scheme for once the part has been released for manufacturing. The basic scheme that I've seemed to settle on is:

Development: -.01 thru -.99, e.g. -.01, -.02, -.03. (dash in primary indicates development status)
Release: A thru Z.99, e.g. A, A.01, A.02, B, B.01. (alpha primary indicates major release, numeric secondary indicates minor change to release)

Also, I think having a working copy ( + ) would be beneficial at least in the development stage.

At first I was thinking we didn't need to deal with lifecycles, but after further thought having some simple rules might help with revision control. Maybe just having "Development", "Released", and "Obsolete", with rules to keep users from accidentally using a revision letter/number for the wrong status. No need to control document access or change owners with status changes. Also, having lifecyles enabled will give us more metadata if we want to utilize it.

Sorry for the wall of text, but if anyone is willing to share their experience that would be very helpful, especially if you have similar workflow (concept work, prototyping, etc). I'm sure I'll have some more questions but this is a start. Thanks!

 

[GRF]

I would stay away from Workgroup PDM. SW2017 is the last version of the software that will support Workgroup PDM. Starting with 2016 with Pro and higher versions of Solidworks you will get Solidworks PDM which is a scaled down version of the old Enterprise PDM now known as Solidworks PDM Professional.

 

[jstluise]

Thanks for the response. We've been running WPDM for quite a few years now and it has worked fine for our needs so far. But all we've really used it for is storing our files on the server in the vault...no lifecyle/revision utilization. We'll have to adapt to the new version of PDM when it comes out.

Up until now no one has used any revision control mainly because the current scheme that kind of came standard with PDM is overkill for our type of work. That, and no one really took the time to plan a new scheme out. I'm hoping to come up with a simpler scheme that makes sense for our workflow so everyone will begin using it correctly. I think I have a pretty good idea but I just thought I'd make this thread for any suggestions/tips/critiques. I've seen various revision scheme examples from browsing the forums but nothing really geared toward R&D and prototyping.

One question that someone could probably weigh in on is regarding when you distinguish between a major release and a minor change to a release. For example (using the scheme in my OP) I release the part for machining, rev A. If I make a change, how do I decide whether to go to A.01 or B? My thought is that if the change is still backward compatible (i.e. A and A.01 are interchangeable), then you make a minor revision. But if the part is not backward compatible, you go to the next major revision. Thoughts?

 

[ctopher]

We use WPDM.
Prelim rev's 1 thru ?
Release A thru A1, thru ?
Rev's should only be 2 digit's per standard.
We have Development, then Released.
We tried Pre-Release, In-Change, etc. It turned out to be too cumbersome and confusing the more users we had.
Make it simple. Not every user understands file management, or revision cycles, very well.

Chris, CSWP
SolidWorks '16
ctophers home
SolidWorks Legion

 

[Updraft]

As Chris said, "Make it simple. Not every user understands file management, or revision cycles, very well."

- - -Updraft

 

[jstluise]

Exactly. That's why no one has used or attempted to use our current scheme...just way to complicated.

Just like ctopher, I plan to have just Development and Released lifecycles. I don't think Obsolete is necessary as long as previous released versions remain saved (rather than moving them into Obsolete when they are replaced with a newer release).

Rev's should only be 2 digit's per standard.

Can you elaborate on this?

 

[GRF]

I have been using/managing WPDM for about 10 years.

We use numbers for prototype/engineering design revisions -01 through -99.
Once a product is released to production it goes to revision A. (should match last numbered revision, but may have a small change)

Any change after that is rev B if we are going straight to the change in production (99% of the time for us). If we want to do an engineering build to evaluate the change first then it would go to A-01 (~1% time for us). We do not have a major or minor change differentiator. Any change that is released to production gets a new revision. Our revisions run out at AZ. We skip over revision "I", "o", and "q" because when written as capitals they can be confused with 1 or 0. If you get more than 46 revisions to a part the chances of it having the same form and function as the original are pretty slim.

We try to make sure we check in a copy of any file that is getting sent out to get quoted or made so we can always go back and reference it.

Once new revision is checked in the previous revision is marked as obsolete so anyone on the mfg or purchasing side cannot see those revisions. Engineering can see the revisions and get copies of them even though they are set to obsolete.

We do not keep nut, bolts, screws, or standard electrical package models (0402 resistor) in the vault. Those are stored on the network in a design library folder.

Solids and Models are kept at the same revision. Even if there is just a change to the drawing and no change to the model we will up rev both documents to avoid confusion. Unfortunately we have to do this manually.

 

[jstluise]

Thanks, GRF. Lots of good info and it sounds like your scheme would work well with our workflow. The only difference being that we rarely go into "Production", so I think we would release a part when it is first sent out for machining, be it a prototype or actual part we are selling.

I think I'm with you on revisions to releases. It seems like most changes made to a released part will rarely be backwards compatible. I can think of a few scenarios where it would (e.g. slightly modifying something to make it easier/possible to machine, but not affect the form/fit/function), but most of the time you'd go from A to B (to C, etc) without any intermediate revisions (e.g. A.01).

Or, another way I could think of doing it is to not worry about the whole backward compatibility thing and just use the minor revisions in the Released lifecycle to track change right up until the part is machined. Then the next machined part would bump the major revision. For example:
Development: -.01 thru -.12
Ready to Release: A
Make some changes before machining: A.01 thru A.05, part is then machined at A.05
Ready to implement changes: B
Make some minor changes before machining again: B.01 thru B.03, part is machined at B.03

I feel like the latter method prevents unnecessary bumping of the primary revision when you are in Release. Say you send a part out for quote (rev A) and the vendor comes back with a question or you realize you forgot a feature. Instead of making the change and going to rev B, you can just increment the minor revision to A.01. I know we deal with a lot of back and forth for prototyping parts, mostly making minor changes to improve the machining process and bring the cost of the part down. Does that make sense?

 

[ctopher]

jstluise,
ASME Y14.35, Para 5.1:
"Revision letters shall not exceed two characters."

Chris, CSWP
SolidWorks '16
ctophers home
SolidWorks Legion

 

[RathodAsit]

Dear jstluise,

we are also in same kind of group R&D , we are making prototype of power electronics component, after testing it will be release to Engineering Department, and then finally Engineering will updated the 3D/2D as per the customer requirement.
Older Practise
Also having problem of Revision Control in 3D and 2D.
Development REV-00 Initial Release for Prototype, and subsequent revision for changes like -01, -02..
3D Name: DrawingsNO-00, for Revision Increase -01
As Assembly having subparts Part-01 and Part-02,
Assembly 3D Name: DrawingNO-00
1st Subpart 3D Name : Part-01-00
2st Subpart 3D Name : Part-02-00
New Practice

When we Want to revision Increase to any part of assembly it will be difficult to track.
so we have started adding Revision Name like Drawings No_REV0(e.g Adding Rev_XX word in 3D File name Only ),previously we don't keep older 3D, and now will practice to keep Older revision 3D/2D Both

Any suggestion on this.

Thanks in advance

Best Regards
Asit Rathod

 

[jstluise]

Hi Asit,

If I understand you correctly, you are having trouble with figuring out the best way to deal with drawing and part revisions? First, are you using PDM? If you are, your file names should be "dumb", meaning they don't have any data/properties within the file name (e.g. revision number). By making the file names "smart" you are defeating the purpose of PDM. The only requirement with PDM is that the file names be unique, and everything else (file properties) are handled and organized within PDM using the file metadata. There are many suggestions dumb file naming schemes if you search around. I think EPDM will actually handle the file naming for you, but with WPDM you have to do it on your own.

The scheme we ended up choosing that has been working well so far is in the form of XXX-YYY-ZZZ, where XXX is the Project Number, YYY is the sub-Project Number, and ZZZ is the Part/Assembly number. So, it is kind of smart, but ultimately it just prevents users from potentially using the same file name. Usually we only have one person working on a project at a time so we haven't had any issues...if you had multiple people working on the same project you may run into issues when you grab new file names.

Anyways, on to your question. There are a couple schools of thought that I have come across. One is to keep your drawing and part revisions always the same. So, if you bump the revision on the part, you automatically bump the revision on the drawing even if nothing in the drawing changed. The only problem I see if that if you make a change to a drawing (e.g. changing a note) then I don't necessarily think you should bump the part revision (maybe you should?). But, if you make the change to the drawing and don't bump the revision, then there might be confusion when your customer has two different drawings with the same revision number. So, maybe you should bump the revision of both whether you change the drawing or part.

The other method is to keep the revisions separate which means you will have a Drawing Rev and Part Rev indicator on your title block. This would be useful if you make a change to a drawing but don't want to bump the part revision. You could also make your drawing and part revision numbers sort of matching. For example if your part revision is A, your drawing can be A.01. If you change the drawing it would be A.02 and so on. If you change the part, you move to B and your drawing moves to B.01. This lets you have revision control of the drawing while still being able to determine what revision the part is at.

The moral of the story is that there are plenty of different ways to do something in terms of part numbering and revision schemes. There are no right or wrong ways to do it, just a matter of which method works best for your workflow.

 

[AnnaWood]

Keep everything as simple as possible.....

Anna Wood
SW2015 SP5, Windows 7 x64

 

[RathodAsit]

Hi jstluise,

NO we are not using any PDM as of date now we are Planning to use PDM in solidworks, (we have SW2012 Professional)

I believe the best way is the pointno1, Which you mentioned Bump the revision on the part, and automatically bump the revision on the drawing.

Current practice we have only 1 3D Model and 1 SW Native 2D files and we have multiple PDF/DXF of Different Revision.

and in New Practice Different revision Solid works Native 3D/2D(Believe multiple 3D for same parts with Different Revision)

currently we have different people working on same project and files are in Local Machines, so we are facing issues with Revision Control.
and I believe after using PDM(not sure EPDM or WPDM) will resolve issues in Revision Control.and all the files are in vault Servers no Local Files.


Hi AnnaWood

Trying to make simple things but, Human thinking is always try to do complex things

Thanks & Regards
Asit

 

[jstluise]

Asit,

Yes, if you move to PDM a lot of your headaches will go away. Before we started using PDM we had lots of trouble keeping everything straight between users since files moved between our network storage and local machines.

If you are just looking for vault storage and revision control WPDM is all you need (soon to become PDM Standard). WPDM is more powerful than just that and EPDM even more so, but it is overkill for our small operation. WPDM will be able to keep all your files straight as well as save all previous revisions. It works very well when everyone uses it like they are suppose to.

Anna is right, keep it simple. I'm beginning to think about ditching lifecyles altogether and just having a simple alpha-numeric revision scheme (e.g. -.01, -.02, -.03, ... , A.01, A.02, ... , B.01, ...). The primary revision will be for major changes/milestones (e.g. release for manufacturing) while the secondary revision will be for minor incremental changes. And leave it up to the engineer's discretion of when to bump the revision.

 

[RathodAsit]

Hijstluise,

Thanks for knowldedge sharing, It really help.

That simple alpha-numeric revision scheme already adopted /used CISCO,when I used to work with them.

Thanks & Regards
Asit