News from NI Week

Having spent a few scintillating days in very hot Austin, I thought I’d share with you what I consider the big news: LabVIEW 2012 has support for stereo imaging.

You can read all about it on the NI website, under “3D Imaging with NI LabVIEW,” and there’s some good stuff to take in. In particular, NI has provided some of the math behind stereo and spends some time exploring possible applications.

What’s interesting to me though is how NI seem to be steering clear of line-of-light based 3D for part inspection and instead are pursuing the bin picking and autonomous navigation uses of 3D. Why should this be?

They have a link with Aqsense, so they can offer some tools for 3D part inspection, but was part of the deal an agreement that they wouldn’t compete with the Spanish software house? If so, that was a smart move on the part of Aqsense. What’s your theory?

Split screen

Back in the 1970’s, (yes, I am that old!) movie producers became very fond of the split screen technique. This allowed them to show both ends of a phone conversation, though some used it for more “artistic” effects too.

Well the split screen technique has advantages in machine vision. The conventional approach to capturing two views of an object is to use two cameras, two lenses, and two lights. But as you know, the objects we look at in machine vision seldom feature a convenient 16:9 aspect ratio, so many of the pixels in each image are wasted.

Split-screening means using a mirror or prism to let a single camera see the target from two directions. This can result in more efficient use of camera pixels as well as considerable cost savings.

A great example of this comes from National Instruments Alliance partner Coleman Technologies. A case study titled “High-Speed Seed Counting With LabVIEW and NI Vision” describes how a mirror was used to generate a second view for a single linescan camera. Not only did this save hardware costs, but, according to the author, it also simplified the image processing.

Incidentally, Coleman Technologies might sound familiar to regular readers. That’s because, back in October of 2011 I described an application of theirs that had been featured in Vision Systems Design magazine. The title of my articles was “Learning from others” and the application was inspection of dinnerware.

Confused by Tattile

Tattile is not a company that gets a great deal of publicity, at least not here in North America. Perhaps they are better known in their native Italy where they’ve been in the machine vision business since 1988.

It was a press release from their North American distributor, Alternative Vision, that led me to their web site. This was about the release of their “Antares Engine Toolkit for LabVIEW.” Well as I like to work in LabVIEW I had to find out what this was all about.

It turns out that Antares is Tattile’s machine vision package. It seems to have all the usual features and is presumably optimized to run on their own line of smart cameras and “embedded analyzers” (which I think means a vision computer.) What I think this press release means then is that I can now use LabVIEW to develop applications on Tattile hardware. Or is it that I can use Antares to develop applications that run on the National Instruments smart camera?

I’m confused.

Machine vision job in Southern California

An unnamed manufacturer in the growing solar sector is looking for a vision guy or gal with LabVIEW or VisionPro experience. Details are on Dice.

They’re looking for someone to manage projects in areas such as high speed pick and place automation, robotics, assembly quality, manufacturing defects, and incoming material and final assembly inspection. Seems like this goes beyond just developing vision solutions and is more of a project management role. Why, I might even put in an application myself!

NI Week – will you be there?

It’s a few years since I last attended the LabVIEW lovefest that is NI Week. Held every August in sunny – and hot – Austin, NI Week is always an impressive demonstration of the power of the LabVIEW graphical programming language.

But my interest is machine vision, and industrial applications thereof, and having scanned the program, I’m not seeing a lot to whet my appetite. Is it that they are slow pulling the program together, or could it be that machine vision is not high on NI’s priorities?

Time was, NI had a strong vision champion in Matt Slaughter, but Matt moved on to a new position earlier this year and I sense that the baton was not passed. So just what is NI’s long term plan for vision? Speak up Austin, I’d like to hear what you have to say.

Experience is a great teacher

Here’s a novelty: a press release that actually tells us something useful.

“Machine Vision in Wood Industry” tells the story of a vision system developed by an organization called Forintek, which apparently is Canada’s Wood Product Research Institute. (I’m neither Canadian nor a lumberjack, so I’m unfamiliar with the body.)

The system was developed to measure the quantity of “fines” in lumber being used for OSB structural wood panels. However, the goals of the system are not especially relevant. What caught my attention was the description of the vision system development process. Apparently, the first attempt was not too successful, because the developers went back and had another go.

