Is there more than one way to skin a cat in the world of coding? As many ways as there are software engineers, of course!
As with all things, people have different takes on how to go about it.
Are some coding methods better than others? Absolutely, and there are many reasons why coding must follow good practice. The equipment the vendor sells must add significant value to the manufacturer through the installation of continuous, money-producing cash cows; this is imperative to the long-term cost effectiveness and competitiveness of the Australian manufacturing sector.
For the vendor to be cost-effective and stay in business (which is crucial to the continuous servicing of the cash cows), the vendor must maximise profitability by reducing implementation costs and minimising the post-handover warranty claims that eat away profits.
Robust coding leads to reliability, maintainability and transparency, which in turn lead to the one thing all factory owners are after — more production uptime — more $$$ to the bottom line.
Crap code leads to unreliable machine behaviour and makes otherwise well-designed machinery look… well, crappy too.
Every man and his dog can learn how to write code, but it takes a particular skill to produce effective programs that are solid and repeatable and add to the bottom line of both the vendor and the end user.
Imagine the pilot in an aircraft cockpit using a pre-flight checklist from yesterday’s take-off. That would almost certainly lead to a fatal crash!
Although not as devastating, this is often what goes on in the software that runs production lines.
Programs using memory latching of past events often lead either to machine crashes or hung systems. Hung systems are where operators see a healthy “running” machine but no throughput.
What’s going on? No alarms, no info, no nothing. The software memory is out of sync with the actual state of the machine. The weather is thunder, high winds and heavy rain, but the checklist (past memory) says blue skies and a mild summer breeze.
When production does run smoothly, all is well and the line is ticking away — until a stoppage due to an abnormal situation results in a devastating impact on re-start. This is an all-too-familiar, frustrating and costly scenario for operators, factory owners and vendors alike.
To the majority of people, the machine controller is a black box and just a few people, the programmers, know better. They know what goes on inside, and even that statement is often a stretch.
Without good code structures and the use of more real-time logic and less memory latching, your machine will be built on a poor foundation that will haunt you for the life of the machine and will pull down your line OEE numbers.
Do you know the true cost of crap code in your machines?