My experience spans PLC programming and computer programming using OOP languages like C++ and Java. It's worth noting that current PLC programming lacks OOP features such as inheritance and polymorphism, making it quite different from traditional computer programming. In a PLC system, quick response times are critical, with delays of even half a second being unacceptable. Unlike computer programs, PLC programs must prioritize speed and efficiency over extensive memory usage. This contrasts with OOP programming, which can introduce execution overhead that may slow down processes.
It is important to note that current PLC programming is notably lacking in object-oriented programming (OOP) features such as inheritance and polymorphism. This is mainly due to the absence of a base class library. However, there are platforms like Codesys and Twincat that offer support for these essential OOP concepts.
In my opinion, clear transparency and easy-to-understand logic are essential reasons for utilizing a PLC, making ladder or FBD programming highly preferred. However, if your focus is more on convenience and you opt for ST or IL programming, it may hinder troubleshooting efforts by maintenance personnel. In such cases, using a computer with enhanced functionality or a cost-effective microcontroller might be more suitable.
I personally reserve textual programming for complex mathematical operations that may appear convoluted in ladder format or when time constraints necessitate streamlined logic for multiple tasks. Recently, I have developed Python scripts to automate ladder instructions for a large number of processes, such as controlling the start/stop functions of 65 motors concurrently. These scripts efficiently generate and insert individual ladder sequences into the project, simplifying the programming process.
BeepBob expressed his belief that when performing a discrete process such as turning a pump on or off, it is beneficial to make the process visually apparent by utilizing ladder or Function Block Diagram (FBD) language. In Codesys, it is possible to represent a method call in FBD or Ladder without the need for Structured Text (ST). Some individuals still prefer implementing a ladder rung over creating a function or Function Block, which may hinder the adoption of Object-Oriented Programming (OOP).
One key difference between computer programming and PLC programming is that PLC programming is typically not event-based, as user interaction is minimal. Therefore, simply calling a method to start or stop a pump may not provide all the necessary functionality, such as checking if the pump actually started or stopped. In PLC programming, additional logic is often required, separate from the method call.
For example, changing from "P200.ProgStart :=1;" to "P200.AutoStart();" may not have a substantial impact without additional background logic. Additionally, SCADA/HMI systems present another barrier to OOP adoption, as many systems do not support method calls. In such cases, creating methods and utilizing a boolean input/output interface may be necessary to control and monitor devices like pumps.
Furthermore, some OOP concepts are currently being debated, such as inheritance versus composition. Instead of focusing solely on OOP features, it may be more beneficial to prioritize modular code design and address OOP principles as needed in the development process.
Creating a structured hierarchy of classes with functions and data variables is essential in Object-Oriented Programming (OOP). These classes serve as the foundation for creating instances (objects) that can be inherited and modified in derived classes. Designing a well-suited class hierarchy can be challenging, especially for those new to OOP. I have experience in implementing small automation tasks in Java, like interfacing with scales and printing labels based on weight parameters. It would be great if a manufacturer steps up to develop a true OOP system for Programmable Logic Controllers (PLCs).
When it comes to Object-Oriented Programming (OOP), having a well-structured hierarchy of classes containing functions and data variables is crucial. These classes serve as the foundation for creating instances (objects) that can be customized in derived classes. However, grasping and implementing the OOP paradigm can be challenging, especially when it comes to designing an effective class hierarchy for a specific purpose.
The main hindrance to fully utilizing OOP is not the PLC manufacturers, but rather the users themselves. Despite the potential to create hierarchical data structures and abstraction to streamline programming efforts without OOP, users often struggle to do so effectively. For example, many opt to duplicate code by creating separate blocks for different Variable Frequency Drives (VFDs) instead of utilizing a unified interface.
While OOP is not always necessary (relying on variable naming can suffice), there is a missed opportunity in failing to leverage its capabilities. Until users shift their mindset towards more efficient programming practices, the introduction of a true OOP platform by manufacturers may not have a significant impact.
Cardosocea pointed out that the primary challenge of implementing Object-Oriented Programming (OOP) in Programmable Logic Controllers (PLCs) lies not with the manufacturers, but with the users. Despite efforts to simplify coding for PLC applications, the real issue is the operational costs outweighing the development costs. Using OOP may not provide any significant benefits, and could even be a hindrance during operation due to the complexity it introduces. This complexity makes diagnosing problems during operation more challenging for users unfamiliar with OOP principles.
One common mistake people make is viewing the PLC as an inaccessible computer. However, the program and ladder serve as an additional user interface for troubleshooting unique systems. Think of the ladder program as an application on a phone, allowing users to adjust settings. It is essential to design the program with the user in mind, especially maintenance personnel or plant engineers with minimal PLC experience. Simplifying the program for neatness may hinder the user's ability to effectively utilize the interface for machine troubleshooting.
Arpus4KM pointed out that a common mistake people make is treating PLCs like inaccessible computers. However, the program and ladder can be seen as a unique user interface for troubleshooting processes that can't be easily fixed with online updates. The ladder program functions as an application on a phone, allowing users to adjust settings easily. It's important to consider the end user, who may be a maintenance worker or plant engineer with limited PLC experience, when designing the program. Simplifying the interface for a clean look should not compromise usability. It's crucial to build the program with a user-friendly interface in mind.
The best practices for code abstraction can vary depending on the platform being used. Unfortunately, AOIs in AB have historically unnecessarily complicated the process. On the other hand, FBs in Siemens are known to be quite effective. Platforms like Codesys provide you with comprehensive OOP capabilities. However, it is crucial to incorporate extensive diagnostics into your abstracted code and ensure it is thoroughly tested and reliable. This may not always be practical for one-time projects, but for many systems, utilizing standard chunks of code can be beneficial. It is important to trust the instructions provided by your PLC vendor as a black box, as integrator code can also be reliable. When dealing with drives, it is much simpler for beginners to refer to a fault code rather than scanning the entire parameter list for irregularities. The same principle applies to pre-programmed PLC code blocks. It is worth noting that programming diagnostics can be as time-consuming as developing the actual process logic, leading to the tendency to overlook them. Additionally, SCADA/HMI systems are the final frontier for the next 5 to 10 years. Most of these systems currently lack the ability to call methods, necessitating the creation of methods and boolean input/output interfaces for receiving commands and providing feedback. Although HMIs are beginning to support OPC UA methods, this introduces another layer of abstraction to the process. The direct method of implementation remains unclear.
Codesys describes it as "Object Oriented Industrial Programming," which involves utilizing functions, but it is not necessarily a full-fledged OOP program. Learn the basics and practical examples of Object Oriented Industrial Programming in CODESYS with this informative presentation by Gary L. Pratt, the president of ControlSphere Engineering, available on YouTube.
In computer programming, Object Oriented Programming (OOP) offers the advantage of breaking down large projects into manageable parts, allowing multiple individuals to work on their specific part, class, or classes. Despite its benefits, there may be skepticism about its usefulness in programming PLCs. While it would require a manufacturer to introduce it, implementing OOP in PLC programming would undoubtedly be a significant departure from current methods.
In the realm of computer programming, the concept of "Object Oriented Industrial Programming" is gaining traction, particularly in the context of functions. However, it is important to note that a program centered on OOP principles is more than just applying functions. Object Oriented Industrial Programming - Basics and practical Examples in CODESYS--------------------This informative presentation on Object Oriented Industrial Programming was delivered by Gary L. Pratt, the president of ControlSphere Engineering, and is now available for viewing on YouTube. One of the key benefits of OOP in programming is its ability to compartmentalize large projects into manageable parts, facilitating collaboration among multiple individuals on their respective classes or components. The potential application of OOP principles in PLC programming is a subject of debate, with some questioning its feasibility within this context. Despite this, there are PLCs in the market that do support OOP features such as methods and class inheritance. This video primarily focuses on programming best practices rather than delving into the technical capabilities of PLCs. It is worth exploring the possibility of incorporating OOP principles into PLC programming, as it could potentially revolutionize the traditional approach to programming in this domain.
In my view, a successful automation program hinges on math modeling, where real-world processes are first defined using clear mathematical formulas and then translated into a programming language. Utilizing object-oriented programming can be advantageous if there is an encapsulated library with the mathematical formulas already translated - simply define an object and manipulate it. However, if such a library is not available or if the code is stored in a plain text file, the process may be more complex.
Arpus4KM made a valid point when discussing the misconceptions surrounding PLCs. Many people view PLCs as inaccessible computers, but in reality, the program and ladder serve as a user interface for troubleshooting unique systems. Unlike mobile code updates, PLCs require a hands-on approach for maintenance. It's crucial to think of the ladder program as an app on a phone, allowing users to adjust settings easily. Just like a phone app should be user-friendly, PLC programming should be intuitive for maintenance staff with minimal experience. Simplifying the program for neatness may hinder its usefulness as a UI tool. Let's keep this in mind for efficient troubleshooting in the future.
Arpus4KM mentioned that the user, whether it be the maintenance personnel or the plant engineer with limited PLC experience, often uses PLCs as a troubleshooting tool. It is crucial for the PLC interface to be user-friendly and well-organized for efficient operation. However, simplifying the interface too much can hinder the user's ability to navigate through the system effectively.
In contrast, looking at the ladder logic is necessary for maintenance personnel due to the lack of built-in diagnostics and transparency in industrial systems. Just like how one might not typically delve into the ECU code of a car or the code running on a phone.
While HMIs are beginning to support OPC UA methods, this adds another layer of complexity. It may take decades before OPC UA becomes a standard feature across industrial systems. Additionally, OPC UA may not yet be suitable for larger applications.
It is important to note the distinction between OOP and modularity in programming. OOP can assist with creating modular code, but it is not a guarantee. Code should ideally be modular, regardless of whether OOP is used.
Cardosocea stated their disagreement with the idea that maintenance personnel should not need to access ladder logic in industrial systems. They argued that many systems lack proper diagnostics and transparency, unlike in modern cars or phones where users do not typically view the ECU code. Despite the slow adoption of OPC UA in industrial systems, it is important to distinguish between OOP and modularity. While OOP can aid in creating modular code, it is not a guaranteed solution.
In the past, machines were like puzzles with wiring diagrams as their programs. Without diagrams, maintenance would be a nightmare. Similarly, car enthusiasts can customize their ECUs, but regular users access diagnostic features. Maintenance personnel benefit from user-friendly interfaces in ladder programs, just like OBD2 scan tools for cars.
When designing industrial systems, it is crucial to consider the end user who will interact with the ladder program. Providing detailed descriptions and logical structures can improve usability, making the code function more effectively as a user interface.
Arpus4KM emphasized the importance of having comprehensive wiring diagrams for machines in the past. These diagrams served as the "program" for the machine, crucial for maintenance electricians to navigate. Without clear diagrams, dealing with equipment would become a nightmare in the future. In addition to diagrams, indicator lamps were used to identify errors, simplifying troubleshooting. However, the lack of detailed documentation on how a machine operates poses challenges for maintenance and future users.
Considering the industrial perspective, Arpus4KM highlighted the significance of creating ladder programs with user interaction in mind. Properly documenting code, including descriptions, tag information, and a logical structure, enhances user-friendliness. While thorough documentation may not improve the functionality of the code, it serves as a crucial interface for users interacting with the program in the future. Neglecting proper documentation risks confusion and inefficiency, emphasizing the importance of writing and documenting code correctly.
Cardosocea mentioned that in the past, lamps were used to signal errors and the relay indicator was often enough to understand the machine's operation. Despite this, there is typically a lack of documentation or diagnostic information provided for machines, which can be problematic for both operators and customers. This difference between operator and maintenance interactions highlights the importance of using lamp indicators and wiring diagrams for troubleshooting physical issues in the system. This concept of unexpected errors being likened to a "bug" in the machine, as coined by Grace Hopper, still holds true. Older relay logic machines were not necessarily simpler, and could be more challenging to troubleshoot without comprehensive layout and documentation compared to today's digital systems.
Cardosocea argued that the maintenance personnel should be familiar with ladder logic due to the lack of diagnostics in the systems we create. Just like how we don't have access to the ECU code in our cars or phones, limiting our control over them. An example of this is not being able to modify our phones despite owning them. Car manufacturers use safety as an excuse to restrict access to diagnostic information, forcing us to rely on expensive dealer tools for simple repairs. As technology advances, manufacturers may push updates without our consent, potentially altering the functionality of our vehicles. The focus should be on providing maintenance personnel with user-friendly interfaces, like the ones used by Ford service technicians and Apple refurbishment specialists, to effectively troubleshoot issues without requiring specialized knowledge.
It is not accurate to say that smartphones automatically update themselves. However, my phone alerts me when there is an update available and I choose to update it for potential improvements. OBD scanners can be bought for under £20. I own two different types - one is standalone while the other connects to a PC via USB. In my experience, these scanners outperform the ones used at my nearby garage.
Strantor mentioned how different perspectives can shape consumer preferences when it comes to purchasing products. Some people prioritize functionality and ease of use, while others prioritize customization and control. For example, when it comes to choosing between an Android and an iPhone, the price may not differ much, but the user experience can vary significantly.
Additionally, Strantor expressed frustration about not feeling like a true owner of a high-priced phone due to forced updates and restrictions imposed by the manufacturer. However, it's important to consider the legal implications and the balance between consumer rights and manufacturer control in such situations.
Similarly, the automotive industry faces challenges with proprietary diagnostic tools and software, leading to increased costs for consumers. The concept of over-the-air updates and minimalist interfaces in vehicles may limit the visibility of essential information for users, emphasizing the designer's preferences over practicality.
In contrast, alternative solutions like OBD scanners offer a more user-friendly approach to vehicle diagnostics, providing quick and accurate information without the need for specialized knowledge or expensive tools. This reflects a shift towards empowering users and technicians with accessible tools for maintenance tasks.
Ultimately, the goal is to streamline maintenance processes and improve operational efficiency by investing in user-friendly interfaces and tools that benefit both users and maintenance personnel. This approach not only enhances productivity but also reduces overall costs associated with maintenance operations.
When maintenance has to refer to the PLC code to diagnose why a machine is not operating, it reflects a significant oversight on the part of the programmer. A well-designed PLC and HMI program should clearly indicate the cause of the machine malfunction. In my programming approach, I utilize standard-FBs to send commands and receive status information, which can be reused multiple times. While it is possible to implement multi-layered FBs (such as Siemens' "multi-instance"), I prefer to stick to embedding only timers as multi-instance elements. These standard-FBs are straightforward and have been thoroughly tested, minimizing the need for troubleshooting once they are implemented. By using these standard-FBs as building blocks, I establish the foundation for a larger program, similar to assembling Lego bricks. Would this approach be considered Object-Oriented Programming (OOP)?
I concur with Jesper's opinion. In a recent incident, a machine experienced a fault, and shift engineers spent hours trying to troubleshoot it without success. Despite their training and efforts to analyze the code on a laptop, they were unable to identify the issue. When I was brought in, I quickly went to the alarm page and discovered that the problem was related to low air pressure, specifically the pressure switch on the main air line. This situation highlights the importance of having access to relevant information during problem-solving. In terms of Object-Oriented Programming (OOP), it can be argued that Function Blocks' (FB) Add-On Instructions (AOI) incorporate concepts such as Abstraction, reusable classes, and other programming elements.
In response to Jesper's comment, Parky shared a story about a machine malfunction that stumped shift engineers for 5 hours, despite their efforts to troubleshoot using a laptop and code analysis. When Parky arrived, he quickly identified the issue as "AIR PRESSURE LOW" due to a faulty pressure switch on the main air line. This incident raises the question of the effectiveness of alarm systems in industrial settings. Are there too many alarms to be easily managed? Do alarms reset, potentially causing them to disappear before a technician can respond? In maintenance work, it is essential to conduct thorough inspections before turning to technology like PLC connections. Opaque systems that rely solely on online monitoring can lead to overlooked solutions that may be as simple as checking breakers or fuse break indicators. In one case, a new facility experienced issues left over from the commissioning process, which reinforced the belief that all problems were PLC-related. This situation highlighted the importance of both thorough examination of physical components and the competence of maintenance personnel.
Implementing multiple instances of an FB does not adhere to Object-Oriented Programming (OOP) principles, as it lacks a class hierarchy. In OOP, the program structure revolves around classes, where everything is encapsulated within them. It is crucial to design the class hierarchy before beginning to write any code, as without classes and class instances, OOP cannot be achieved. PLC programs rarely utilize OOP concepts, making it challenging to draw comparisons. The difference between a program written in C versus C++ or Java is significant, with OOP being prevalent due to its numerous benefits. In the 90s, grasping OOP was difficult and time-consuming, but with perseverance, it can be achieved.
During my 16 years of experience, we encountered few major issues that required extensive diagnosis. Most of our time was spent on preparation and installation of new parts. One particular instance stands out when a worn-out valve actuated cable caused disruptions in the ASI system. It was a challenging task to locate the issue as the cable's position was far from the valve, making it difficult to pinpoint the exact location among the 64 ASI nodes. On a related note, I mentioned it could be perceived as Object-Oriented Programming (OOP), although my programming background includes Basic, C++, assembler, Pascal, indicating minimal differences between them.
Cardosocea inquired about the number of alarms present and raised concerns about the alarm system's reset function potentially causing alarms to not trigger when needed. It is crucial that alarms remain active if the condition persists, even after acknowledgment, with a clear indication on the HMI.
In a new facility undergoing commissioning, lingering issues may become the norm. To address this, consider implementing alarm muting functions on the HMI, with secure access via password. Any muted alarms should be prominently displayed on the interface.
During times when the programmer is off-site, ensure there are no external forces acting on the PLC, regardless of the commissioning status of the plant.
Most HMIs feature a function that displays either a flashing or steady alarm banner, or a symbol that flashes or remains steady to indicate the presence of muted or active alarms. This is a common standard across many systems and has been a practice I consistently follow. These alarm indicators are typically shown on all pages of the system.
Life asserts that Object-Oriented Programming (OOP) relies on the existence of classes and class instances. But, isn't an FB essentially a class? According to the definition, a class serves as a template for methods and variables within a specific object type. Therefore, an FB can be considered a class, with its instances being instances of that class. It's not just about the mechanisms like polymorphism and inheritance, as many now favor composition over inheritance. Even in languages like C and C++, one can achieve encapsulation benefits akin to those in C++. JesperMP suggests that alarms should remain active until the underlying issue is resolved, regardless of acknowledgment. Imagine if all systems were programmed this way - it would have made managing tasks a lot easier.
arpus4KM pointed out a common issue in PLC programming - the misconception that PLCs are inaccessible computers. In reality, the program and ladder can be considered a user interface layer essential for troubleshooting unique systems. This layer should be built like a mobile application, allowing users with minimal PLC experience to easily navigate and make necessary changes.
Experienced PLC programmers emphasize the importance of well-organized code and thorough documentation. This ensures that maintenance personnel can diagnose and fix unexpected issues that may not have been anticipated by the manufacturer. Maintenance teams are more forgiving when they can understand and follow the logic of the code, even in complex situations where the machine stops without clear indication.
While concise programming using AOIs and UDTs is beneficial, it should not come at the expense of clarity and usability. Ultimately, the goal is to empower maintenance teams to troubleshoot effectively without the need for constant intervention from programmers. This perspective is based on personal experience, and it's important to consider various opinions and approaches in PLC programming.
Parky mentioned that their phone notifies them of updates and requires their manual intervention to update it. They prefer to update their phone as it generally leads to improvements. However, if you frequently postpone the update by selecting "later" without choosing "no" (which is no longer an option), you may end up irritating the system. Eventually, the system may automatically force your phone to update at the most inconvenient time possible. It is important to stay up-to-date with phone updates to ensure optimal performance.
In contrast to the perspective shared by cardosocea, I believe that prioritizing maintenance tasks such as inventory management, cleaning, and planned maintenance over troubleshooting PLC code is crucial for efficient machine production. Investing in an additional $1k for this purpose can lead to cost savings within the first year of machine operation. This approach not only streamlines maintenance processes but also reduces dependency on specialized skills within the maintenance team.
While the idea of a perfect world where all faults are indicated on the HMI may seem ideal, it is not always realistic. Programmers who claim to have identified every possible issue without the need to access the code may either lack experience, have a service contract, or have a tendency to overlook unforeseen issues. The complexity of larger systems with numerous I/O and sensors increases the likelihood of encountering unknown problems, particularly in the case of custom-built machines.
Contrary to popular belief, an FB is not an OOP class, but rather a structured programming function. It is important to understand that simply using C++ does not guarantee OOP programming - without a class hierarchy, you are essentially coding in C. Transitioning to OOP can be challenging for programmers as it represents a new and advanced level of programming. However, this concept has not yet been fully incorporated into PLCs.
In an ideal world, all machines would operate flawlessly with no need for programming adjustments. However, in reality, machines often face various issues, from outdated hardware to unauthorized modifications by operators. These challenges can lead to unforeseen bugs, system malfunctions, and the need for constant updates.
In the real world, hardware is used well beyond its intended lifespan, leading to compatibility issues and reliance on outdated components. Programming changes are made by inexperienced interns or low-cost programmers, causing new problems to arise. Operators may also take shortcuts to speed up processes, compromising the machine's performance and safety.
Furthermore, plant modifications and product line changes often require machine adjustments that are not always within budget. This results in makeshift solutions that may pass quality control but are not sustainable in the long run. Additionally, IT requirements for cybersecurity updates can disrupt older systems, leading to compatibility issues and the need for extensive rework.
While the idea of a flawless machine operation for a decade is appealing, the reality is that machines frequently encounter complex challenges that require constant attention and maintenance. The reluctance of manufacturers to share proprietary code adds another layer of complexity to the maintenance and management of industrial machinery.
cardosocea expressed the desire for maintenance teams to focus on inventory, cleaning, and planned maintenance tasks instead of having to troubleshoot through PLC code to identify production issues. This sentiment resonates with the belief that developers may overstep their boundaries by dictating how equipment should be managed. The idea of reducing the skill set required for maintenance staff by streamlining processes is appealing, especially for in-house operations. However, if these decisions are made with the intention of creating dependency on the original equipment manufacturer (OEM), it raises concerns about the transparency and accessibility of essential information. The practice of hiding, complicating, or encrypting programming to maintain control over maintenance procedures is a contentious issue that challenges the principles of open communication and cooperation within a maintenance team.
When maintenance staff need to delve into the PLC code to troubleshoot why a machine is not operating, it indicates a significant oversight by the programmer. An effective PLC and HMI program should clearly identify the issue causing the machine to malfunction. It is essential to acknowledge that if maintenance personnel are unable to access the PLC code to diagnose the problem, it also reflects a failure on the part of the programmer. This issue is often exacerbated by OEMs restricting access to the code through password protection, as well as utilizing programming language and structures that are not easily understood by most maintenance staff.
I believe that the advanced monitoring tools found in PLCs can sometimes lead to a lack of thorough diagnostics and documentation within the industry. This can create a cycle where shortcuts are taken during machine development, leading to a lack of budget for essential extras like diagnostics. As a result, companies that prioritize these features may struggle to compete or have to offer them as add-ons, which end users may not be willing to pay for. It's important to remember that going online for troubleshooting should be a last resort, not the first step. In our industry, there seems to be a disconnect between expectations for understanding system failures compared to other technology, such as troubleshooting Windows debug mode.
According to lfe, an FB is not an OOP class, but rather a structured programming function. However, an FB can also be considered a data structure template, with its instances serving as data structures, much like a class in OOP. In essence, both an FB and a class can function as a UDT, as without any logic within them, they would lose their purpose.
In response, strantor raised concerns about the mindset that leads developers to make poor decisions, particularly regarding maintenance tasks. It is crucial for maintenance to be proactive rather than reactive, as it ultimately translates to increased uptime for profit-generating machinery. This sentiment is widely shared amongst those who rely on machinery for their livelihood.
Regarding the design of programs, strantor emphasized the importance of clarity and ease of understanding, especially for maintenance personnel. The idea of intentionally making programs difficult to decipher or encrypted goes against the principle of efficiency and collaboration.
Conversely, mk42 expressed a different perspective on the use of monitoring tools in PLCs, suggesting that they may lead to complacency in diagnostics and documentation. This may result in machines being left unfinished, creating a potentially hazardous situation.
In troubleshooting, it's important to remember that going online should be the final step, not the first. It's better to keep it as an option rather than being completely locked out or unable to use it due to complexity. Understanding how to operate it shouldn't require expert knowledge akin to working at spaceX. I stand by my original statement that perfection is rare, and the majority of manufacturing operates reactively rather than proactively.
Cardosocea expressed their need for well-documented and easily readable programs, along with sufficient diagnostics in an interface to eliminate the need for a laptop. I share the same requirements, indicating a mutual agreement. There may have been a misunderstanding in interpreting previous comments. It appeared that there was a preference for object-oriented programming (OOP) over the traditional ladder arrangement, with a suggestion that those who disagreed were hindering progress. I have been opposing these ideas, but if this is not the case, I apologize for the misconception.
Cardosocea explained that an FB, or Function Block, can be compared to a class in Object-Oriented Programming (OOP). Both FBs and classes serve as data structure templates, storing data internally like objects. While FBs do not have methods officially, they can be used to trigger various functions related to the data stored. Some FBs can be complex, resembling classes but without inheritance concepts. However, there are OOP extensions in ST that are not widely supported by manufacturers.
Arpus4KM shared the perspective that 95% of manufacturing is reactive rather than proactive. Balancing customer demands with the practicality of implementing advanced features like diagnostics can be challenging. It can be tempting to cater to customer requests even if they may not fully utilize the features, reinforcing inefficient practices.
In a discussion, Strantor expressed interest in both simplicity and the potential of Object-Oriented Programming (OOP). There was a misunderstanding regarding the perception of a straightforward ladder logic being outdated and OOP being the way forward. Upholding the importance of well-formatted code and thorough documentation, it is acknowledged that OOP offers benefits but may not always be superior to traditional coding techniques.
While some see OOP as essential for modular thinking, it is argued that Function Blocks (FBs) and Add-On Instructions (AOIs) can achieve similar benefits. This alternative perspective challenges the necessity of OOP for many applications, emphasizing the practicality and effectiveness of existing methods like FBs.
In a related conversation, it was suggested that FBs could be likened to classes, not OOP. Despite similarities in data storage and function triggering, FBs lack key components of OOP such as inheritance. It's important not to conflate the two concepts to avoid confusion.
Another point raised is the dilemma of meeting customer demands while not enabling inefficient practices. The necessity of winning bids and accommodating clients sometimes conflicts with the desire to promote best practices in control systems engineering. Companies face challenges in balancing client expectations with the need for skilled professionals to drive industry standards. However, a shift is being observed as more organizations recognize the value of having expertise in this area.