Over the range of projects we work on, we find ourselves constantly shifting focus from very distant overhead views to the minutest details. For the most part, we tend to relate the big picture information effects to big picture decisions. After all, little detail oriented decisions really only affect a component level change. While we certainly do not hold these guidelines to be law, these concepts oftentimes cloud our judgment and narrow our view of root cause options. Sometimes something small can have a big picture effect.
Web handling encoder rounding
One of my favorite instances of a very small detail affecting an overall system is one concerning the encoder configuration of a servo motor. This particular problem grew out of a need for frequent tooling changes on a web handling machine that operated continuously. It was used to cut a web into sheets with a very tight tolerance for error. The specific tooling was a cogged roller used to meter the web.
The problem presented itself when specific sets of tooling would aggregate error until the product would eventually drift out of tolerance. The investigation to determine the root cause began by characterizing the mechanical properties of the tools generating the error. After confirming the dimensions of the tooling, the investigation moved to the power transfer unit. All gearing and belts were examined for hysteresis or slippage. None of this was found to be out of tolerance.
The answer to the problem came mathematically. Because the various sized tooling rollers had different configurations of teeth, the scaling in the servo setup had to change with the tooling. Unfortunately, on many of the rollers the numbers of teeth were prime numbers. The configuration of the servo encoder allowed for a user definition of counts per revolution and counts per unit of measure. In this case, the measuring units of the sheet size were teeth on the tool. This is how the configuration defined teeth per turn of the tool. The configuration of the encoder could be modified at run time, such that the counts per unit could be changed, but the counts per revolution could not be modified.
For those of you who stuck with me through the minutia, here is the root cause. In order to avoid error, all encoder scaling had to happen in integer math. In order to create a tool configuration, the counts per turn had to be divisible by all the tooth counts, including the prime numbers. That meant we had to use a number which was larger than the double integer defining this value in the software. In short, we had an insolvable problem. No matter how we defined the counts per revolution, we would always have tooling which could not evenly divide the number of counts per tooth, thus creating an error. This error would aggregate over time until the sheet length moved out of tolerance.
This very small configuration issue ended up creating a scenario which generated much larger production problems. The error was small enough to be concealed during early testing, but once in production, it would generate scrap and downtime on a regular basis. The fix was simple enough. By simply adjusting the position of the encoder on a regular basis according to a predicted rounding error, the aggregation of the error was mitigated.