Documenting within CNC

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

Admittedly, older CNCs do have memory constraints, so some programmers avoid doing too much documenting within programs if memory capacity is at a premium. Newer CNCs commonly have ample memory space, however, and programs can even be run from external memory like a flash drive or memory card, so the memory-constraint concern should no longer be an issue.

The person who inspired this column, W. Worthington Treasure of Bettendorf, Iowa, recently said, “If a CNC code is the highway, then comments are the signposts along the way.” I couldn’t agree more. The more interaction you expect people to have with your CNC programs, the more documentation you should include. Following are tips on when and what to document. 

• Document to boost productivity. There are at least two ways to improve productivity: 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 information regarding what the program is intended to do. This can result in catastrophe, since the setup person could easily run the wrong program. Headers, placed at the beginning of a program, can include program-identifying information like part number, part name, part revision number and operation number. With this information, setup people can confirm that the correct program is being run. 

Other helpful header information includes important dates, like the date of program creation and the date of the last program revision. Headers also should include the programmer’s name (or the name of the person responsible for the program when problems are encountered). 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-the-ordinary. It’s important to document times when a program will be doing something unusual. This information 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.

• Include setup information. While most programs are complicated enough to require separate setup instructions, a shop might also have simple jobs that don’t require much setup documentation at all. In these cases, the entire setup may be able to be explained within the program.

And even if a setup is complicated enough to require separate instructions, it may be helpful to also document certain setup-related information 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 instructions (or to search through the program) to determine which offsets must be changed to make a needed sizing adjustment.

• 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 appropriate 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 programmer, 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 appropriately placed message in the program have helped them avoid that mistake?