Any Lessons Learned to Implement Drawing Templates?

[jwagh]

There is a push to implement drawing templates in our company. Like everything else, there are lessons learned when doing something like this. I am hoping some of you can share your lessons that you've already learned. Some of the things already rattling inside my head are:

• Deciding what scenarios to use Templates for. Just for assemblies? Certain type of assemblies? Certain parts? What works the best, what doesn't?
• How specific do we get? Do we want to show all dimensions and have users go crazy trying to clean it up?
• How do we handle format sizes? If we have 12 formats and 10 scenarios for templates, does that mean I have to create 120 templates?
• Do you implement templates in conjunction with Mapkeys? What do you do with those Mapkeys? Does the Mapkeys deal with required naming conventions for simplified reps? Format sizes?
• Do you feel user's actually benefit from templates or is the limited functionality not much of a time saver?

Any help would be greatly appreciated!

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.

[dschenken]

On similar projects I first start by taking a sample of existing drawings and seeing what will be either frequent enough to save a lot of time or tough enough to relieve users from figuring out everything for (hopefully) rare jobs - or both.

I found it worthwhile to use mapkeys to create hydraulic tubing drawings for an entire project - about 150 drawings cranked through in about 45 minutes**. And the real beauty was that when the checker found something not to like I redid the mapkeys and ran all 150 again. Some time spent on the mapkey generator, and no sweating putting mouse to drawing making changes.

I'd look into using Excel to generate mapkeys for certain situations. The advantage is that Excel can be given lists of names and act appropriately no matter the names in the model - extract the names that you want; say by mapkey to a file, and the VBA can open the file and build the mapkey you want.

The big advantage to VBA is that eventually you will have a new version of Creo to support and if the VBA splits the mapkey creation into tiny, identifiable parts, you'll be able to capture replacements for the parts that work differently. At least for me, it is difficult to step through hundreds of steps recording a mapkey and then fit in the variables. Much easier to have small bits in subroutines that do tiny amounts, allowing easy debugging.

**Not to mislead - Excel calculated the bend tables, both LRA and XYZ, and created the tubing models, placed the bend symbols, all the bend indicator marks, and the primary view. There was too much variability to figure out the most pleasing arrangement so that was left to do by hand, but all the tedious, repetitive and error prone effort went through Excel->VBA->mapkey.

[jwagh]

Wow... very impressive. I've done a lot of Mapkey work, but not with VBA.

[dschenken]

It's just a bunch of Print statements to spit out he boilerplate and some variable dropped in as required. The toughest part is that it is very easy to forget steps in the planning stages that are very familiar. The second toughest is to make sure that nothing depends on the current state of the process - Creo 'remembers' things in a session, that will be different at the next session. Fail to force them to what they need to be and it won't work right.

[huggre]

David

Creating Creo mapkeys using Excel VBA sounds to me like beating around the bush.

Why not use the Creo VB API and do the automation directly inside Creo?

[dschenken]

Two reasons.

1) The VB interface doesn't support creating features, for example.

2) I don't care to learn yet another interface. I tried the C interface and found that wanting. The WebLink interface was OK but limited in its functionality. With the mapkey/trailfile method I can do anything any user can to create or modify things subject to cleverness. I'd use AutoIt, but most companies don't like even free software they didn't decide on. With VBA I am not limited to Creo.

[jwagh]

David,

I am unfamiliar with the VBA mapkey integration you are talking about. Do you have an example you can share?

Thank you!

[TomD.inPDX]

As for templates, I shy away from them but only because my client base forces me to be very versatile and allow for quick setups.

In this case, K.I.S.S. applies.

In my corporate years, "templates" were the system's default new parts.  Drawing formats were handed down and simple parameter loaded pages.

A simple sheet 1 and continuation sheet formats.  Typically what drove the documents was a series of parameters that were entered by any means.

