The tender trap

One of the great advantages of being the head editorial honcho here at Vision Systems Design magazine is that I'm able to spend a great deal of my time visiting systems builders who develop image processing systems that are deployed to inspect products in industrial environments.

During the course of my conversations with the engineers at these companies, I'm always intrigued to discover -- and later convey to the readers of our magazine -- how they integrate a variety of hardware components and develop software using commercially available image processing software packages to achieve their goals.

Although it's always intellectually stimulating to hear how engineers have built such systems, what has always interested me more are the reasons why engineers choose to use the hardware or software that they do.

Primarily, of course, such decisions are driven by cost. If one piece of hardware for example, is less expensive than another and will perform adequately in any given application, then it’s more likely than not to be chosen for the job.

The choice of software, on the other hand, isn't always down to just the price of the software package itself. If a small company has invested time and money training its engineers to create programs using one particular software development environment, it's highly likely that that same software will be chosen time after time for the development of any new systems. The cost involved in retraining engineers to learn enough about a new package might be simply too exorbitant, even though it might offer some technical advantages.

To ensure that they do not get stuck trapped with outmoded software, however, engineering managers at systems builders need to meet up with a number of image processing software vendors each year -- including the one that they currently use -- and ask them to provide an overview of the strategic direction that they plan to take in forthcoming years.

If it becomes clear during such a meeting that there is a distinct lack of such direction on the software vendor's part, then those engineering managers should consider training at least one of their engineers to use a new package that might more effectively meet the demands of their own customers in the future.

Certainly, having attended more than a few trade shows this year, it's become fairly obvious to me which software vendors are investing their own money in the future and which are simply paying lip service to the task. And if you don't know who I'm talking about, maybe you should get out more.