Stop Causes and Recovering from Stops

Recently, I was asked to put together a presentation for Invensys, a software company that we use at my plant.  I’ve worked with a wide variety of data in my career and wanted to share something meaningful with this group.  When I started writing ideas, I decided that it might be best to talk about some of the more basic uses of data visualization.  As I listed examples, I noticed that many recent data efforts were on a piece of OEM equipment that the plant purchased a few years ago.  I decided that it would make a good case study for the topic and also allow me to talk about the challenges of dealing with OEM equipment from a controls and data acquisition standpoint.

The machine for this case study was a tray erector, a relatively simple machine that takes a flat piece of cardboard and squirts glue on and folds and compresses it into a sturdy tray in a matter of seconds.  The vendor who supplied the machine makes many of these units and the one we purchased performed well at our vendor shop acceptance test.  Once we installed it at the plant, we realized that while it was generally easy to operate, there were times when it was tough for an operator to figure out what was needed to correct a problem.

The first challenge was getting the machine to re-start when it was stopped.  Our operators were trained to press a sequence of buttons and watch to make sure that certain lights came on.  Normally, this worked fine.  But when it didn’t, the fun began.  It turns out that there are 21 conditions needed in the programmable logic controller (PLC) to be true for the machine to start making a tray.  However, there were only two indicator lights to give operators a hint as to what the status was, so operators would have to walk around the machine and look for a problem which could take some time to find.  Without changing any code, a troubleshooting screen was installed on a nearby operator display showing the 21 logic conditions needed to make a tray.  That seemed to solve the problem for the operators, at least for a time.

A month or so after start-up of the tray erector, I came in one morning to find that the machine had been down for over four hours because the team couldn’t figure out that a safety door switch wasn’t made.  It turns out that there were 13 hard-wired contacts required to make the safety circuit become active.  This safety circuit was one of the 21 logic conditions, but again with 13 possibilities, it was hard to find the source of issues.  The electrical resource on the shift had looked at the schematic and after taking some voltage checks, determined that the problem was an emergency stop switch.  A few hours later another operator found the bad door switch and the problem was resolved.  I realized that this was a scenario that was likely to happen again based on the way the machine was wired.  We added wiring to each switch in the circuit and connected each point to an input in the PLC.  A new screen with a machine layout of all safety devices was added and now operators can quickly tell where there is a problem.

With these two changes, we have been able to eliminate virtually all downtime for electrical troubleshooting of basic equipment status issues.  Over the years, I’ve tried to do this on all equipment in the plant as a matter of principle, but often it is when an issue occurs that it becomes a priority.  With OEM equipment, you sometimes get what you get.  These changes and a few others are detailed in my recent webinar, which you can view from the links on my webinar page.