Machine Control Programming Adds Layer of Puzzle Solving to Software Development

I like that machine control programming has an added layer or two of puzzle solving when diagnosing machine behavior. The operator can't see my code executing. They see the machine behaving. My program watches inputs and controls outputs. The actual behavior has electrical and mechanical dependencies.

When a machine is not working properly, it can sometimes be difficult to know who to assign to troubleshooting. I spent the better part of a day trying to remotely help a customer diagnose a problem he was having. I could tell there was a bad signal coming from a part sensor but he couldn't find a reason why. He had replaced the sensor and checked every wire connection.

I flew out that week to help them in person. I quickly proved that it was a signal problem which was causing unexpected behavior. That behavior changed the speed at which a third party piece of equipment was running which made it difficult to troubleshoot. While my software wasn't causing the problem. My program wasn't helping to diagnose the software.

I altered my program to be more forgiving of the signal quality we were seeing. As soon as we did that we were able to focus troubleshooting on that 3rd party machine. This led to the discovery of some bad components (relay, potentiometer) and ultimately to find that their wiring harness had been rubbed raw and wires were shorting out.

Trips like this teach me that I need to be more mindful of edge cases when writing control software and to provide better options for remote troubleshooting. I was glad to be able to restore some control to the situation which proved helpful to their very capable maintenance person.