It's really mind-boggling to think of what my hourly rate would be if I were paid for the actual time that I spent troubleshooting a problem to get to a fix. The challenge is to avoid going down a rathole.
Sometimes there's an easy solution to a machine problem. At other times, well, it's really mind-boggling to think of what my hourly rate would be if I were paid for the actual time that I spent troubleshooting a problem to get to a fix. The challenge is to avoid going down a rathole.
Source: iStock (Getty)
Here are a couple of frustrating and time-consuming problems that I've faced.
Early in my career, I was assigned the task of putting a SCARA robot on a line to automatically pack parts. Essentially ball bearings had to be placed into a carton, which looked like it could be easily handled by a vacuum gripper. My idea was to use a compound gripper to do both.
You might be thinking that the eventual lesson in this story was to use different grippers for different purposes. That's usually a good idea and a reliable approach, but I eventually got a multi-purpose gripper to work quite well. It took some effort, but it wasn't my main challenge.
The main problem was that I tried to program it without a clear hierarchy of "who" was in control. This robot had a processor that was capable of being used as a PLC, but I was advised that it would probably be better to have an actual PLC handle the logic and let the robot controller do what it was good at: Controlling a robot.
I originally implemented a PLC that communicated via discreet IO points with the robot controller. This strategy was fine, but in order to save IO points, I decided to let the robot do some of the “thinking” on its own, instead of relaying everything back to the PLC.
This strategy ended up being a nightmare, code-wise. Although I think I could have made it work eventually, I eventually ditched that strategy in favor of a system in which the PLC told the controller what point to go to, and the controller simply obeyed. This was much simpler programming-wise, and it's running to this day as far as I know.
Lesson: Machines, like some humans, really need to know who is in charge
At the same company, I was tasked with implementing a vision system based on some soon-to-be-obsolete cameras. Apparently the cameras had performed fine in the plant they came from, so the theory was that they should work after being transferred. After initially rebelling against bringing yet another type of vision technology into the mix, I eventually started learning how to program the system.
I set it up at my desk and after asking the engineer who previously worked on it how the inspection was done, I was able to get a functional inspection running. Unfortunately, the fixturing and lighting wasn't done that well on these machines, so it was difficult to get them to work perfectly.
On the plus side, I was able to build several more inspection machines, using the lessons learned while struggling to get this vision system to function. I was quite proud of the new machines, and they worked much better. At least I thought they did. I don't think I've ever met an engineer who didn't think that their solution was was the best.
Lesson: When you're called on to troubleshoot a problem or make something that isn't working right work, sometimes you just have to bite the bullet and get it done. At least you can improve on it later.
So not everything is easy. If it seems like you've gone down a genuine rathole, just try to remember that you'll eventually slog your way through it. Try to keep calm -- or at least appear calm -- while you tackle the problems one-by-one.
— Jeremy Cook is a manufacturing engineer with 10 years' experience and has a BSME from Clemson University. You can find him on Twitter at