This page provides an overview of my contributions to ATX’s NH Software. To give the project context, it begins with a short introduction to the workflow of adapter development, as several aspects of the software are closely tied to that domain.
Overview
Testing circuit boards reliably is a demanding engineering task, particularly in safety-critical contexts. While a defective consumer board may be inconvenient, failures in electronics used for systems such as alarms or industrial devices can have much more serious consequences. For that reason, manufacturers often rely on specialized test systems to validate boards during production.
These test systems are commonly referred to as adapters. Their purpose is to establish electrical contact with a large number of points on a circuit board in order to verify correct functionality. ATX Hardware GmbH develops such systems, and an important part of that workflow is determining how the board can be supported safely during testing.
Electrical testing is performed through large numbers of spring-loaded needles that make contact with the board. Because each contact point contributes mechanical force, the total pressure on the board can become substantial when thousands of contacts are involved.
This is where Niederhalter, abbreviated here as NHs, become essential. They provide mechanical support from the opposite side of the board and help prevent structural damage during testing. Determining where NHs can be placed safely is a central part of adapter development, as modern boards are often densely populated and offer very limited free space. Incorrect placement can damage components and compromise the entire board.
To reduce risk and improve this workflow, ATX developed a dedicated in-house tool: the NH Software. Its purpose was to make NH placement faster, safer, and less dependent on manual interpretation, especially in situations where human error could lead to damaged hardware.
NH Software
The NH Software is used by both the sales and adapter development teams. For sales and project planning, it helps estimate the complexity of a board and therefore supports more reliable assessments of cost and implementation effort. For development, its primary value lies in enabling safe and informed NH placement.
To support this workflow, the software provides several visual layers, including a 2D board model, a captured board image, and the so-called carpet. The carpet is a color-coded safety overlay that indicates whether a given region of the board is suitable for NH placement. The underlying calculation is proprietary to ATX Hardware and is therefore not described in detail here.
Although the software includes additional functions, the combination of geometric data, imaging, and safety visualization is its most important capability. It allows both quick early-stage project evaluation and more reliable engineering decisions during adapter design.
My Contributions
During my time at ATX, first as a student trainee and later in a full-time role, I implemented several substantial additions to the NH Software.
One of these contributions was support for Line-Arc geometry in the calculation pipeline. Line-Arc is one of several primitives used in DXF files, which are commonly provided as part of board data. Because many geometric operations depend on being able to determine whether an element lies inside or outside the board outline, comprehensive support for all relevant DXF shapes was important for correct downstream processing.
A second major contribution was an algorithm for detecting carpet outlines and converting them automatically into a Line-Arc representation. This was required to enable the 3D printing of custom NHs based on the safe support regions identified by the software. This capability was particularly useful in areas with very limited free space, where standard NH geometries could not be used safely.
The carpet itself is represented similarly to an image, with pixel colors encoding available safety distance. My outline extraction approach first applied a marching-squares-style contour pass and then reconstructed line and arc segments from the resulting 2D boundary data. The process is computationally intensive, but the resulting geometric representation proved accurate and practically useful.
My largest contribution, however, was the implementation of the 2D engine that now powers rendering and content handling. The original version of the software relied almost entirely on VB.NET GDI+ for drawing, which had become a significant performance bottleneck. For larger projects, rendering operations could take several seconds and would often block the user interface.
My replacement system was built around a heavily modified version of SFML, extended to support features such as stencil testing and concave shapes. Some improvements were implemented in the C# wrapper, others directly in the underlying C++ source. On top of that rendering layer, I implemented a custom engine in VB.NET for content generation, drawing, lifecycle management, and integration into the rest of the application.
I also developed several custom shaders to replicate visual behaviors previously handled through .NET drawing logic, including emphasized selection states such as bold or dashed rendering. While some resource handling remained in VB.NET, the new engine replaced almost the entire previous drawing path and was designed with both performance and future extensibility in mind.
The resulting performance improvement was substantial, on the order of up to 100× in practical scenarios. Just as importantly, the new renderer reduced CPU load and made the software significantly more responsive for day-to-day use. Feedback from the teams using the application was very positive, as the improved responsiveness noticeably supported productivity on larger projects.
Conclusion
Although I was not the sole developer of the NH Software, my contributions affected several core areas of the system. The software now supports the full range of relevant DXF geometry, enables custom 3D-printed NHs for previously unusable regions, and remains responsive even on large projects because of the redesigned rendering architecture.
There is still room for further development. Some specialized interaction features were not yet migrated to the new renderer, and the carpet computation remains both memory-intensive and time-consuming on larger boards. In principle, this part of the pipeline could benefit from GPU acceleration, for example through CUDA. Even in its current form, however, the software is in daily use and provides clear practical value.
