A new idea about operations manuals

By Jason Christopher, Liberty Precision Industries

For many machine designers, the sequence of activities that goes into one machine build typically applies to the next as well. There is specification development, hardware design, bill of material (BOM) development, rework of the hardware design and BOMs after the specification changes. Then there’s software, debug and startup. What then awaits is the dreaded writing of the operations and maintenance manuals. Ugh!

If you’re like me, writing the operations manual is a step you can do without. What’s worse, is that you suspect nobody reads the thing, so why even bother.

In reality however, ease of operation makes a tremendous difference to the end user. How difficult it is to run the equipment or recover from a fault condition has direct and significant correlation to OEE as well as your customer’s perception of how much value they receive from your company’s equipment.

Despite this, the gut feeling that nobody ever reads the user manual is pretty accurate—because nobody can find it when you ask if they have referred to it. Instead, the operator will struggle with the machine, complain to co-workers, and bad-mouth the equipment—when all they had to do was home the machine out and it would run just fine thereafter.

The answer isn’t to create a more dynamic operations manual, or one that is graphically intense to make it easier to understand. These things will make the manual better, but if nobody opens it in the first place, what’s the point?

Instead, I suggest you place the informational tools you have available to you right at their finger tips: on the operator interface. This can take the place of the operations manual and guide the operators out of trouble.

In many instances, there are several conditions that must be met before an operation can be performed. These conditions get collected into an “enable” line that must be high before allowing the operation to proceed. For example, to manually unclamp a spindle drawbar, you might require the following conditions to be met:

1. The spindle must be oriented,
2. AND, the set-up door must be open, 
3. AND the machine must be in manual mode

If the operator presses the drawbar-unclamp push button, whether hardwired or virtual, and any of the required conditions are not met, then a message can be displayed to inform the operator what conditions are missing. The same approach can be applied to startup sequences, manual operations, and fault recovery.

Thinking like the operator--not the designer--can pay huge dividends in the effectiveness of the message. Messages such as: “Analog Voltage From Tool Retainer Position Transducer Fails to Meet Acceptable Criteria,” typically will be less meaningful to the operator or even a technician than something like this: “TOOL SHORT CLAMP--CHECK X12 PROX.”
In addition, the added information in the second message—the address of the proximity sensor—makes it easy to locate in the electrical schematics.

This might seem a daunting task, but it can be a manageable part of the software development process. I try to discipline myself so that immediately following any sort of “enable” line, I automatically add the logic to inform the operator of missing conditions if they are attempting to initiate the programmed action. This helps keep the structure of my logic consistent, and ensures that I don’t neglect any of the conditions.

This approach won’t be a substitute for all aspects of a machine or process manual. Many of the necessary procedures to set up and/or maintain a piece of equipment are very involved, and require more than the 255 characters that your programming software allows for messages. These items need to be addressed in an offline manual in order to provide the forum and detail required. More detailed troubleshooting items also might need to be addressed elsewhere.

In the example above, an offline manual might be required if the solution to the stated fault is not readily apparent. However, these more detailed items encroach more into the maintenance manual than the operations manual. Nevertheless, don’t hesitate to include maintenance-type activities into the messages when feasible.

If you’re anything like me, you’d probably prefer to add messages to your control software than to painstakingly write a Word document detailing the same items. Not only does the control software provide for a more immediate, more useful feedback that the operator will actually get to see, but the returns for the time spent are significantly higher for you and your company.

---

Jason Christopher is a controls designer for Liberty Precision Industries, Rochester, New York, an integrator of high-volume manufacturing cells and systems.