cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

The PTC Community email address has changed to community-mailer@ptc.com. Learn more.

Drawing Table of Contents

Drawing Table of Contents

1. Describe your environment: What is your industry? What is your role in your organization? Describe your stakeholders.
Design systems / assemblies to address client challenges - from initial concept to delivering final product.


2. What version of Creo Parametric are you currently running?

8


3. Describe the problem you are trying to solve. Please include detailed documentation such as screenshots, images or video.

Drawings with multiple sheets need a Table of Contents (TOC) - just like any other multi-page document.   Report repeat region parameters would need to be established for just this purpose.  A Table of Contents should be just as easy to implement as a Bill of Materials.  A parametric Table of Contents would update any time a sheet is added, or is re-named or moved in sequence.


4. What is the use case for your organization?

As much as I would like to fully implement Model Based Definition, I've never had a client (in over 30 years) request a project with anything short of a full set of 2D drawings.  For me, multi-sheet drawing packages with a necessity for a Table-Of-Contents will be around indefinitely.  Addressing a variety of situations, my average drawing packages vary from 10 to 50 sheets (usually of a custom assembly and the related custom subassemblies and custom parts).  I have to set up a table and manually fill in the cells.  When (every time) sheets are deleted, changed, added... I have to manually edit the TOC table.  In a simple TOC I almost always use the sheet number and sheet name.  On authoritative drawings, the TOC includes the sheet edit date and revision mark, and sometimes a part number and part name.  All of this could be "parametric". 

 

So, at the very least, a simple TOC would only need to be able to list the sheets (using the sheet numbers as the table index) in a drawing and the drawing sheet name.  With some judicious sheet naming, this makes an effective tool to locate specific details of subassemblies or parts without having to shuffle through the entire Contents of a drawing package. A report index by sheet number, and report parameter of the respective sheet name would be necessary.  Selecting either sheet number or sheet name would 'hyperlink' to the sheet just like the sheet tabs (and be available as 'bookmarks' in an exported drawing).

 

The implementation of 'edit date', 'revision mark', etc...would mean being able to assign parameters (in addition to the existing sheet name) to each sheet (much like each part having its own parameters in an assembly), and making those available as report parameters.  A multi-sheet drawing can be thought of as an assembly, and the sheets are either sub-assemblies or parts of the assembly.  Additionally, views on each sheet can be thought of as specific features of each assembly or part (just like in the model tree). If sheet parameters could be assigned and made available in table reports (just like parameters of assemblies and parts), this would be an intuitive implementation.  In addition to the preview that the drawing sheet tabs currently provide, they could also provide a toggle to include the sheet in the TOC, and there could be an additional ‘drop-down’ to assign and edit parameters for the sheet (and/or these items could be incorporated into view properties). A parameter would be created in the drawing (or present in the drawing template), that would be designated as unique to each drawing sheet - much like creating a parameter that is included in a part or assembly family table.

 

In addition, the generation of new view names should be able to be ‘formatted’ to incorporate the view’s model. Instead of ‘new_view_nn’, it should be ‘prt_name’ or ‘asm_name’ and projected ‘prt_name_right’ and ‘asm_name_right’.  Auxiliary views are provided a certain amount of view name formatting in ‘detail options’ with aux_view_note_format (‘VIEW %viewname-%viewname’ by default). New views should have a format option in ‘detail options’ – such as ‘%model_type “-“%model_name’ or ‘%model_parameter“ - “%model_type’.

This would make much more sense in terms of ‘bookmarks’. If you diligently re-name your views, this is potentially how they end up anyway…it’s just a lot of work that could be ‘parametric’.




5. What business value would your suggestion represent for your organization?
Hours per project saved in the proper and adequate documentation of engineering documents.

2 Comments
olivierlp
Community Manager

Hello, 

Thank you for your idea and the information you provided.

olivierlp
Community Manager
Status changed to: Acknowledged