Trouble-free troubleshooting

COMPLEX DEVICES such as vision systems, motion controllers, vibration analyzers and communications systems can be a real chore to troubleshoot. This is even more true when the original machine builder has—or shares with his customer—the responsibility to monitor and troubleshoot.The problem grows tougher when, for example, a motion control system works with a vision system over a communication link. When it fails, which system is at fault? Fortunately, because those device manufacturers also realize the sales value of built-in diagnostics, you can buy smart devices that will simplify maintenance.Almost every vendor that puts diagnostics into their hardware also has a little software program that inputs, formats, and diagnoses the data. For example, Wago has Wago-IO-Check software; Danaher’s Motion Engineering has a suite of design and diagnostic tools; Baldor has a setup and troubleshooting tool; and Cognex has In-Sight Explorer software. You can bet if a vendor has built diagnostics into a device, it also has a software tool, so its own techs can extract and analyze that data.

"There is no limit to how clairvoyant the machine can be with some sensing capability and a little programming."

Using Baldor’s Mint Workbench tool, a tech can connect a laptop to the drive via a standard USB cable, and perform diagnostic functions. Plus, the tool has a built-in oscilloscope that can diagnose problems while the drive is running.Even if you don’t set up a remote diagnostics system via the web, smart devices will make troubleshooting much easier for your service techs when they arrive on site.To implement remote diagnostics, the system must be able to collect the data; put it into some recognizable, common database; diagnose the system in real time at the machine; report problems to the customer and to you; respond to inquiries from your office; and carry out on-line diagnostic procedures from afar. But once you have the data, then what?For starters, you might have to write a few software programs or configure a few HMI screens to figure out what’s wrong with the machine when problems occur. “I tell our customers that when they have the motors doing precisely what they want them to do in the machine, they are 20% complete with their programming,” says Roger Bigler, CEO of Animatics. “They now need to obsess about what might go wrong, how that would be seen by the many sensing and recording functions within the motor or system, and program the unit to offer this information upstream for delivery to the operator. For example, if the software is programmed to check if a motor is operating 10 ºF hotter today than it normally does, then a message can be sent to lubricate the mechanism before failure. Motor current or position error can be read to detect jams. There is no limit to how clairvoyant the machine can be with some sensing capability and a little programming.”Playing “what if?” is a common technique for most software programmers. Essentially, you work down a decision tree that goes through a logical sequence of questions. Let’s say a digital input indicates the machine is not feeding parts to the assembly module. The diagnostic logic might ask if the parts feeder is on? Are there parts available for the feeder? Is there a jam? These essentially are the same questions that your service tech now asks when a customer calls in, complaining that its machine isn’t feeding parts.“Data is the key,” says Matt Miller, OEM sales and marketing manager for OSIsoft. “I’ve seen two approaches to diagnostic solutions used successfully, namely model-based and rules-based. The model-based solution generally is more comprehensive, requires more time to implement, and is suitable for complex applications. Rules-based solutions tend to be easier to embed in a standard product, can be replicated widely, and tend to be simpler to use by field personnel.”A model-based solution gathers reams of operational information for the machine builder over time, and develops algorithms to determine if the machine is running properly. A rules-based system is what was described above.The trick to automating the diagnosis is to have all the inputs you need to answer the questions, so, in the above example, you’d need sensors that indicate the feeder actually is on and parts are available, the motor current on the parts conveyor indicates a jam, and so on. Much of this diagnostics can be done in PLC logic.