Engineering / Computers / Part 8 of 9
Drawing Automation
Drawings are where an engineering office spends its time and where its errors become expensive. They are also highly rule-governed, which makes them unusually good candidates for automation — provided the tool understands one structural quirk about how views are organised on a sheet.
- Part 8 · Applied
- Templates & sheet sizes
- Sheet is the first view
- Print control
KL-ENG-COMP-1508 · KEVOS® Knowledge Library · Australian English
Three capabilities cover most drawing automation: creating a drawing and populating it with standard views, walking the sheets and views to audit or modify them, and printing with real control over what goes where. Each is straightforward once the object structure is clear.
01What is worth automating in drawings
Creating the drawing
New drawing from the correct template with standard views placed, for every model in a folder. Removes both the keystrokes and the risk of the wrong template.
Auditing sheets
Which drawings have views with no model, incorrect scales, missing sheets, or references to files that have moved.
Batch output
Every sheet to PDF or DXF under a naming rule, or every drawing in a release printed to a defined device. Covered in Part 3 for export; printing is below.
Title-block population
Usually better solved by linking title-block fields to custom properties (Part 7) than by writing text through the API.
Dimensioning and annotation
Placement is a judgement about legibility. Automated dimensioning generally produces drawings that need rearranging by hand.
One-off layouts
Anything drawn once is faster drawn by hand.
02Creating a drawing from a template
A drawing is created like any other document, from a template — but unlike parts and assemblies, the paper size and sheet dimension arguments matter.
Reading the size back from the template rather than passing constants is what makes the tool work across a company that uses more than one sheet size. The call reports the paper-size enumerator together with the sheet width and height; where the size is a custom one, the dimensions carry the information the enumerator cannot.
An absolute template path embedded in a tool is the most common reason it works for its author and nobody else. Read the configured template folder from user preferences, or take the path as a setting stored beside the tool.
03Placing standard views
A single call places a standard set of views of a named model onto the drawing, in first-angle or third-angle arrangement.
IDrawingDoc swDrawing = (IDrawingDoc)swModel;
bool placed = swDrawing.Create3rdAngleViews2(modelPath);
if (!placed)
{
log.Add("no views placed for " + modelPath);
return;
}The choice between first and third angle is a drawing-standard decision, not a preference. Where a business works to a single standard, fix it in the tool and say so in the tool's documentation. Where it works to more than one — different customers, different territories — make it an input and record which was used on each drawing.
A false return means no views were placed — a missing model, a path that has moved, or a model that cannot be resolved. Continuing past it produces an empty drawing that looks like a template problem. Test the return, log the model path, and stop.
04Walking sheets and views
This is where the structural quirk lives, and it is the single most useful thing to know about drawing automation.
Asking a drawing for its first view does not return the first drawing view. It returns an object representing the sheet itself. The actual views are that object's successors. A loop that starts processing at the first returned object will report one view too many, and the extra one will have properties that make no sense for a view.
foreach (string sheetName in (string[])swDrawing.GetSheetNames())
{
swDrawing.ActivateSheet(sheetName);
// The first object returned represents the sheet; step past it.
IView view = (IView)swDrawing.GetFirstView();
view = (IView)view.GetNextView();
int viewCount = 0;
while (view != null)
{
viewCount++;
Record(sheetName, view.GetName2(), view.Type, view.ScaleRatio);
view = (IView)view.GetNextView();
}
log.Add($"{sheetName}: {viewCount} views");
}| Check | Finds |
|---|---|
| View count per sheet | Empty sheets, and sheets carrying far more than the standard expects |
| Referenced model of each view | Views pointing at files that have moved, been renamed or been superseded |
| Scale of each view | Scales outside the permitted set, and detail views inconsistent with their parent |
| View type | Section and detail views that have lost their parent |
| Sheet count and names | Naming that departs from the convention downstream systems expect |
05Printing with control
There are two routes. One is a single call with no options; the other gives you everything a print dialogue would.
The simple route
A direct print call sends the document to the default device with current settings. It is one line, and it is genuinely useful for "print what is open". It offers no control over range, copies, collation or device.
The controlled route
The document extension provides a print call taking a page range, a copy count, a collation flag, a named printer and an optional output file. This is the one to use for anything unattended.
The page range argument
Ranges are supplied as an array of integers read in pairs, each pair being a start and an end. A pair of one and five prints five pages; adding a further pair of seven and eight prints two more. A single page is expressed as a pair with the same value twice — supplying an odd number of entries is a defect that produces unpredictable output.
Collation
With collation on, multiple copies emerge as complete sets. With it off, all copies of each page emerge together. For a multi-sheet drawing issued to several recipients, collation on is almost always what is wanted, and it is worth setting explicitly rather than relying on a device default.
The printer name
The printer is identified by its exact name as the operating system knows it. Supplying nothing uses the default device. Two consequences follow: a tool that hard-codes a printer name will fail on any machine where that device is named differently, and a tool that relies on the default will print wherever the user last printed. Present the list of installed devices and let the user choose, storing the choice.
The output-file argument writes printer data to a file, not a portable document. To produce a PDF, export using the save operation with a PDF extension as in Part 3, or print to a device that is itself a PDF writer. Confusing the two produces files nobody can open and a difficult diagnosis.
06Export or print
| Requirement | Use | Why |
|---|---|---|
| Issue a drawing pack electronically | Export to PDF | Reproducible, archivable, and independent of any installed device |
| Feed a cutting or nesting system | Export to DXF | Geometry is required, not a rendering. See Part 3 |
| Physical copies for a workshop | Controlled print | Range, copies, collation and device all matter |
| Print what is on screen | Direct print | One line; no configuration to get wrong |
| Archive of what was issued | Export, and keep the file | A printed sheet leaves no record; an exported file is the record |
Where output feeds manufacturing, the tool should record what it produced: source file, revision, configuration, sheet, timestamp and destination. That log is the evidence connecting a physical part to the drawing that authorised it, and it costs a few lines to write while the tool is running anyway.