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

snipped-for-privacy@liquidschwarz.com (TheTick) wrote in news: snipped-for-privacy@posting.google.com:

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

"Richard Charney" wrote

I'm having the same issues. Contacted my VAR & they informed me that is the way it is supposed to work. I swear that when we made the decision to switch to SW's Rev. Table, I tested the functionality and it brought the column headers into the sheet just fine. VAR says other customers say that too, but so far nobody has been able to show proof of this. Additionally, I am unable to insert a rev. symbol without a dash for the revision (instead of a letter) without making the sheet two Rev. table look pretty much like sheet one. VAR is contacting SW and is supposed to get back with me.

Deb

"TheTick" wrote

Theoretically that's true, but if our QS9000 auditor came in here and saw a two sheet process print with a rev block on page two that says 'refer to sheet one', we'd have a major infraction. Say you update your print to rev. B. Given the current way sheet two's rev block comes in, 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?

I'll agree that it's a very bad idea to have different revs on different sheets, but they could at least force the exact same rev table to each sheet. The current way SW handles this makes it impossible for us to comply with QS9000, making the functionality useless to us.

Deb

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

Richard

"matt" wrote

A time when a physical piece of paper was a document? I personally don't know of any job shops that have a computer capable of displaying prints at each machine. So, for the vast majority of machinists paper is all they know. There has to be some way of ensuring that each page of the multiple sheet print is the correct one. Most machinists, production workers, and others still have to have a paper document to refer to. Every machine operator in this plant has a control plans, tooling layouts, and a process prints sitting on their bench that they have to refer to. The documents have to be readily available to them. Maybe some industries or small job shops will be able to operate just fine without paper, but it'll be a long, long time before the automotive or medical industries will be able to.

Deb

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

"Deb Dowding" wrote in news: snipped-for-privacy@corp.supernews.com:

But, once the electronic document is printed, each sheet _is_ it's own thing.

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.

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

snipped-for-privacy@yahoo.com (Brian S) wrote in news: snipped-for-privacy@posting.google.com:

The entire drawing set gets the same revision level. The revision level appears in the title block. A revision block appears on the sheet where the revision is made, and contains revision notes for revisions of that sheet. The problem is that you end up with parts getting a revision with no actual changes. This means that several dozen sheets need to be replaced with every revision. It's not efficient, but that's how that system works.

The revision tables work with this. Insert the revision table, then double click in the cell with the "-" and type in the letter or number for the correct revision level. Do the same for the cell that says "see sheet 1".

"Deb Dowding" wrote in news: snipped-for-privacy@corp.supernews.com:

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.

"Richard Charney" wrote in news:fbNnc.5602$ snipped-for-privacy@newssvr28.news.prodigy.com:

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

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

Regards,

SMA

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

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