Machine maintenance

I spent 7 years in direct maintenance support working on machines from all over the world. I have been working in machine build for over 16 years with the last 6 years being clean sheet custom build. Rarely do we build the same machine twice. We also often support machines from other builders that will either no longer support their machine or the customer won't let them back in the door. Often, these machines were programmed with spaghetti code with no distinguishable sequence making troubleshooting difficult at best. I am well aware that bad code can make good mechanics run poorly but great code still won't make bad mechanics run well!

Learn GRAPHSET is a great idea (Goggle it if you are not familiar with the concept). The company I work for standardized on Graphset coding a long time ago. Any engineer can troubleshoot the program by asking the customer to look on the HMI for each routine's state. This leads to the exact step the sequence stopped at. Since only one event allows state transition the cause of the failure is easily identified. The only reason to look at the code is if an alarm message wasn't properly written.

About time, money and a correct specification is spot on. As a custom builder many customers don't know what they want or won't take the time to put it in writing. Changes during and after the machine is built and running cost time and money. Customers are often not happy about this type of delay and cost.

When a catastrophic failure occurs such as a CPU failure it is difficult to provide an error message unless there is some form of redundancy. One example is we had trouble with the backup battery failing when the machine was shut down (the vendor's battery had a 7 day life expectancy an no auto flashing). We had a battery failure alarm but the machine wasn't power on to give the message when the battery failed! By the time the message was displayed the program in volatile memory was lost and the flashed version was loaded erasing all machine setups and counts.