Re: Rev Block on Sheet1, Sheet2, Sheet3.....

Hi Michael.

Yes the success of this hinges on having a way to determing the revision for each page, most notably, an index.

I have the dubious honor of having to maintain assembly documentation and found myself asking "why would this multi revison scheme be bad?" The index is evil and so is multi-rev, but so is updating (in reality)

12 document sheets for the sake of one. Remember if you are in PDM (we are), that's 12 check-in-check-out procedures, 11 meaningless rebuilds for a new datatag in the revblock and possibly reving a model that has undergone no geometric change simply to add new annotations to a given page on a given set of prints.

We still do it the "monolithic revision" way, but I see that the rev-per-sheet could work nicely as well and our software should not dictate that we cannot do this.

There is one certainty here - Take the number of companies and multiply by two and take half of that and you will arrive at the number of "right" ways to manage documents. (smile)

Regards,

SMA

It is an infraction only if your QS9000 work instructions were written as such.

Say you update your print to

Date stamp and revision level noted in the drawing title block of each sheet.

We do work with the aircraft manufacturers that have multiple drawing sheets for one part number. Each sheet has it's own revision block and rev level. On sheet #1 there is a tabulated chart that shows the appropriate rev level for each sheet. This works fairly well with no problems. I would just as soon have the choice as to which way I want my revs to be and not be forced to do it this way or that way because that's the way it's supposed to work.

kenneth b wrote:

Hi Matt,

I've been tossing this one around in my head. While we continue to use the monolithic revision method, I think it is aptly called "monolithic" (large stone, which in this case, I often have to bring my Herculean CAD powers to bear to simply change one sheet of 11 - smile). Lets not even mention that fact that we publish the doc set to PDF - another multi sheet file to make meaningless updates to.

Option 1: I can envision a solution, but this has too many technical barriers & qualifiers: Whatever released document the vault gives you is current - end of discussion. This works regardless of date code revision, letter, number, Greek symbol or Chinese ideograph. Since presently all our vendors and people who need prints are not "PDM linked", it's not workable.

Option 2: Structure a BOM in MPR, which gives visibility to people who need it. The idea being that a vendor would also see the need to get an update of, lets say, sheet 7 of the document set. Also a pain, but not PDM or MRP "prohibitive".

Option 3: Put the burden on the first sheet of the drawing, which requires it to be the master for the "drawing set", having a table that defines the rev or release date of each sheet. Alternately, let the front sheet define revision solely, exclude revision from the "individual" sheets and let the front sheet act as the "parent" for the document set. If one is working under release management then the vault will only give current data and if the PDM is "project-object" capable, then the main document can be the parent to the other sheets "PDM-wise".

I think the whole issue here is making sure that documents are current and identifiable in a reasonable way. I don't think that the rev-per-sheet is a bad way to go. But, I do prefer the rev-per-set method as is takes the onus of sheet-by-sheet confirmation off of the end user and places on the document originator. While this is a maintenance nightmare sometimes, it does favor the end user, which in my mind weighs heavily on the "rules of conduct".

Later-

Sean

Hey Sean,

I didn't learn much in engineering school, but I did learn how to organize the information that you have when you're trying to problem solve. From that perspective:

- rev per sheet comes from paper drawing days (not necessarily bad, but its definitely a strike against it)

- revving multiple sheet electronic CAD docs "monolithically" seems very inefficient and a pain in the ass

- revving multiple sheet electronic CAD docs "per sheet" seems like bad practice because there is no master

- revving multiple sheet electronic CAD docs "per sheet" with a PDM system is not possible.

From this, it looks like the problem is either the "electronic CAD" (which we can't get away from) or the "multisheet" condition. What if you just got rid of multisheet drawings? Treat the first page of a drawing like an assembly that calls out the individual sheet documents (each has its own drawing number)? So you'd have a little BOM-like chart on the first page that calls out the individually rev controlled sheet docs. The chart calls out drawing numbers without reference to revision.

That sounds more reasonable to me because it's easy to maintain for the creator and if the sheet doc numbers are assigned sequentially, makes it easy to find for users. Plus, if you end up putting the same schematic on sheet 4 of that 11 page drawing on several different multisheet drawings, the schematic is controlled in one place.

With ProductCenter I remember that you could make links between docs, so you could link the sheets of a drawing together. We don't have that luxury yet with PDMWorks, we can link non-sw docs to anything but SW docs can only be linked to SW docs automatically. I'll keep pushing them...

Anyway, if I had it to do again, I think that;s how I'd handle multisheet drawings.

matt

snipped-for-privacy@frontiernet.net (Sean-Michael Adams) wrote in news: snipped-for-privacy@posting.google.com: