What’s wrong with pattern matching?

A few days back I commented on the number of pattern matching-type tools offered in the latest release of Vision Builder AI from National Instruments, (thanks to Keyence for the link to their concise definition,) and suggested that this might not be “a good thing”. It occurs to me that perhaps you, my loyal reader, deserve something of an explanation.

I have several concerns about pattern matching. First, it’s computationally intensive, meaning that it’s slow. I realize that in these days of quad core PC architectures that’s less of an issue than in days of yore, but it can still be an issue when the part rate is high.

Secondly, it’s just plain inefficient. Why use pattern matching when there’s a simpler, more elegant way? If the answer is that you need robustness, then work on your lighting and optics rather than just throwing processing “horsepower” at the problem.

Third, it’s expensive. In a number of the well known machine vision packages the pattern matching tools cost extra, (and that’s disregarding the cost of the high-end PC needed to run the tools.)

But, in the interest of balance, let me also mention one very good reason for going with pattern matching: speed of application development. In many cases the single most expensive part of putting a vision system on-line is the time of the developer. If pattern matching shaves a week off his time, that’s a big chunk of money saved.

So, should you pattern match? If it saves development time, makes your application more robust, or there’s no other way, then yes. But in all other cases it’s a sledgehammer to crack a nut.