What should I keep in mind when I’m launching a new product and considering a custom product validation system?

What should I keep in mind when specifying a custom test system?

Find out how the test system will be used. There are two common styles.

For the first style, if you are designing a test system to test a variety of similar designs, then you’ll want a test system that’s flexible in the ability to change sensor types and channel counts. Suppose your group tests battery stacks. You might have a set of stacks this week that has different capacities than last week. Plus, the design engineers are very interested in the rate of temperature rise on the connector, whereas last week they wanted to know the maximum temperature on the housing.

For the second style, you might be doing a performance, i.e., a durability, test where the design engineers ask you to run through a standard set of measurements and operating conditions on the different designs they give you each week. For this test system, the sensor types and channel counts will be known, or at least they are well bounded.

What’s the best way for the tester to interface with my product?

Try to avoid a mess of multiple individual wires running from sensors/actuator to the data acquisition equipment. Create harnesses and/or even custom PCB connector converters. A lot of time can be saved in setup and teardown. Also, if your product interface is mainly communications based, with little analog or digital I/O, then obviously you will need a communications card or port in the PC or controller to interface.

What if I’ve already got a test system from a previous product launch? How do I know if I can re-use it?

Are the testing needs similar? If so, likely a significant amount of hardware can be repurposed. The software may be less reusable, unless your latest product needs to be measured or controlled in the same manner as the prior one.

I need to characterize my part, so I need a very flexible test system. What should I be thinking about?

Assuming you’re designing the test system for flexible measurement types within the bounds of the types of products you make, you’ll want to consider:

1. the types of channels
2. quantity of each channel type
3. their acquisition rates

and choose hardware accordingly. Note that some types of acquisition equipment will limit these rates based on channel type. A typical example is the slow rate of thermocouple acquisition cards compared with general purpose analog input cards.

The unknowns of sensor counts and types can be addressed by using external signal conditioners connected to generic analog voltage input cards. If additional input channels are needed, connect them to a spare voltage input card via external signal conditioning boxes. This approach is often less compact, more expensive, and perhaps noisier than using acquisition hardware with built-in signal conditioning.

Software can often either be a datalogger or based on the concept of one, while including any control of conditions and safety/shutdown monitoring. If you need product-specific calculations as data is being acquired, then put those calculations in a “calculation engine” section of the test application. Note that, in most programming languages, these calculations can be called by loading functions at runtime rather than needing to “hard code” them into your application. This method improves flexibility.

How much will the tester cost (in 2023)?

It depends of course on the complexity of the tester.

• A brand new tester can cost as little as around $10,000, with equipment on a bench and only doing data logging.
• An expensive test system with many, many features for control and acquisition and calculations and reporting and mechanical/electrical custom equipment and so on can be over $500,000.
• An average cost for design validation test systems that we see at Viewpoint is around $50,000.

What’s the process to develop a custom test system?

Write down your requirements and start to design and then implement around those requirements.

Be flexible, because sometimes you find during design that implementing a certain requirement can be expensive and time consuming. Do you really need that requirement? Can you soften the goal? If so, then iterate on the requirements until you reach a reasonable cost/benefit balance.

Here’s our typical process: Custom Test Equipment development process.

What programming language is best for test system development?

Programming languages have many dimensions to consider:

1. development time,
2. deployment license cost,
3. support for hardware,
4. longevity,
5. support (vendor and community),
6. availability of programmers for test system development,
7. and a host of others.

At Viewpoint, we use LabVIEW and C#.NET.

• LabVIEW is good at supporting hardware, especially from NI (naturally), because most everyone offers LabVIEW drivers for their products.
• C# is great for web and database development on Windows.
• Python is free, there is a large base of people in the on-line forums, and it is well-supported with 3rd party add-ons, but it is free and can be “you get what you pay for”.

We believe you can’t go wrong with LabVIEW and C# or both. Use the right tool for the job!

What are some precautions I should consider taking so the tester can help prevent damage to my part?

It’s a new design with operational behavior you don’t yet fully understand.

For obvious safety critical aspects, monitor for parameters at high levels, such as current, temperature, pressure, voltage, vibration, and so on. You can choose to use a dedicated controller, such as a PLC or motion controller, or a simple relay that trips when levels get too high, and shutdown the test and remove all energy.

Choose devices that let you set these “trip” levels low enough to be safe and then increase the levels as confidence builds.