The central issue is a deep diagnosis of the system status. However, PLC programmers often make the mistake of concentrating on the function of the system first and implementing error handling afterwards. As a result, the error diagnosis system is not complete. The machine will run, but if later components don’t function properly due to wear and tear or inapplicable settings, the system will stop running without even displaying an error message, or the error message that is provided will be misleading. In addition, time is lost when commissioning another machine because the source code has to be debugged again, despite the fact that the software is actually working.
The heart of every automated machine
Can a PLC support the user experience? Are you skeptical? It can actually do just that, excellently.
What can be done better?
As developers, we concentrate on function. What is needed, right now? What is the process?
In order to be able to show quick progress, error handling and the possibility of extended functions are often neglected. However, the seeming advantage to working like this in the short term has not insignificant drawbacks over time:
- We can achieve a full overview of all unexpected disturbances only by concentrating on function. This deep understanding can’t be obtained once a task is already completed.
- We are also in the best position to see all possibilities of a function as we are developing it. After a product is develop, new applications or features can be very difficult to implement – but these are exactly the things a customer may want towards the end of a project.
Careful programming pays off in the end. Progress may seem slow at first but in the end, the work speed increases enormously. Debugging becomes less and less necessary. Additional requirements can be implemented faster. The best thing, however, is that the typical “loosening the grip” of the developer in the last phase of the project can be avoided.
Next stage: Object-oriented programming
Oh yes, for a lot of PLC programmers, this a nightmare. Not true!
To understand this we have to take a short trip into the past. Older control systems such as those from the market leader Siemens (S3 and S5) do not support object-oriented programming. With the S7-300/400 PLCs it became possible, although option were still very limited. The S5 programming style had prevailed among many programmers and reusable functions were used only at the lowest level. If there were identical system parts, the program parts were merely copied! For this purpose there were functions in the editor like “rewiring” to decouple program parts from each other. To this day, the market leader Siemens does not support true object orientation down to the last detail. Even in the TIA Portal, there is still a great need for catch up regarding hardware
connection.
Therefore, nobody should be surprised that PLC programmers often still have reservations about object orientation in the PLC.
Here, we save a lot of time by having the right development strategy. Ideally, each function should be programmed only once and then reused as often as possible. Modern PLC development tools even support inheritance, properties, methods and actions. Simply linking the hardware directly to the instance makes programming easier and more efficient. You can connect an HMI in exactly the same way.
In this graphic, you can see a simple outline of what object orientation means. Ideally, this can be extended multidimensionally, across levels, for example: machine, plant part, operating mode range, function group, function, component driver. With this structure it is then very easy to integrate a modularity as described here.
What can you expect
Would you like to execute a project especially cost-efficiently and flexibly?
You want see it in action? Lets talk about a project.
Get in touch with us.