Skip to main content

Someone wanted to learn this too, so Grasp built them a personal learning path.

You can keep exploring this one or create your own

Engineering File Organization and Revision Control

Hello again. Last lesson, you compared your computer and software access with the requirements for CAD and PLC practice. Whether you work locally or on an approved training computer, you will soon have drawings, I/O lists, and PLC project files to keep together. A useful file system lets you answer three questions quickly: Which project is this? Which document is this? Which version should I use?

This lesson closes the first module by building a practical naming, revision, and backup routine. Allow about 35–40 minutes, including the short video, two readings, and time to sketch a folder structure you can use later.


Give every document a stable identity

A filename such as motor drawing final new.dwg describes the author's intention, but it does not reliably identify a drawing. Someone else may create another “final,” or the motor project may contain several different drawings. A drawing number solves a different problem from a descriptive title: it gives one drawing an identifier that remains stable as its contents change.

Watch this short explanation of why numbering belongs to a wider document-control process. You need the principle, not the video's elaborate corporate numbering example.

What is Document Control Numbering?

Watch “What is Document Control Numbering?” from Technical Writer HQ for its distinction between identifying a document and tracking its versions.

Watch document numbering for the purpose of a numbering framework. Then watch version tracking for why an identifier alone does not tell you which copy is current or approved.

There is no single filename pattern required for every engineering job. The construction example below packs several agreed project fields into one name; a small control-panel training project needs fewer fields. The important feature is that each field has a defined meaning and everyone on the project uses it consistently.

A construction-file example showing separate fields for project, originator, location, document type, role, document number, purpose, revision, work-in-progress number, and file type. Its codes illustrate a project-specific convention, not a required format for control-panel drawings.

For this course, consider a practice convention for a small motor-panel project named MTR01. Give the project a short, stable code, then reserve distinct drawing numbers:

Stable identifier Document title
MTR01_E101 Single-line diagram
MTR01_E102 24 V control schematic
MTR01_E103 Terminal plan
MTR01_E104 Panel layout

Here, MTR01 identifies the project, while E102 identifies one drawing within that project. Changing a contact or adding a note to the control schematic does not make it a new E105 drawing; it makes a new revision of E102. Conversely, a new terminal plan should not reuse E102 merely because it belongs to the same panel.

A larger organization may assign drawing numbers centrally or require different fields. NASA Langley’s procedure is one example of a formal system: its facility convention combines a location or asset identifier, system type, drawing type, drawing number, and sheet identifier. Read it to see how a real convention defines each field—not to adopt NASA’s codes for your practice project.

Subject: Engineering Drawing and Document Requirements

Read Appendix A of NASA Langley’s “Engineering Drawing and Document Requirements” to see how an organization turns project attributes into distinct filenames.

In “Appendix A: Facility Configuration Management Drawing and Document File Naming Convention,” find “DRAWING FILE NAMING CONVENTION” on pp. 23–24. Read from the drawing convention, including its examples and field descriptions. Notice which fields identify what the drawing is; do not treat these facility-specific codes as a universal standard.

Agree the convention before generating many files. Record what each prefix means, how numbers are assigned, and whether your workplace uses revision letters, numbers, or a document-management system. For independent practice, a short note in the project folder is enough.


Distinguish a revision from a working save

Now add a second piece of information: revision. The drawing number stays MTR01_E102; its revision tells you which formally identified state of that drawing you are looking at. For example, R00 might be its first issued practice revision and R01 its next. Those meanings are choices for this example, not universal engineering rules.

Before an issue, you may save many working changes. They do not each need to become an issued revision. Keep working material visibly separate, such as MTR01_E102_DRAFT_01.dwg in a Working folder. When you decide to issue a practice copy, check it and save an identified issue such as MTR01_E102_R00.dwg. Label it practice issue, not “approved for construction”: a filename cannot grant an approval that has not occurred.

Read the following article for a compact example of filename revisions, title-block revisions, and a change log. Its REV001 scheme is one possible convention. When working in a managed CAD or PLC project, follow that software’s and your organization's procedures rather than renaming linked project files individually in File Explorer.

Drawing Revision File Naming Best Practices for Engineers

Read Industrial Monitor Direct’s guide for its distinction between the revision visible on a drawing and the revision visible in a filename, then examine its example folder and change-log arrangements.

