Andy MacDonald | Feb 13, 2024 | 4 min read
Old Code, New Machine
Legacy Code Implemented in New End-of-Line Test Machine
Background
A local manufacturer of industrial equipment needed an urgent, low-cost implementation of legacy LabVIEW code integrated into a new end-of-line (EOL) test machine. The legacy code contained many pre-built test recipes configured to different product types that the client wished to retain in the new machine.
The machine was commissioned by a separate system integrator who used an Allen-Bradley CompactLogix Programmable Logic Controller (PLC) as their controlling hardware. The hardware included an array of analog input/outputs, digital inputs/outputs, and digital counters. However, other machines in the plant producing the same product used exclusively NI hardware, and so the customer required that their legacy LabVIEW code be implemented as the test executive to control and read the PLC.
This posed a significant challenge with the allotted 3-week timeline, as the legacy LabVIEW code was written for NI hardware and had no provisions for PLC communication. This alone would not normally cause great trouble; however, the code was written by a third-party using their own legacy code with elaborate levels of abstraction and complexity to make it modular.
Initial Investigation
Right away the VoxSomnia team got to work unpacking and reviewing the legacy code. It’s important to understand that legacy code, especially in manufacturing environments, often acts as a pillar of tribal knowledge and quality controls of products leaving the line. Modifications to code must be performed with great care to avoid adversely impacting the quality of product under test. In this case, the risk is even greater with a change in the hardware supplier.
Once the preliminary code for PLC hardware communication was established, the team visited the system integrator to understand and communicate with the machine using LabVIEW. A basic I/O checkout was performed, and all signals expected to communicate between LabVIEW and the PLC were tested at various machine operating levels. Several hiccups were detected and resolved, but more importantly, a strong understanding of the overall machine was achieved. In this industry it is pivotal to see firsthand the systems and machines being controlled by code. It is not enough to write code for what is expected to be.
Program & Implement Solution
The team then spent a week programming changes and writing simulations to act as PLC signals with an obsessive eye towards keeping legacy test subroutines as similar as possible to new code. Simulated PLC signals allowed for virtual testing of the system to find undesired behavior. After a week of making changes and performing tests, onsite implementation at the customer factory began. The customer was under a tight deadline from their end customer and needed the machine up and running as soon as possible.
Initial problems arose in the fact that the machine was not built to service external development. Physical ports for communication with the development program were difficult to access and required system overrides to use. Additionally, the sensing equipment chosen had different measurement characteristics and lower sampling rates than previous hardware. This was discovered in the preliminary I/O checkout and code adjustments were implemented to account for lower sample rates.
The array of tests proceeded with positive results; however, unexpected behavior arose when ramp signals were sent to the device under test (DUT) to sweep the component through different performance characteristics. The lowered sample rate impacted the legacy filtering algorithm in unexpected ways, which caused filtered signal values to exhibit strange behavior; measured values displayed erratically. Much to the teams’ dismay, all DUTs were failing the tests, yet when signals were verified statically, they aligned perfectly.
The problem was not obvious with the tools available, so the team wrote a troubleshooting program to run in parallel with the main testing program to peer deeper into the hardware and measurements. More tests were run with the parallel tool, and eventually the issue was discovered when the real measured values did not match the filtered recorded values during a live ramp. The team dug deep into the code to trace where this could happen.
It turned out that the legacy code authors assumed that arrays of signal waveforms coming in from the hardware would always be the same length (using higher-speed hard-coded NI hardware). However, with the slower PLC hardware streaming data to LabVIEW, sometimes one of the appended signal arrays would be empty, which resulted in both signal arrays being truncated to a single value (a FOR loop cannot iterate on a value that does not exist). The filtering algorithm was changed to ignore cases where one array was empty, and appropriate signal values were finally obtained.
With the changes implemented, products began to pass and fail the tests in accordance with products tested on other machines. A statistical comparison was performed to validate all test results. The customer was satisfied with the machine’s performance and went into full production! The team kept in contact with the customer to monitor any further bugs or issues and provide support as needed.
About the author