In Creo, having a template simply to maintain parameters is certainly worthwhile but importing a text file is just as simple.  Someone would ultimately create a simple data generation app (in BASIC no less) that feeds the CAD system with a usable UI.  The only other thing Creo needs is the additional true ISO views.

If you make templates, start with a clean empty part.  Creo 2 M020 had a bug that showed the full history in the default Creo templates.  ...It wasn't pretty!

[James62]

Make sure you figure out how to generate the templates automatically. 120 templates seems like a huge maintenance burden in case there will be any change requested.

I do what David describes above with Autohotkey scripts. Autohotkey can read Excel files, stack up and generate on-demand mapkeys or trail files.

I recommend keeping all the small chunks of mapkeys and trail files outside of the code of the script, inside of small *.pro files that are easily maintainable. A good syntax highlighter always helps.

[jstone-2]

Joseph Wagh wrote:

There is a push to implement drawing templates in our company. Like everything else, there are lessons learned when doing something like this. I am hoping some of you can share your lessons that you've already learned. Some of the things already rattling inside my head are:

• Deciding what scenarios to use Templates for. Just for assemblies? Certain type of assemblies? Certain parts? What works the best, what doesn't?
• How specific do we get? Do we want to show all dimensions and have users go crazy trying to clean it up?
• How do we handle format sizes? If we have 12 formats and 10 scenarios for templates, does that mean I have to create 120 templates?
• Do you implement templates in conjunction with Mapkeys? What do you do with those Mapkeys? Does the Mapkeys deal with required naming conventions for simplified reps? Format sizes?
• Do you feel user's actually benefit from templates or is the limited functionality not much of a time saver?

Any help would be greatly appreciated!

You don't have to create 120 drawing templates, and probably don't want to maintain them either, as James mentioned. My company has about 500 active Creo users throughout 50-60 groups, each with their own set of custom drawing requirements, product standards, and list of demands. Their solution, met with much resistance, was to use a single drawing format containing a "common title block", with the only variation being specific tolerance tables for each group. I set up drawing templates in my group to help simplify (force update) our transition to new title blocks, since engineers are SO willing to accept change...The templates include standard notes, title block, tolerance tables, and embedded symbols, as well as limit the number of options to choose from in the start model directory. I only included A, B, C, & D size formats for my group because that's all we need. No views or dimensions because our drawings are typically new designs and not repetitive. The templates originally included our standard drawing formats, but we found that the formats remained static when inserted this way, and wouldn't update when they were revised by the CAD admins. Instead, we load the standard "controlled" formats and specific tables for various scenarios using nested mapkeys, which are incorporated into menu buttons within a custom group in the ribbon menu. 

All you really need is the 12 formats if you are willing to create nested mapkeys for title block/tolerance table placement by coordinates. For example, a mapkey "WD" will replace the existing format and all tables with the new "D" size format, then insert the proper tables using coordinate placement, import the DTL file, and insert any standard symbols. Each nested maypkey can be used individually, and used to call on any combination needed.

Assembly format size A-D, location grid, tolerance table, bom table, for example:

mapkey dfa @MAPKEY_LABELFormat: Assembly: A;%fa;%fga;%tbla;%boma;

mapkey dfb @MAPKEY_LABELFormat: Assembly: B;%fb;%fgb;%tblb;%bomb;

mapkey dfc @MAPKEY_LABELFormat: Assembly: C;%fc;%fgc;%tblc;%bomc;

mapkey dfd @MAPKEY_LABELFormat: Assembly: D;%fd;%fgd;%tbld;%bomd;

You don't necessarily need to use drawing templates to "save time" unless your products only vary dimensionally and maintain similar drawing views and dimension schemes. The objective in my case was drawing consistency, and minimizing confusion and resistance to change, without requiring any programming knowledge or an act of congress to approve some CAD customization.

Be careful using mapkeys to replace assembly formats with BOMs - you don't want to wipe out the repeat region balloons on a large assembly by automating this.

