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 theres software, debug and startup. What then awaits is the dreaded writing of the operations and maintenance manuals. Ugh!
If youre like me, writing the operations manual is a step you can do without. Whats 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 customers perception of how much value they receive from your companys equipment.
Despite this, the gut feeling that nobody ever reads the user manual is pretty accuratebecause 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 equipmentwhen all they had to do was home the machine out and it would run just fine thereafter.
The answer isnt 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, whats 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:
- The spindle must be oriented,
- AND, the set-up door must be open,
- 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 messagethe address of the proximity sensormakes 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 dont neglect any of the conditions.
This approach wont 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, dont hesitate to include maintenance-type activities into the messages when feasible.
If youre anything like me, youd 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.