The press release does a nice job of explaining the problems experienced, and why the various upgrades, such as a GigE camera, strobed LED lighting and LabVIEW software, were adopted. Apparently the system now functions much better and is being used by more than 10 OSB mills.

Experience is a great teacher. Take a few minutes to learn from the experience of others.

Following the faithful to Austin

If you’re a disciple of LabVIEW you’ll know what I mean. NI Week is underway in Austin, Texas; a veritable lovefest of geeks united in their adoration of the graphical programming product and its associated hardware.

The problem with NI Week, from the point of view of a machine vision user, is that the conference and show are about promoting the entire NI product range. As vision is a relatively small part of what NI do, the number of vision offerings is somewhat limited. Yes there are some camera people present, (Basler, to name but one,) some of the integration houses are showing off vision applications, and there is a vision ‘track’ to the conference sessions, so in fairness, there is some good stuff. But does it warrant the cost of a trip to Austin?

Well instead of me shoving my opinions at you, let’s do it the other way. If you’re at NI Week ’08, what do you think? And if you decided not to go, can you share why?

Two for the price of one

Two useful and informative links that is, courtesy of ‘Machine Design’:

The first is a piece by Matt Slaughter of NI regarding the programming and application of the NI smart camera. Matt does a good job of introducing the various I/O functions available on the camera, (encoder input, lighting control and so on,) as well as discussing the two programming options – VisionBuilder or the more grown up LabView Vision Development Module. The NI cameras are definitely an alternative to the class-leading Cognex Insight range,) especially if the Cognex yellow clashes with your factory color scheme!)

The second piece comes from two Ph.D’s at Pepperl+Fuchs and is about avoiding and eliminating electrical noise. I don’t think I’ve discussed noise in these pages, but it can be a very big issue – a noisy image is a bad image, and noise in trigger signals could result in the wrong image being captured. The article is not specifically about machine vision, but it offers some good general tips to consider

Leaving VB6 behind?

That’s Visual Basic 6, if you didn’t know, and the word is that Microsoft wants you to “upgrade” to .NET (that’s “dot net”). I know a lot of people have already made the change, but even if you haven’t you’ve probably heard there’s a steep learning curve. Well please allow me to share an interesting article from Evaluation Engineering that helps clarify the differences and options. Be sure to check out the helpful links provided at the bottom of the article.

As an aside, I found it quite refreshing that the writer, Wendy Logan of National Instruments, mentioned LabVIEW as just one of several ways to address the challenge of .NET. I’m a big fan of providing information and letting readers make their own decisions and Wendy seems to be from the same school of thought.

Looking forward to reading your next piece Wendy!

Got to admit, it’s getting better

This week is taking on a bit of a National Instruments theme, but I don’t think the guys in Austin will mind too much. I finally got around to spending some quality time with Vision Builder AI 3.5, so today’s homily is on what I found.

First, let me say that I’m moving up from version 2.6. I liked the old version, but at times it was a bit unfriendly, so I’m glad to see that 3.5 is much improved. NI have made much of the ‘State Machine’ functionality, but for me that’s less important that the simple addition of a number of tools.

If you’re at all familiar with the earlier versions of VBAI you’ll know that to perform an image processing operation such as thresholding you had to drop out to Vision Assistant. Not a big deal, I know, but somewhat inelegant. Well now filters and thresholding are available directly from the tools menu, so that’s an improvement. Other changes I spotted (and I don’t claim to have logged them all,) are an “advanced” edge tool, the inclusion of a “golden template” tool and the addition of a QR code reader. The range of I/O functions has also grown, as has the ‘other tools’ section with the inclusion of custom overlay and logical operator functions, to name just a few.

So all-in-all, 3.5 is a significance advance over 2.6, but in the interests of being evenhanded, I feel I should also flag a reservation. There are now quite a few pattern matching-type tools available (like the golden template tool I mentioned earlier.) I’m not sure this is a good thing. Pattern matching is computationally intensive, meaning that your inspections are going to run slowly and this could be a problem if you plan to run an inspection on the Compact Vision System. But more fundamentally, pattern matching is an easy tool for the inexperienced user to grab a hold of. In fact I think it’s too easy – a sledgehammer to crack a nut, in many cases – and having tools of this power available encourages a developer to take the quick route rather than the best route.

Is that a bad thing? I’d love to hear your comments.