Inventing something new is all well and good, but without efficient machines to automate the industrial processes, the idea is unlikely to be profitable. Addressing this challenge can be both time and resource intensive.
In our experience of bringing innovative products to market, we’ve found that commissioning is a time-critical part of the traditional design and build process. So, anything we can do to reduce the commissioning time without compromising quality will reduce the overall development time.
The way machine developments normally go, we write the programmable logic controller (PLC) software before building the physical machine. This results in a period where the software team is waiting to test their work on the machine.
When the machine is ready, the software and mechanical teams get the machine working without product (we call this dry cycling), this focuses on checking that the machine’s individual parts do what they should. It’s then ready for process commissioning using product (we call this wet cycling), this focuses on quality and speed.
While software commissioning should be about making the machine work safely and reliably, part of its purpose is to find and fix operational software bugs. Whenever we find a bug, we need to diagnose its cause and correct the software, creating delays. So, to address this inefficiency, we developed a way to test the software without the physical machine, making use of the previously inactive time.
It’s standard practice to use automated testing and continuous integration to find bugs as we develop software. However, the development tools for PLC software from major vendors make it difficult to use these approaches, which is why we created something new to tackle this challenge.
This allows our developers to write tests as they write PLC code. We transfer the sequences and logic we want to test in the production code to a test harness application that runs on a PLC emulator. This lets developers test behaviours without having the machine, finding bugs while the code is still fresh in their mind so they’re easier and faster to fix. By re-running all the tests, we can confirm any fixes or new code blocks haven’t ‘broken’ other parts of the software.
Writing tests and code in parallel takes some extra time, but it’s off the critical path and is worth the effort due to the improved quality and shorter commissioning times, creating an overall time vs. cost benefit. Continuous integration takes some of the burden of running tests away from the developer, ensuring they run and telling the team if any fail.
We first used this technique a few years ago for a set of three machines. We estimated software commissioning would take 14 days for all three machines, but by using a PLC emulator to test the software before we finished building the machines, it took just four. We spent less time debugging code and more time getting the machines’ efficiency right. Overall, it was a smoother commissioning process, allowing the software and mechanical teams to work in tighter collaboration sooner.
Of course, we’ve now adopted this as standard practice for all our machine development projects.