At NI Week 2006 this year, we hosted a Lead User reception. We began a Lead User program two years ago and wanted to thank those who had participated in a lead user project. One of the attendees was Patrick Wyse of Primetest. He has worked at Primetest
since the telecom days of the nineties. I remember running into him at the Corning plant in New York. Since then Primetest diversified into other fields including automotive and manufacturing automation. Our discussion highlighted the importance of interoperability between various systems, PXI, RT(Real-time), FPGA(Field Programmable Gate Array), etc.
Patrick sees a trend in customer applications toward those with diverse requirements. The number of tests are increasing and the type of tests are diversifying. No longer do people want a few samples taken or channels measured. They now want to take triggered samples and perform protocol analysis on it with FPGA-based tools which requires PXI working with RT, working with FPGA, and so on.
He went on to comment that it’s wonderful that you can get LabVIEW on an FPGA in the first place, but it’s still early days. I know what he’s talking about. I started at NI almost twenty years ago. In fact, my first day at work was the day the first version of LabVIEW shipped. It was September 28, 1986. I was a new hire walking down the hallway at NI. An ecstatic man came up to me in the hallway and said, “Guess what? LabVIEW shipped today for the first time.” I said, “That’s great. What’s LabVIEW?” That man turned out to be Jeff Kodosky. A few days later, I took my first LabVIEW support call from a customer in Sugarland, Texas, who had bought LabVIEW and was now building a program. The customer said it took him twenty minutes to save a VI (Virtual Instrument). Thinking he must be doing something wrong, I talked with our developers who indicated that twenty minutes was about right. It was early days for the personal computer then and performance had a ways to go. Today, with FPGAs it’s the same story. It’s early days and performance has a ways to go.
Patrick talked about some of the applications he is working on now. He built a
Blueberry sorter with FPGA-based imaging recorders to test the colors at very high speeds (about two feet per second). They built a Microsoft Windows interface to handle the MMI portion of it. He wanted to use a touchscreen product, but encountered mouse driver problems.
Patrick thought the Lead User reception was a great message – take our products and beat it up before NI ships it. It’s not new features, but rather interoperability that counts.
Primetest now focuses on full manufacturing automation where it used to be more simple test and verification applications. Today, processes are much more complex. Even manufacturing and assembly applications can include RF, Sound, Vision, Motion, and more all in the same test. Once again, interoperability comes to the fore. Due to increased complexity of the product, more and more customers want to see every board tested rather than every 100th board tested. You need multi-discipline skills across domains to do it.
In manufacturing automation, Primetest complements or replaces PLCs in numerous applications because PLCs can’t take high-speed data or even record it for later use. Traditionally people added NI tools on to PLC systems, but now they are using NI products for the relatively slow I/O control as well in replacement of entire PLCs. He indicated he would continue to win as long as the units are reliable and don’t break in the field. He went on to say that NI tools once delivered and installed don’t see a breakdown. He said that he uses NI tools because it provides for faster development; however the RT chassis doesn’t boot the same way every time. I believe it loads drivers in a different order. So again, it’s early days in this transition to multi-disciplined manufacturing automation.