Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
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:
Any help would be greatly appreciated!
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.
Wow... very impressive. I've done a lot of Mapkey work, but not with VBA.
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.
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?
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.
David,
I am unfamiliar with the VBA mapkey integration you are talking about. Do you have an example you can share?
Thank you!
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!
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.
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
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 Cons:
Other comments about Formats: