Show Menu

Documenting within CNC programs Cheat Sheet (DRAFT) by [deleted]

This is a draft cheat sheet. It is a work in progress and is not finished yet.


Almost all modern CNCs (Computer numerical control) provide the ability to include messages and comments within their programs. Most use parent­heses for this purpose, and any messages placed in parent­heses will appear on the CNC’s display screen when the program is viewed.

Newer CNCs commonly have ample memory space and programs can even be run from external memory like a flash drive or memory card, so the memory­-co­nst­raint concern should no longer be an issue.

The person who inspired this column, W. Worthi­ngton Treasure of Betten­dorf, Iowa, recently said, “If a CNC code is the highway, then comments are the signposts along the way.” The more intera­ction you expect people to have with your CNC programs, the more docume­ntation should be included. Following are tips on when and what to document.

Document to boost produc­tivity

There are at least two ways to improve produc­tivity: Raise the skill level of the people performing a task, or lower the skill level required to perform the task. Including messages within a CNC program will help with the latter, making it easier for operators to run the program. Every suggestion you provide will reduce the potential for mistakes, clarify a concern, explain what must be done or in some other way simplify the task of running a program.

Use program headers

I’ve seen too many CNC programs that contain no clarifying inform­ation regarding what the program is intended to do. This can result in catast­rophe, since the setup person could easily run the wrong program. Headers, placed at the beginning of a program, can include progra­m-i­den­tifying inform­ation like part number, part name, part revision number and operation number. With this inform­ation, setup people can confirm that the correct program is being run.

Other helpful header inform­ation includes important dates, like the date of program creation and the date of the last program revision. Headers also should include the progra­mmer’s name (or the name of the person respon­sible for the program when problems are encoun­tered). Even program execution time should be specified in the header so everyone can tell how long the program will take to run even when the job is not actually running. Anything that helps identify the program and track its use should be included in the program’s header.

Note the out-of­-th­e-o­rdinary

It’s important to document times when a program will be doing something unusual. This inform­ation could be included in the program header, but it must be obvious. Maybe most programs use but one offset per cutting tool, but for some reason this program uses two or more offsets for a given cutting tool. If the setup person is caught unaware, it’s likely a workpiece will be scrapped before he or she figures out what is wrong.

CNC G-code

Include setup inform­ation

While most programs are compli­cated enough to require separate setup instru­ctions, a shop might also have simple jobs that don’t require much setup docume­ntation at all. In these cases, the entire setup may be able to be explained within the program.

And even if a setup is compli­cated enough to require separate instru­ctions, it may be helpful to also document certain setup-­related inform­ation right in the program, such as cutting tool names, their station numbers, what workpiece attributes they machine and their related offsets. This will be especially helpful during the production run and will keep operators from having to reference separate instru­ctions (or to search through the program) to determine which offsets must be changed to make a needed sizing adjust­ment.

Consider every tool change

It’s also important to include a message that specifies the cutting tool name when tool changes are made. This is especially helpful if setup people and operators will be expected to rerun cutting tools, as is required for trial machining. With the tool names specified, these operators can confirm that they are rerunning the approp­riate ones.

And every program stop

If the programmer makes the program stop (with M00) for the purpose of having the operator complete a task such as clear chips, readjust clamps, turn the workpiece around in the chuck or the like, he or she should be sure to include a message near the M00 that tells the operator exactly what to do.

Document changes made after a dispute

As a progra­mmer, you may be told to make program changes with which, for one reason or another, you do not agree. Be sure to document the reason for the change in the program at the point at which it is made. Should issues arise at some later date, at least you will be able to explain why you made the change.

Help with error trapping

Certain mistakes can be made during the running of a program that messages could have helped avoid. Some have already been mentioned, such as when the program does something out of the ordinary, for example. Consider other times setup people and operators have made mistakes, perhaps with cutting tool placement, program zero assignment or when re-running cutting tools. Could an approp­riately placed message in the program have helped them avoid that mistake?