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

So has anybody else had the problem with the Rev Block not putting the
column headers on when it's inserted onto Sheet2 or Sheet3 or Sheet4, etc.
of a drawing? It comes in fine on Sheet1 but any other sheet after that, all
of the column headers are missing.

Is there a fix for this?

TIA, Richard

 

The best fix is to not do it.

As with BOM's, it is not good practice to have multiple copies of rev.
blocks on multiple sheets.

 

(TheTick) wrote in

I agree, More to the point, it is bad practice to rev separate sheets
separately. That is a hold over from a time when a physical piece of paper
was a document. If it gets rev controlled separately, it should have a
separate document number.

matt

 

That's exactly what is happening here. All I want is for each REV. block to
come in on each sheet with the header columns and be able to add a revision
and have it add a letter instead of a dash. We keep all of our REV's for
each sheet the same rev letter, but it's a lot of extra work to add all the
info manually to each sheet. It would be nice to have each sheet show the
same REV letter instead of Sheet2, Sheet3, Sheet4, etc. say "See Sheet 1".

I've tried to copy and paste the first REV block onto Sheet2 or Sheet3, etc.
I can copy it, but it just doesn't want to paste.
Oh well, maybe in the next major release they'll get it right?!

Frustrated in the Brew City. I think it's time for a beer, even if it is
9:00am!

Richard

 

how could you be sure that you have the correct sheet 2? How would you
know you >don't have the current sheet one with the old sheet two?


you'd tell by looking at the Rev # in the lower right hand corner of your
title block. Every sheet needs to have the Rev#; but not every sheet needs
to (or should, IMHO) have a RevBlock

 

I don't disagree with you about what the shops need. Still people
stuggle with the "rev each sheet" scenario, which I don't think is
practical, because pdm apps and SW are geared around "the document"
being whatever is contained in an electronic file instead of whatever is
on a single sheet.

It's different from when you drew on a board, and the sheet of paper was
its own thing.

matt

 

I have to agree with Deb.

We use multiple sheet assembly drawings in our shop with some of the parts
detailed on say sheet 12, without a part number for the part, but rather
just giving the raw material number. That sheet is used on it's own by the
oerson in the shop who is making that part. If he doesn't have any other
sheets of the assembly drawing, how would he know what the revisions are for
that drawing? If they are on that sheet, he has the info he needs, right at
his hands, without having to run around looking for sheet 1 or where ever
the info is. He may not even know where to look for the info.

 

Every sheet needs to have the Rev#; but not every sheet needs

Exactly,
Amen

 

i'm so confused. can you define the function/purpose of a revision block in
your situation?

revision tables are often referred to as revision history. we use them to
cross reference our eco's which have the details on specific changes to that
drawing. it's been my experience that most shops will almost always do a
"physical compare" between drawings to find changes and not even rely on the
revision history block.

 

What if you want to have something self-contained? Put the assembly on
sht 1 and put parts on sht 2, sht 3, etc. Not something I would
normally do with our products, but maybe I would want to with a
fixture or gage made of multiple parts.

Anyone know the answer to this?

Brian

 

So you can manage the sheet revision in a drawer.

How are you going to manage the electronic file, though?

I'm not aware of any PDM systems that will allow per-page revs. If someone
knows of one, how does it work? If this could be shown to be practical in
a PDM app, I'd be willing to change my song, but until then, the only thing
that seems practical to me is reving the entire electronic document.

matt

 

There are a couple of things at play here. First, how does your company's
internal system work, second, how does the software work, and third, how do
you bridge any disconnects between them.

I'm coming from an assumption of using a PDM system, and it sounds like you
all may be coming from the assumption of using a drawer to manage paper.
Both ways work, but with PDM you would have to plan things a bit
differently.

Plus, it seems we may be talking about two different things. The original
conversation was about rev blocks on separate sheets, and I kind of
launched into talking about revision levels of individual sheets.

 

Hi Richard,

I've seen a lot of fireworks get a lunched on why one should not use
multiple sheet revison tables. I think that this really dovetails
nicely with the mono vs. poly detailing question that has been raised
lately.

If one uses poly detailing, then multiple revision sheets are very
practical and necessary. If not, then the need is not so strong, but
this is still a viable need.

Many people simply respond "just don't do it (no multi sheet revs)".
Nevertheless, I think that solidworks need to be practical about what
is done in the real world, where both styles are used. I firmly
believe that the multiple revision per sheet in a drawing set is not
intrinsically wrong, but it does put the burden on having a revison
table on the drawing somewhere (or even multiple sheet records in MRP
- yuck). I have seen this type of per sheet revision work for "real"
companies that manufacture things on the hunderds of thousands of
units, so the concept is viable.

If one wants the same rev table on every sheet with a simple
reduplicaton of the front sheet then the devils's advocate side of me
asks "why?". But of one wants to do sheet-based revs then viva la
difference. Personally, having given this alot of thought, I think
the rev-per sheet method is superior in some ways in that is allows
you to maintain only the sheet needed and not all of them, for example
a 30 page assembly doc with a "monolithic" revision that needs an
adjustment to sheet 4 would need to revison ALL sheets to make a
change to that one sheet - very time unfriendly.

Short answer: Multiple revs are not wrong, but has their downside
too. Solidworks owes us the ability to manage sheet level revisions
(using the table tool) if we choose to - differences of style
notwithstanding. That said, I personally would make a table on sheet
1 that bore this burden today, alternately, revert to the excel
revison table on a per sheet basis.

That's more than you asked for, but possibly helpful.

Regards,

SMA

 

If one wants the same rev table on every sheet with a simple

If you have a rev-per-sheet scheme as you describe above, how do you keep
track of what the proper rev level for a particular page should be? In
other words, how does the operator know that he's supposed to be using
sheet4, RevC?

It's easy for me to imagine getting yourself into a situation where the 30
page document you mention above has a different rev level for every page--do
you have an index or something that you also rev?

 

oh, what a headache. i need some asprin.

 

Sean:

I agree, but I guess I'm falling into my usual practical role not of "what
should be" but rather of "what is" and how to deal with what is.

I agree that changing a rev on a sheet of a 30 page drawing "should" not
force you to uprev the whole thing, but ... well, right now it does.
Particularly with PDM.

How are you handling this now? If I remember correctly, you are using the
"monolithic" approach because there is not another way aside from assigning
separate filenames for each sheet in ProductCenter.

Look at how PDM apps do configurations. It's a similar problem, and maybe
the solution could look similar (although the solution is kind of cheesy).
There is a separate PDM entity for each config, which is just a shortcut
back to the original doc with all the configs. Each config in name is
controlled, but not in a way that keeps you from changing other or all
configs. If you really want to manage configs properly, they are probably
best done as separate documents.

Conceptually, I accept what you say, but how do you make this happen? If
you were the software developer, how would you achieve the per-page revs in
PDM?

matt


(Sean-Michael Adams) wrote in

 

I agree that changing a rev on a sheet of a 30 page drawing "should" not

this seems flawed to me. but then again we're a mono company, so perhaps i
just don't understand the method to this madness.

 

It's easy for me to imagine getting yourself into a situation where the 30

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

 

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


(Sean-Michael Adams) wrote in