If the equipment isn't running reliably then no amount of fluff around the edges is going to make a scrap of difference. The sad part is that we see many businesses struggling day to day with poorly programmed equipment and amazingly, it's often the original equipment manufacturer (OEM) that's supplied the equipment with poor code, complex fault recovery, limited or non-existent documentation and minimal training.
And that's assuming your sparky can access the code in the first place!
Would you believe there are actually businesses out there that although they bought the equipment, they don't actually own a copy of the machine code, stored away in some version-controlled repository? Some OEMs refuse to provide it at all.
Often access itself is restricted by passwords that again, the customer doesn't have. The excuse … er pardon me .. 'reason' touted is that the code is 'clever' and so the OEM doesn't want your sparky in there. If your business is a nuclear power station, then fair enough, however for the average production plant, at the very least your business needs to insure itself from the OEM going out of business and taking its code with it. (We've actually seen this happen and the business was left with a $1M boat anchor that started life as a high-volume injection moulding machine.)
You have every right to insist that your business is protected and that you own a copy of the code your machines are running. How else can you embark on a path of continuous improvement if you can't access the very software that runs the machines?
“I guess the question I'm asked the most often is: “When you were sitting in that capsule listening to the count-down, how did you feel?' Well, the answer to that one is easy. I felt exactly how you would feel if you were getting ready to launch and knew you were sitting on top of two million parts -- all built by the lowest bidder on a government contract.”
– John Glenn, Mercury Astronaut
The other sad fact is, and this comes from years of first-hand experience, that OEMs rarely provide what we would call high-quality code and by that we mean:
Easy to understand
Structured
Commented and documented throughout
In English (always a favourite!)
Based on best practices such as 'object-oriented'
Real-time fault recovery without a sparky's laptop being plugged in.
“Surely not!” you protest!
Think about it this way.
Your last machine was probably
influenced by a procurement decision
based on price.
If you're an OEM in a competitive pricing landscape, how do you reduce your cost to manufacture?
Unfortunately, poorly written code that'll pass commissioning and release the final payment, is the cheapest option. The quality of electrical gear in the panels, such as PLCs, also affects the final price.
I know it's an old adage, however you really do get what you pay for.
Procurement dollars saved now (because the purchasing person wants to reach their annual performance KPI by screwing down on price) when that equipment will perform thousands of hours of operation in a key role on your production line, will cost you so much more than their annual bonus!
The reason we know this and most businesses don't, is that the loss to production for events such as this is generally unknown, since the majority of businesses don't have efficient methods to record and capture it in the first place.
And how often have you heard of a production person approaching the purchasing person and tell them the machine they bought is simply not going to do what it was bought to do? Often, the production and engineering teams simply have to make do with what they have, so they inherit the stress of keeping the lemon alive.
If the issues are to do with how the machine is programmed, then one solution is to engage someone who has the skills to look at the existing code, make recommendations implement best-practice standards, document what's there, improve fault recovery and reduce troubleshooting time.
