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 ------------------------------------------------------------------------
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.
** 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.