Under “Title Block vs. Filename: What's Required,” read the revision explanation. Under “Recommended File Naming Convention,” read the naming examples. Continue through “Project Folder Structure,” from the folder example, and in “Revision Notes Documentation” read the change-log fields. Focus on traceability rather than copying its precise numbering scheme.

A drawing that says R01 in its title block but R00 in its filename creates an avoidable doubt. For an issued drawing, make the title block, filename or document-system record, and exported PDF agree. Record what changed as well as the revision identifier. A short log entry might read:

E102 | R01 | 2026-04-10 | Added contactor feedback indication | Practice revision

The log identifies the change; it does not replace the drawing. In workplace projects, it may also need an author, reviewer, approval, or change-request reference according to local rules. Keep the previous issued R00 available but clearly superseded so nobody mistakes it for the active issue.


Make the active set easy to find

Folders provide context that filenames alone cannot. One workable training layout is:

MTR01_MotorPanel/
├── 00_ProjectRules/
│   └── NamingAndRevisionRules.txt
├── 10_Working/
│   ├── Drawings/
│   └── PLC/
├── 20_IssuedPractice/
│   ├── Drawings_Native/
│   ├── Drawings_PDF/
│   └── IssueIndex.txt
└── 30_Superseded/

Working is where you edit; IssuedPractice is the clearly identified set you would show a reviewer; Superseded retains earlier issues. An issue index lists the revision of each included document. That matters because revisions need not advance together: after a control-schematic change, E102 might be at R01 while E101, E103, and E104 remain at R00. Do not silently rename all four drawings R01.

Keep both an editable native file and a PDF representation when issuing drawings: the native file supports later changes, while the PDF lets others view the particular issue without CAD. NASA Langley’s document-control procedure describes this pairing for its released engineering drawings.

Subject: Engineering Drawing and Document Requirements

Return to NASA Langley’s procedure for the reason to retain an editable drawing and a viewable representation of the same issue.

In Chapter 5, “Non-Facility Drawing and Documentation Control,” find subsection “5.3 Drawing Document Media” on p. 20. Read from native files and PDFs. This is NASA’s controlled-release procedure; apply the underlying distinction to your training folder without implying your files have NASA approval.

Treat CAD and PLC project folders as projects, not bags of independently movable files. Drawings may reference other drawings or project settings; PLC software may maintain related files internally. If a tool provides a project manager or archive command, use its documented method to copy or package the whole project, then check that the copy opens. Naming rules should make work traceable, not break its links.


Back up for recovery, not just for neatness

A superseded revision and a backup have different jobs. The superseded revision answers, “What did we issue before this change?” A backup answers, “Can we recover the work if a drive fails, a file is deleted, or the working project is damaged?” Keeping R00 and R01 on the same laptop does not protect either from losing that laptop.

For practice, choose a second, permitted location—such as an approved external drive or an approved organizational backup service—and copy the entire project, including its rules, logs, native files, and PDFs. Make a recovery copy at least at the end of a substantial work session and before a major revision. Keep more than one dated copy so a damaged file is less likely to replace your only usable backup. Occasionally restore a copy to a separate test location and confirm that the drawings or project actually open. A copy you have never tried to restore is an unverified backup.

On a workplace computer, follow the organization's storage, access, retention, and backup policy. Do not put company drawings or PLC projects in a personal cloud account simply because it is convenient. Also remember that sync is not necessarily backup: deletion or corruption can sync to another device. Check whether your chosen service retains recoverable earlier versions.

If you have a practice computer available, spend a few minutes creating the MTR01_MotorPanel folders and a short NamingAndRevisionRules.txt. Write down your project code, drawing-number ranges, the meaning of DRAFT and R00, where the active issue lives, and where a permitted separate backup will be kept. You can do this before installing any CAD or PLC software.


Conclusion

A dependable engineering file system separates document identity, revision, issue status, and recovery. Keep project and drawing identifiers stable; identify changes consistently in filenames or controlled records, title blocks, and a revision log; separate working files from issued and superseded copies; and verify that a backup can be restored.

You now have an organizational foundation for the drawings and PLC files you will create later. In the next module, you will begin 2D drafting by navigating AutoCAD and managing your view in model space.

Can't find a good explanation? Sign up and we'll make it for you

Sign up