Revision Table On Drawings

[lococnc]

Has anyone done anything clever on revision tables shown on a drawing?

I would like the current revision to be driven by parameters, that's easy
enough...

But to preserve previous revision information on the table you would have
to first copy the values to text in another table row and then edit the
parameters.

Any off-the-shelf functionality to do this or something similar?

Does everyone else just fill in table cells with text?

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[RandyJones]

On 09/06/12 09:53, Michael Gamber wrote:
> Has anyone done anything clever on revision tables shown on a drawing?
>
> I would like the current revision to be driven by parameters, that's easy enough...
>
> But to preserve previous revision information on the table you would have to first copy the values
> to text in another table row and then edit the parameters.
>
> Any off-the-shelf functionality to do this or something similar?
>
> Does everyone else just fill in table cells with text?

We use a note parameter (from the model). For non family tabled objects this works okay. For family
tabled objects it adds some complexity.

The issue with family tables is that anytime you modify a note you are modifying the entire family
table and not just the instance in question. What PTC needs is a multi-line text parameter that
works just like the current string parameter works.

Note parameters currently reference a note (by number). The actual text is contained in the note and
not in the note parameter. The notes can not be added to a family table.

So if you have 5 instances in your family table you have these steps:

1. add 5 notes to the generic
2. create a note parameter ie revisions.
3. add the revisions parameter to the family table
4. for each instance change the value of the revisions parameter to point to a different note
5. back in the generic edit each note and add the revision information as appropriate

When you add an instance you have to add another note to the generic which modifies the entire
family table.
When you revise an instance you have to modify the appropriate note which modifies the entire family
table.

>
> -----End Original Message-----


--
------------------------------------------------------------------------
Randy Jones
Systems Administrator
Great Plains Mfg., Inc.
1525 E North St
PO Box 5060
Salina, KS USA 67401
email: -
Phone: 785-823-3276
Fax: 785-667-2695
------------------------------------------------------------------------

[kimndave9]

A fairly decent solution would be to have parameter arrays that could be
indexed, but that's on PTC to come up with.

A modern solution would be to have no historical information on the
drawing itself and depend on the PDM system to handle that. I've seen
some small drawings where the change block has enough information to
un-draw the changes (Zone B2 2.550 dimension was 2.540, for example)

All the important information about the management and control of the
drawing should be in the PDM system and only enough information on the
drawing to see if it's a match to what's in the PDM system. The PDM
system itself should annotate anything that is copied out with revision
and sign-off status information, and also who copied it out and when.

Taken to the extreme - Why are there signature blocks on CAD drawings
when there is no realistic way to sign a CAD file? Even if it is opened
by each signer, they are modifying the drawing from what the previous
signer saw, in a way that is not limited to adding the signature. With
the PDM system, the signed-off drawing should be the same for all of the
signers.

Back to the revision tables - sometimes there is interest in having
individual sheet revisions. Typically all sheets of a drawing are in a
single file, and you can't change any one sheet without changing the
whole file, so why complicate life? I suppose one could make a separate
file for each sheet, but that would make sheet numbering an additional
headache. It's one thing to deal with a drawing where a sheet may or may
not have been altered, but nothing like the joy of trying to tell
someone which of the three sheet 5s need to have their sheet number changed.

To speed access to history information, I had a semi PDM system (Wiki
based) with individual drawing pages that included copies of all
revisions and all changes and included detailed descriptions of what
changed and why it changed. It linked to any related analyses or other
support material. Often I used Photoshop to overlay the old version with
the change or the new version**. This check file was also attached. It
wasn't a workflow management system that controlled the release status
of drawings, but it nicely covered the info most people want when they
are curious about how a drawing/design got that way.


Dave S.

** Why Photoshop? Because it can (manually) handle views and notes and
balloons that are moved either on the same sheet or to another sheet,
and re-flow or re-pagination of text, and could compare scanned versions
of drawings with re-drawn plotted versions. The overlay file could keep
the entire check markup for all the versions/revisions of a drawing. In
Photoshop Elements it was entirely manual, but in Photoshop, a lot of
the overlay work was automated. I tried GIMP, but at the time it was
sluggish for certain selection processes. It might be faster or newer
hardware might be good enough.