Rather than incur the cost of a newer development environment, systems integrators opt to rely on methods and software that they have successfully used in the past.
by Andy Wilson
Developing a machine-vision or image-processing system on time and at reasonable cost is a daunting task. Design tangibles, such as the cost of cameras and frame grabbers, often merge with design intangibles, such as fuzzy product definitions, which may emerge as the project evolves and complicate systems development.
For engineering managers and engineers involved in system development, roads that were clearly defined at the beginning of the project may wander into roads less traveled. The effect is added development time and cost, resulting in more expensive end-user solutions. Confronted by these prospects, many systems integrators often rely on well-trodden software-development paths. Rather than incur the cost of a newer, perhaps better, development environment or machine-vision/image-processing software package, systems integrators opt to rely on methods and software that they have successfully used in the past.
Indeed, many engineers and engineering managers have admitted to me that the learning curve for new software is too steep to be absorbed by smaller systems-integration houses. As a result, their choice of software products is generally based on experience. Their design rule is if certain software has worked in the past, it will probably work in the future.
While there is nothing wrong with this approach, it can sometimes backfire. Based on experience in only a small number of software packages, some companies are forced into developing systems that task engineers with C-code and HMI (human-machine interface) development and even assembly language programming. To accomplish the main design goal, engineers may struggle over hot compilers for weeks before the code is developed. And, although eventually the code will run and the product is brought home on target, the cost in man-hours (although not necessarily in dollars) may be far more than had been planned.
Most engineers don't complain when faced with such design tasks. They see them as work challenges. And they get the most out of the tools that are available, often for the lowest cost possible. They design successful products.
To the engineering manager, however, the decision to doggedly follow one avenue of development may result in an overstressed development team and projects that are not delivered on time. It is in their best interests to explore alternative methods. For example, all the C-code machine-vision software development spent might have been available for a few hundred dollars in run-time code. In addition, the HMI software needed to control processes on the factory floor probably exists somewhere. These software packages can be readily used to prototype and develop machine-vision systems and solutions.
However, some engineering managers are too focused on routine software, such as Microsoft Visual C++, to discover other methods. Their excuse is not to burden the software-development team with new choices. These engineering managers should spend their time investigating the various proven graphical-user-interface (GUI) based image-processing, machine-vision, and factory-automation tools currently available.
Even better, they should encourage their engineers to learn the functionalities of some of the newer GUI-based software programs. Only in this way will engineering managers be able to fully direct the engineers in their charge, gain valuable feedback from them, and inform higher management of the most viable engineering options at the start of the software-development process.
With engineers and engineering management fully empowered, system development should not veer radically from the proposed specifications, even if the end user decides on last-minute changes.