If you are interested in a recipe for spaghetti, please google “spaghetti bolognese” and browse the results. But if you are interested in learning a bit more about the structure of a PLC programme, please continue reading. You are on the right page! The link to the spaghetti theme is explained at the very end of Part I.
Mankind has always wanted to automate routine tasks to operate without human intervention while they are resting or doing other things. As a result of that, a number of examples can be found in history such as the use of primitive wind turbines to pump water to the water fields and speed regulated valves to maintain a constant pressure in steam boilers.
It goes without saying that automation of a certain task is much easier once the control energy is easy to manipulate. Nowadays we sometimes don’t even realise that, but the use of electricity to drive our machinery and processes allows engineers to implement a variety of ideas and designs to automate the processes which would be difficult to otherwise achieve.
A modern example of this is the use of electric energy to illuminate our houses. If lights are all electrical it is easy to connect a computer and program it to switch the lights on or off following a certain program or a simple timer. However, if we were to use an oil lamp to illuminate our house, the automation of such a lamp following a program or a timer would be very difficult. This is one example of how an easy to manipulate energy allows implementation of a complex automation functionality.
While on the industry floor the number of applications is much higher, the number of demands to automate production is much higher as well. These demands are all in an effort to achieve and maintain the production of high quality products.
A bit of history
Attempts to approach automation tasks on a theoretical basis date back to the 1930s. In 1936/1937, the UK born and based mathematician Alan Turing introduced a paper describing the Universal Turing Machine.
During the Second World War, Turing worked for the Government Code and Cypher School at Bletchley Park, Britain’s codebreaking centre. Turing played a pivotal role in cracking intercepted coded messages that enabled the allies to triumph in many crucial engagements, including the Battle of the Atlantic.
The research work and development of this theory were later driven by growing demands to optimise the number of elements in the integrated circuits. However, for our purpose, the quote below from Alan Turing is more indicative of his thoughts related to the Automatic Computing Engine, as it was referred to at the time.
Of course, we are unable to get into too many details here. It will serve our purpose to remember that every Universal Turing Machine computes a certain fixed partial computable function from the given input and set of internal rules. The result of this is displayed as an output. The set of rules is today known as a program.
The link here provides more information for readers who want to dig deeper into this interesting era of automated machines.
Further developments in that field produced two types of machines; The Mealy and the Moore. Both machines use a finite number of internal states, inputs and outputs to execute the desired sequence. The difference between them is when outputs are energised. The outputs of the Mealy machine are energised while transferring from one state to another, whilst the Moor machine energises the output while it is in a certain state.
Fig. 1 – Automatic Machines showed with circles representing states and arrows representing transitions between states. Mealy Machine left and Moore Machine right.
Commercially available packages
Let’s leave the theoretical waters behind here and jump straight to the software packages commercially available to program automated machines in the real world.
One of the brand names in the automation area offers two packages to design an automated machine like the ones we were talking about earlier on. Use of a specialist package from the market will contribute by focusing on the process rather than on the method and will significantly contribute to a professional level of the user and project documentation! This will later allow modifications and upgrades even by engineers that were not initially involved in the project. A client’s maintenance staff will find this bit in the documentation very handy as well.
To protect the company’s internal knowledge, the structural part of the program can be locked with a password whilst still permitting access to the input and output part of the PLC program to allow efficient troubleshooting and maintenance for a third party.
I am sure there are many packages available on the market today with similar functionality but we are going to give a short description of only two examples here. The ‘Step 7 Graph’ is used for simple automation tasks, while the ‘Step 7 HiGraph’ package is used when more complex solutions are required. Both packages are installed as an add-on to the existing Simatic Step 7 Manager package. The graph package is optional also with the TIA Portal, while the HiGraph package is currently not at this stage.
Fig. 2 – Automatic Machines programmed with the Siemens Graph package (left) and HiGraph package (right). Green fill in colour is used to indicate the current state of the machine during the debugging process.
It is not an intention of this article to provide education or training in using individual packages. For that purpose it would be preferable to refer to individual manuals provided by the package supplier or search for online content. In this article, a completely manual process to create an automated sequence of a process will be discussed in Part II. The manual approach can be used with any of the PLCs available in the market as it is not related to any software package but based on the ‘pen and a piece of paper’ package :-).
The manual approach and an example
The manual approach is good to get familiar with the basics, but for more complex functionalities the use of any software package is highly recommended.
The manual approach uses the least memory in the PLC, but on the flip side does not allow automatic updates of the changes made during assembly and the first-run phase of the project. Thus a careful tracking of code changes should be implemented and documents updated at the end of the first-run phase.
In the second part of this article, we will develop an example model of a simplified hydraulic press. Some hints will be given at the end about how to divide the functionalities of the program to simplify testing and the first-run procedure. Stay with me!
Fig. 3 – Picture of a hydraulic press that we will analyse from the perspective of process automation.
That concludes the first part of our quick journey to demonstrate one example of the basic structure every PLC program should have.
The Mealy and Moore machines are only one way to address the need for a structure in a PLC program. Other equally good methods are common among organisations. I would like to hear from you what type of structure your organisation uses. What are the pros and cons compared to the method described here? What is your experience of using a structure in the program vs no structure?
Conclusion
Did you know that no structure in the program is also referred to as a spaghetti structure? The correct answer to the question from the title is in fact: “Nothing!” The PLC program should always contain some sort of structure to enable a stable and reliable performance.
Fig. 4 – A spaghetti structure of the PLC program looks like that. No one really knows where the beginning and the end are.
I would encourage all PLC programmers and people responsible for automation in organisations to use some kind of a structure while at work and save the spaghetti structure for their lunch break. 😉
If you need some support in any of these activities, I am happy to keep you company during working hours as well as during your lunch break.
—
In Part II we will have a look at a practical example and list all advantages for engineers as well as for the businesses!
