How to Accelerate LabVIEW Based ATS Development, Handling Errors and Understanding Execution Flow (Part 1 of 3)

Reduce your debugging time with simple tools (1/3)

This is Part 1 of our 3-blog post series.

Problem: Using Automated Test Systems (ATS) to support Research and Development (R&D) involve constantly changing components and test plans. At a bare minimum, the DUT (device under test) and the ATS itself evolve with the progress. Complex DUT such as an embedded systems make the problem even more obvious. Managers of testing departments need to ensure their teams can identify the root causes of errors quickly or a lot of time and resources can be wasted troubleshooting symptoms.

Solution: In this 3-part blog series, we discuss some of the simplest and most effective tools test managers and their teams can use to increase efficiency with a LabVIEW-based ATS by accessing information to resolve errors faster. From a management point of view, using a reliable ATS increases testing productivity, accelerates debugging and can create a 10X or more ROI (return on investment). For example, tractor manufacturer, Versatile, says that troubleshooting their embedded product is now 75% faster thanks to their new ATS. Additionally, they can test everyday rather than once a month (ref: see the full Versatile case study for details).

Recognizing if you have this problem

As a test manager who needs to keep projects on schedule through R&D, you can guide your team to implement better development practices and/or make their testing tools more efficient. Technical issues will always arise but the key is how quickly the root cause is discovered and the problem fixed. If the root cause of an issue is unknown and your engineers’ next step is to “debug their code” with probes, then the test system is clearly not providing enough information automatically and needs upgrading.

Where to start?

The following three ATS upgrade ideas each create significant productivity gains in return for small development efforts. We will go into more details about each of them in Part 2 and Part 3. Please note that although we are focusing specifically on extending LabVIEW,  the concepts are applicable to most ATS and can easily be used in C, Python, VB, etc.

1. Creating a System Log for your ATS. The benefit here is that you can understand the sequence of user actions and software execution in real time. Moreover, it allows the information about errors to be contextualized within the operation to understand what the ATS was doing at the time of the error.

   

2. Error Reporting of every error found on the error cluster. Too often, teams trying to progress quickly ignore errors (i.e. software exceptions) unless someone is actively working on a specific issue. Ensuring the ATS always reports (and ideally handles) errors is usually a simple yet highly valuable addition to ensure awareness of inaccurate behavior in a timely manner.

   

3. Save both logs and errors to disk. By doing this, you are able to analyze strange behaviors, review the errors and compare with “good” test sequences long after the fact. Synovus believe that we can typically answer more than 80% of new questions using this stored information.

We will go into more detail about each of the items in Part 2 and Part 3, but as a starting point, we recommend having a discussion with your team about these concepts. Beware however, busy teams will often argue that there is “not enough time to do this extra work” (“…but enough time to do it twice”) In that case test managers need to encourage smarter development that accelerates your schedule through simple additions to your ATS.

Continue reading the next post (2/3) here.