Pre-fuse testing using GOOP programming technology

The Challenge:

By providing an effective software architecture, replacing the existing test software, it will be possible to provide better technical support and test reliability. This should not result in a long period of production downtime, but should ensure that continuous improvement is facilitated.

The Solution:

Leveraging GOOP (Graphical Object-Oriented Programming) software architecture to provide modular and extensible system components provides a way to make incremental changes by breaking down existing code into discrete modules and dynamically invoking these modules from a completely redesigned user interface (UI).

"Using LabVIEW 7.1, LabVIEW Data Entry and Supervisory Control Module, LabVIEW Real-Time Module, LabVIEW PID Toolset, Compact FieldPoint, NI Data Acquisition and other tools, the GOOP programming model has shown great advantages in flexibility, maintainability, code performance, assembly reliability and cost savings."

hardware

The system hardware consists of two test head “bays” and a work cell. Each test bay has approximately 1,400 input/output (I/O) channels, while the work cell has approximately 600 I/O channels. These I/O channels are connected through three independent RS485 networks consisting of NI FieldPoint modules and accessed through OPC servers, one OPC server for each RS485 network. In addition to the I/O channels, there are various other instruments around the test bays, mainly RS232 devices (DMM and PALL contamination monitoring equipment) and two NI PCI DAQ boards.

The original system software contained about 370 Mb of code, a development effort that took about 35 years. The entire code was called through a single top-level VI (virtual instrument) that could take up to 5 minutes to load into PC memory. This made the system difficult to debug and almost impossible to maintain. The most significant advantage in stabilizing the system was breaking the code into test and tool modules.

Once these modules are identified, they are transformed through some GOOP-like VIs that encapsulate the test data. Once this is done, the system supports dynamically loading and unloading these modules into and from the system memory as needed. Thus, the UI can be separated from the rest of the system code.

The system architecture shows data encapsulation in OOP classes

This significantly reduced the memory footprint in the system—about 2 Mb for the UI plus 1 to 5 Mb depending on which is used simultaneously. Other system improvements included distributing some of the system’s time-critical processing, such as the E-stop processing subroutine, to other parts of the network to avoid delays in the OPC server. This was accomplished using Compact FieldPoint and the LabVIEW Real-Time Module.

Outlook

While the system provides the performance and flexibility we expect, it also allows us to plan equipment replacements. We can now upgrade some equipment without affecting other parts. For example, the current RS232-driven DMM will be replaced by an NI PXI controlled via LAN. This can be done by using GOO in one of the test bays without shutting down major equipment.

Summarize

The idea of ​​long-term development of the device had been abandoned early on. This made the development process much easier to manage in the following months.

The return on investment from switching to the GOOP programming paradigm has far exceeded expectations in terms of flexibility, maintainability, code performance, assembly reliability, and cost savings.

In a production line environment, the new architecture enables dynamic modification of the system to support intermediate products under development.