I recommend a note on each drawing stating which assembly configuration is used in each drawing. A few years ago, one of my clients had a big problem with this. A user must have switched the configuration used on a drawing and a big batch of the wrong parts were built.
This post has popped in me, an interesting question to the forum here.
Lets take the same example Sandy brought in, a file with 2 Cfgs & 2 separate drgs for those cfgs in a PDM workgroup.
After the drgs are released for production, Down the line, If I need to modify cfg-1. So now, I check out the part & modify cfg-1 & update the drawing for cfg-1.
My question about the revisions :
Part (with both cfgs) file will be revised
Drg for cfg-1 with get a new revision
What happens to Drg for cfg-2. Should we revise when there is no modification.
CAN we have a configuration specific revision?
You have to decide what your controlling file will be. I this case it would be best to use the drawing as the controlling document. Which means you'll place the Revision of the Drawing File itself on the title block and ignore the Revision of the part.
I am also a little confused on the best practice for this scenario.
Jesse is right. We've been doing this for quite a while now. I don't like having the model and dwg out of sync, but many times you just change the drawing anyway without having to edit the model, so you could be out of sync anyways.
I'm not a fan of checking in a new model just because the dwg changed. This make you rely on the ability to check out "as built" we you want to go back in time.
Coming up with a filename convention is much more difficult depending on your structure. If I could do it over from scratch I would create a number system for Generic files. Trying to control verbiage in filenames is a losing battle in some place.
Many of the problems stem from the systems companies already have in place, and trying to conform to those. The list goes on and on....
I would sit your best people down, and think of all the scenarios, then come up with a standard, and stick to it.
The was we dealt with this is to "Allow Revsion Overwrite." We have an ECO process for bumping Revs. It's sort of the engineers discretion to "Bump the Rev" or not.
The only thing that would be better is if PDM actually had an option to "Default to Current Rev." I know that is scary, but some users are on like Rev N and they havn't even changed anything. It is because they were checking stuff in and out with out realizing what they were doing. Part of it is just simply forgetting to change the Rev combobox. I've even slipped on bigger assemblies.
The good thing is we haven't went "live" yet. We are still playing with this. I've dug pretty deep into it already. Wrote some apps with the API. Did some workflow stuff specifically. Pretty cool.
We also have the "allow revision overwrite" on because of the way things work. With that, as long as everyone includes a note as to why they overwrote it at the same Rev, then there is history of a sort. Get them to use the working copy wisely, and then there is no worry of multiple revs for no reason, just have to make sure they are trained appropiately in how to use it, and when to stop using the working copy.
We have development revisions (numerical), and Released revisions (alpha), but still a few people keep uping the model rev like it's going out of style. I have a few that are up to Rev 28......
Bottom line, have a policy, stick to it, train it.
PDM was already up and running when I arrived here, but nobody really sat down and thought about it. It's not pretty, but the data is safe anyway.
Jesse - Maybe you want to be my API guy? Just kidding. I can't see going to that extreme for our small 4 man cad team. A little off subject here but, I too am in the process of rolling out PDM to our group. I am about a month away from going live. One thing I noticed about bumping and changing lifecycles at the vault view is that the rev table does not update to the next rev. (After bumping, if you do a document info in the vault view and go to the view tab, it clearly shows the bumped rev table updated but the drawing fails to update.) The help file says that the bump rev document will get "flagged" in the Task Scheduler if you have PDF's created during check in enabled. I've tested that theory, and I can't see it being flagged. Regardless, the drawing doesn't update. Therefore, it's best if the users only change the rev's or lifecycles during check in. Have you given this any thought?
One last thing. I like the PDF's being created when checking in drawings, but mutliple drawings being checked in caused a windows system error: "Server is busy...retry or select..."?!?!
Jay, I would use PDM for a 1 man CAD team!!! If you have SWks Professional it's all ready included, and regardless what people tell you there is no manual way to do revision control accurately.
Using the rev control table and such because of the overwrites and what not, many people choose to create a custom property to control the rev that is displayed on the drawing. We use a "DWG REV", sometimes too much automation is a bad thing.
We also create PDFs, but then use them in MatrixOne PLM, problem is we name the pdf with the "revX" in the filename, so you can have them locally and not get them mixed up or overwritten by accident. This doesn't happen much anymore due to the imbedded AutoVue viewer.
Good to see you doing your homework first! It will pay-off ten fold!
I'm lookin to be someone's API guy. I've been doing tons or work at home for free. I'd like to be able to tell my wife I made a few bucks.
It seems that PDMWorks does something to the Rev Table on the Drawing when it is checked in. I was messing around with it. I checked out a drawing I had a Rev "_". I added a Rev Table and checked it back in at Rev "A". The table updated. I bumped it to Rev "B". I checked it out. The Rev Table on the drawing did not update. I checked it back in at Rev "C". And now my Rev Table on the drawing states Rev C and A but it skips B.
One good thing about this is that my table will only show the Rev Letters that I checked the drawing in at. So I won't see Rev "+" or Rev "Prototype" or whatever people dream up.
About the flagging. I'm not so sure about that Task Scheduler. I think not only does "Create PDFs on Check In" need to be enabled, but there has to be a PDF for that drawing in the vault.
It is definitely best to force users to only change Rev's on check in.
I haven't had an issure creating PDF's. I wonder if it's a hardware thing. Maybe your computer is getting bogged down. I checked in 70 drawings the other day and it worked. But they weren't complex. But even then PDM doesn't care how complex they are. At that point SW is doing all the work of rebuilding and saving the drawing. The only issue PDM might have is the number of sheets in a drawing, but this is a very simple process. Creating PDFs from code is not hard. Just tedious.
Retrieving data ...