Also, embed notes into symbols in order to place using mapkeys.

Not sure on simplified rep naming, our drawings pull names from PDM Link/Windchill parameters

[lhoogeveen]

We've implemented Drawing Templates to a good degree of success. My vote would be for keeping trying to keep the number of templates and formats down to as few as possible and then leverage things like mapkeys for things like adding standard notes or tables that are not common to most (all?) of your drawings. We were able able to standardize down to just one drawing format size. This has several advantages like reducing number of active Formats, Templates, and mapkeys can be keyed to exact drawing positions to drop in a table. Users may gripe at first at having one format size but they can get a better and simpler tool set in the long run. You may not have that option but I thought I'd suggest it. We didn't create separate ones for parts versus assemblies and we don't show dimensions by default.

Overall, I found our new Template implementation to work a lot better for us than than our old poorly implemented Format setup. Sounds like some of the other guys here have a decent Format based implementation. You mileage may vary but the main thing to plan it out and create some tools (mapkeys) to complement each solution.

Template Pros:

• Template Parameters used inside the body of the drawing Format don't 'flash/prompt use to fill in' when creating new drawings from Templates like they do with Formats.
• Templates allow Drawing Parameters and Drawing Programs to be set ahead of time unlike Formats. We use a description parameter and I like having this parameter created beforehand and linked to a table in the in the drawing. If you wanted, you could also link this description to your CAD part or assembly description via the Drawing program. Both could be done after the fact with mapkeys too.
• Templates have way more Drawing Options to be able to set. We have Metric and Imperial drawings and turning on things like Dual Dimensions was a headache because when using Formats these were all driven from the drawing_setup_file config.pro option and we only have one corporate config.pro setup. I also created mapkeys to turn dual dimensions on and off quickly with all the correct settings.
• Templates can populate views and projection views automatically with specific view settings. Saves time for user and more consistency. These views also seem to auto adjust the drawing sheet scale to some degree based on the size of the if the scale wasn't hard defined into the view - not perfect but better than nothing. Views that are missing from the part error out and can get deleted. Could be done with mapkeys if desired but users would have to pick the location for the views.
• Templates allow you to use parameters like PTC_WM_VERSION:D in the body of your drawing to dynamically follow the Windchill Rev of the new drawing when using Templates.
• You can create multiple Templates that reference the same drawing format if you have different tables or views to add. We leveraged this to have tables that only show up on the first sheet of a drawing (e.g. Rev block) be in the Template  and kept those out of the Format so when you add a new sheet, you don't have to delete those tables.
• You could create multi sheet Template drawings if needed. We don't but it's possible.
• If you're sharing this with your group/company, add your templates to the start_model_directory location you've set in your config. As long as the templates aren't in sub folder, they should show up in the new drawing dialogue menu for Templates. I would keep your templates/formats and folder in a locked location. Does anyone know how to make the 'Use Template' be selected by default to remind people to use Templates instead of Formats?

         

• Like parts and assemblies, you can also set a default template to be used using the template_drawing config setting.
• You can also create Templates without Formats to make things like DXF creation templates. Just make sure the views all have a scale of 1.000. We combine this with mapkeys to make DXF's as needed.

Template Cons:

• I haven't figured out how to create a drawing using a Drawing Template when there is no CAD. Sometimes we have a need for a drawing that has no associated CAD and we have to do a work around. I may have to make a mapkey for this situation or let users build their drawing from the Format. This isn't all the common for us. Does anyone know if this is possible?

Other comments about Formats:

• Format Text, lines, and symbols in the body of the Format are dynamically populated to every drawing that uses them. Keep this in mind for things like company logos that have a habit of changing.
• Format Tables are copied and do not dynamically populate to every drawing.
• Formats more or less last forever as every drawing that has ever used that Format will need it in the future where as Templates can created/changed/deleted what ever situation you need as they'll only affect new drawings. I recommend keeping the number of Formats to a minimum.