The importance of machine documentation

Automated machinery can be very complex and cost millions of dollars. When it breaks down seconds can count; lost production affects the bottom line and can lead to lost customers when deadlines aren’t met.

By Frank Lamb September 22, 2014

Automated machinery can be very complex and cost millions of dollars. When it breaks down seconds can count… lost production affects the bottom line and can lead to lost customers when deadlines aren’t met.

So why is machine documentation considered an afterthought? A necessary evil that is hurriedly thrown together at the end of a project or lost in a back room somewhere?

"Mastering the Machine" describes the process of concepting, procuring, designing, building and documenting a machine or system from the perspective of the machine builder. At the end of the document is a checklist with, believe it or not, 63 different documents generated in the process of building a custom automation system or machine. Some of these items don’t apply to every system and others may not be required by the end-user, but a lot of equipment purchasers don’t even know some of these documents exist.

For instance, during the design process items such as timing diagrams, I/O and HMI message lists and flowcharts are usually generated. These documents can be very useful to the end-user but are not usually included in the final documentation package. Since they don’t cost anything extra to create, the vendor may be easily persuaded to include them at the end of the project.

At a minimum, A BOM (Bill of Materials), recommended spare parts list, electrical schematics, mechanical tooling drawings, a maintenance and operations manual and documented software files for PLC and HMI should always be included. Most vendors supply these as standard practice.

The quality of these documents can vary widely and are not always checked carefully before the project is wrapped up. CAD drawings are usually generated before the machine is built and "red-lined" as assembly proceeds; these updates may not ever make it to the final documentation package.

With larger plants and bigger machine builders the process of checking off documentation is usually fairly complete. The only people who can determine whether software documentation is adequate are people who understand the software; this is not something a purchasing agent or buyer can evaluate. CAD drawings are also best evaluated by people who have the technical ability to do so. Larger manufacturers usually have engineers with experience in doing this.

A recent project of mine illustrates what can happen when documentation is not complete or a customer doesn’t understand the machinery. In this case the machine had been rebuilt by an integrator who changed the controls platform from Siemens to Allen-Bradley. Since they didn’t have the CAD drawings from the original machine, they simply wrote the changes on the paper copy of the schematics.

Unfortunately many of the changes weren’t captured. In addition, since the original documentation was in English and the integrator documented everything in Spanish, some of the names for new parts of the machine were difficult to decipher. The new program was also only partly documented so it took a while to figure out and re-comment the operation of the machine.

As my time on this machine came to a close and I had to catch a flight, the customer mentioned that he was having a hard time starting the machine. I only had an hour or so until I had to leave, but I went online with the program and checked out the status of some of my recently re-commented logic.

It was fairly easy to isolate a couple of contacts that needed to be closed for the machine to operate. One was labeled (in Spanish) "Pallet Obstructed Relay". We spent some time investigating the schematics and looking in the electrical enclosure but couldn’t determine what this might be. All sensors were pretty well accounted for and there didn’t seem to be any new relays in the enclosure, so the only option left was to trace the wire from the input card out to wherever the device was. As I left a technician was doing just that and had lots of jumbled wires pulled out of the wireway. He had a long evening in front of him.

In addition, the safety relays were showing an error on the 2 channel controller. This is usually caused when one channel doesn’t operate correctly. Again, the wiring had been updated but not documented in the drawings. This required more troubleshooting and wire-tracing.

Since most machinery is a very expensive investment anyway, why not ensure that the documentation is in order and complete ahead of time? It is important to state your documentation requirements during the initial quoting process. And then follow up to ensure that the vendor met the requirements.

Author Bio: Frank Lamb is founder and owner of Automation Consulting LLC and member of the Control Engineering editorial advisory board.