This post [1:4] is part of a new series by GPower software developer, Jesper Kjær Sørensen, on building robust software and test systems.
Do you know the feeling...?
Do you know the feeling? The phone jolts you awake from the night’s sleep you so badly needed. Groggily, you look at it. Your colleague is in the middle of commissioning a new test line in Sydney, and you are on call. “Houston, we have a software problem!” comes from the other side of the planet, and you start investigating what is going wrong.
10 hours later, after vast amounts of coffee, you find the fault. The test system does not know that the DUT is closing the connection. There is a check to see whether the connection is present, but when the check fails, the test system shuts down. The solution is quickly implemented, and we change the test system to re-establish the connection. If that fails, the unit is flagged as faulty instead of shutting down the test station.
Lack of error handling can be costly
The example above is not a pleasant situation to be in. Commissioning comes to a halt because you have to troubleshoot. It costs time and money to arrive at a solution. This could have been avoided by prioritising error handling. Lack of error handling can be a major cost driver that customers often forget to prioritise. Instead, they choose the simple solution: all errors shut down the test system, whether this is necessary or not.
Lack of error handling is one of the reasons you hear phrases such as, “This tester is a bit temperamental, so it works best when Mads is at work” or “I’m not quite sure why this is happening. Just ask Mads when he comes in tomorrow.” That is because Technician Mads is the error handling, due to his knowledge and experience. This is not a sustainable long-term solution, certainly not if Technician Mads leaves the business. So how do you make your operations less vulnerable?
5 simple steps to reduce dependence on “Technician Mads”
- Identify, categorise, and prioritise errors in both the test system and the product(s)
- Assess whether critical errors can be reduced to non-critical
- Resolve all non-critical errors where they occur
- Shut down the test system in the event of critical errors
- Make error messages action-oriented so troubleshooting becomes faster
By resolving the error instead of shutting down the test system, you save time both during the test and overall for the test system. The time it takes to reach the same point in the test will be saved immediately. In the worst cases, such as thermal test systems, start-up and shutdown times can range from several minutes to hours.
If you want to keep your night’s sleep and save money, it is time to get started with error handling.
– LabVIEW Champion, Jesper Kjær Sørensen, GPower
![Don’t let your error codes become the next Blue Screen of Death [3:4]](https://gpower.io/wp-content/uploads/2026/09/Figur-1-Windows-11-Blue-Screen-of-Death-1-300x225.webp)
![Error handling in LabVIEW [2:4]](https://gpower.io/wp-content/uploads/2026/06/Fejlhaantering-i-labview-jesper-kjaer-soerensen-gpower-300x169.png)
![Don’t let your error codes become the next Blue Screen of Death [3:4]](https://gpower.io/wp-content/uploads/2026/09/Figur-1-Windows-11-Blue-Screen-of-Death-1.webp)
