Blog post by Connie LeMarbe, Controls Engineer
What is worth my time? When programming onsite, what is worth doing: continuing to troubleshoot hardware or writing a new function?
Anyone who has worked with technology knows that it sometimes grants you unexpected results. When working onsite, solving those curveballs comes with the additional challenge of maintaining schedule. You are then faced with the question: what is worth my time?
A) Continually attempt to troubleshoot the hardware and find a way to get it to work the way you wanted it to, or
B) Accept the results you have and alter your perspective on the solution?
I was faced with this question while working with my coworker, Nick, on a fixed scanner that was reading multiple barcodes. Originally, I thought we had programmed the scanner to read the results in a specific order, from top to bottom on the sticker. However, each time the scanner read the barcodes into the program, it would read in a different order. There were also random ‘ERROR’ messages and commas that would appear between the different barcodes. What made it worse was these varied results occurred while scanning the same exact sticker.
When an entire production line is depending on your timeliness, seconds can feel like days. After several long minutes of researching, reconfiguring the hardware, re-downloading, and rescanning, we were not making any progress. Among other things, those commas were still there. As the minutes were ticking away, we had to stop and ask ourselves: Is this troubleshooting worth it? How long do we continue on this same path before we look for a different one?
At that point, Nick and I decided that I would take 15 minutes to write a completely new function while he continued to troubleshoot. If the function was a success, then we could add it into the code.
Those 15 minutes went a lot faster than I thought. I was not able to complete the entire function, but I was far enough along to start testing. With some minor tweaks, the code I finished was up and running and capturing the first two barcodes without an issue. A little while later, the rest of the code was finished and we were successfully organizing the input data.
In the end, we realized a few things. We needed to play to our strengths and set time limits. If we have not made any progress in that time limit, take a step back and look at the problem from a different angle. In our case, it was just accepting what was given and finding a solution to make it work. Luckily for us, the time invested in this new solution saved us more time down the road. We were able to use that solution on three other stations for that project as well.