Terminology, Vendor Software & PLC Code (Lesson 1)
Process and machine builders or Original Equipment Manufacturers (OEMs) are market providers of mechanical equipment to product manufacturers. OEMs create and sell all kinds of mechanical equipment, including the electrical and software coding aspects, as complete systems.
OEMs practically span all industries where there is some form of stationary equipment – whether that involves the processing of raw materials pulled out of the ground or the refined manufacturing of electronic print boards in the very computer that runs the same process.
The process and machine-building industry, or OEMs, have been around for well over 100 years and have come a long way from the early inclusion of crude electrical components to the full-scale computerised systems of today.
Since the introduction of the computer to the industry, OEMs have done many things well and progressed with the advancement of electronic and computer technologies to meet the demands of a manufacturing industry that desperately needs to keep up with an agile, competitive and ever-changing consumer market.
The problem is you can use all the latest technology and still fail to benefit if any of the software layers are written poorly.
PLC (Programmable Logic Controller) code or software in general is the one thing that OEMs struggle with – they often fail to understand the importance of their written code that controls their machines and processes, and product manufacturers are often ignorant on the matter. Let’s take a look at some of the reasons for this lack.
Undermined Machine Potential
The lack of sound control principles and structures in the PLC code of machinery and processes has enormous impact on OEMs, on the potential of their machines and ultimately you, the end user. OEMs easily develop bad reputations and won’t enjoy repeat business if their equipment takes on customer perceptions of being poorly designed, even when their equipment is of high mechanical quality.
The real tragedy behind inferior control principles is the unreached potential many machines and processes operate under. Performance potentials are greatly undermined by spaghetti-style and ad hoc PLC coding practices, so often witnessed throughout the industry.
Although some are starting to catch on to the object-oriented and structured approaches that various vendor software has gradually included over the years, there is still a lot left to be desired.
I so often come across PLC code written in ways that indicate a complete lack of knowledge of both process and software principles by the writer. The ad hoc approach begins at the first line of PLC code and continues in one long exhausting section until the end, with manual, labour-intense, and random entries of symbolic naming, descriptions and section headings, or even a complete absence of any documentation.
There is a big lack of proper use of the object-oriented methods that would actually assist the PLC programmer tremendously in achieving effective use of personal time and consistent, repeatable functionality across all machines, processes and industries.
The ultimate result of these random approaches, after long, drawn-out commissioning times with repeated trial and error attempts at making it work, is a software mess left for the customer to deal and live with for years to come.
The “spaghetti-style” PLC code is somewhat akin to the “bird’s nest” wiring left behind in electrical cabinets in the days before the emergence of the PLC, when electrically-wired relays were the only form of automation.
Software can remain in a “clean” and maintainable state if tools available in modern vendor software are used as they were intended.
Insufficient knowledge and understanding of structured, repeatable and proven approaches by electricians-turned-PLC-programmers, completely undermines the ever-expanding and fluctuating needs of today’s manufacturers. This goes especially for the high production performers who need 24/7 production capacity to meet demand and remain competitive.