.NET Qualification-Tool for Pipet-Instruments

Tecan Schweiz AG develops various instruments and devices to support the daily tasks in a laboratory. Many of these instruments have motor-driven parts which move items (water tubes, tablets of wells etc.) from one station to another. During engineering, numerous motor control parameters need to be evaluated to program an optimal machine configuration. These motor control parameters have must be validated for their qualification. The current parameter qualification tool has some major shortcomings: Firstly, it is not implemented with standard Tecan C# library, the Tecan Base SDK; it is written in the less known scripting language LUA. Secondly, the current LUA script tool can only execute one test at a time. After each test the results have to be gathered and stored by hand. As this leads to unnecessary work that could be automated, Tecan aims to develop a new qualification tool in C# using the common Tecan Base SDK.
The task of this bachelor thesis is to determine the requirements and specifications of this new qualification tool and to design and implement a first version of the tool in C# and with the Tecan Base SDK.
In the first phase of the project, all the requirements for the new tool have been analyzed and formally defined. In the second phase, the essential functionality required for the tool has been implemented. As main approach to solve the problem the concept of a strategy files has been developed. Within a strategy XML file the different tests for different motors are defined. Inside the qualification tool the user can select one strategy and one or more motors he wants to test. The tool will then test all selected motors in the most parallel way possible till the user stops the process. It gathers all generated data and stores them. On a report view it presents a first overlook over the gained data.
As a result of the project, the first version of the qualification tool has been completed. Test runs can be executed and will gather data fully automated in an endless loop. Old test runs can be loaded and continued if the same instrument configuration still is present. In the future many features can be added, as example automated error recovery. Current implementations can be enhanced, as example the current gathered data is stored in a XML file. Storing them in a (online) database would be more performing.