Ready to Optimize Your Maintenance? 🚀 Try It Free
I have encountered a new concept in ladder logic where an OTE is placed in the middle of a rung. This is unfamiliar to me and I am curious about how it functions. Is the XIC condition necessary for the OTE to be true? Will the timer only run when both the XIC and OTE conditions are met? How does the timer affect the logic of activating the OTE? Your insights would be greatly appreciated. Thank you.
In this scenario, the OTE does not impact the timer's operation. The OTE will mirror the condition of the preceding rung.
In Controllogix programs, a widely used method is utilizing the ------EQU------+---------+-------------------( )----| A| || B| |+-----------+ +--] [---+-TON----------+-| MYTIMER || PRE || ACC |+-------------- + function, which achieves the same result in a more efficient manner. This approach requires three fewer instructions to program effectively.
What is the general consensus on this practice among the public? Personally, I find it to be unacceptable. Am I alone in this sentiment? I am more accustomed to viewing ladder logic as opposed to relay logic. Is the minimal number of instructions it saves truly worth it in the end?
Although I have utilized it occasionally, it seems that the electricians responsible for maintaining it do not find much value in it.
Timbert raised the question: "What is the general opinion on this practice?" Personally, I find it appalling. Am I alone in this sentiment? I have always been accustomed to traditional ladder logic, similar to relay logic. Are the minimal instructions it saves truly beneficial? I wholeheartedly agree. Perhaps it's just a matter of being more old-fashioned in my approach.
In a ladder logic diagram, an OTE (Output Energize) instruction will activate its associated output whenever the conditions leading up to it on the rung are true. If the OTE is in the middle of a rung, the conditions after it do not influence its operation. So in your case, if you have an XIC (Examine If Closed) condition ahead of the OTE then yes, the XIC condition has to be true for the OTE to be energized. The timer you mentioned only starts running when the preceding conditions are true, regardless of the OTE status. It's really independent and its purpose is to introduce a delay or control an event for a specified period of time. Hope this helps clarify things for you!
In ladder logic, it's not uncommon to see an Output Energize instruction (OTE) in the middle of a rung. Generally, the XIC condition must be true to activate an OTE. However, the OTE doesn't have to be true to run the timer. The timer runs as long as the conditions leading to it are true, regardless of other outputs (such as an OTE further down the line). Essentially, the OTE and timer operate independently within the same rung. The timer's primary role is to delay or define periods within the logic, it doesn't directly influence the activation of the OTE. Hope this helps clarify things.
I wouldn't recommend visiting that place. I am amazed that a structure like this is able to withhold weight and support.
While I agree that prioritizing code readability over saving a few bytes is essential, I have found instances where utilizing series of OTEs at the end of a rung helped solve certain programming issues efficiently. It's important to strike a balance between optimizing code and maintaining readability for better functionality.
I really appreciate your effort, but I am not a fan of it as I already have enough challenges to deal with. The reasoning behind this decision seems questionable and I prefer the OTEs at the conclusion.
While some may not consider it ideal, there are instances where this feature greatly enhances code readability. Picture a scenario where 16 MOV instructions need to be executed - if neatly organized into 4 rungs of four instructions each, they can all be easily viewed on a single screen. However, if spread out across 16 rungs, it becomes cumbersome to navigate through multiple pages. This is why I believe there is merit in utilizing this feature. That being said, I discourage creating a convoluted mess of code with numerous branches and scattered outputs just for the sake of efficiency. Unfortunately, some programmers take pleasure in crafting code that shocks and surprises, perhaps for the amusement of future developers who come across it. While it may provide a moment of intrigue, the long-term impact on code maintainability and readability should not be overlooked.
I heavily rely on PLC programming software for my projects. I have grown frustrated with using RSLogix500 due to its limitations in allowing complex structures. It is crucial to remember that PLC programming is about creating instructions, not drawing electrical diagrams. Trying to visualize ladder logic as a circuit diagram can make it more difficult to solve problems efficiently. By understanding how instructions are executed, you can write code that is more readable and compact. This approach, demonstrated by Paul's example involving MOV instructions, improves code efficiency. I prefer to have a comprehensive overview of the logic in my programs rather than scrolling through excessive amounts of code. By optimizing the layout and condensing logic onto a single row, you can increase the amount of information that can be easily processed at a glance.
It's perfectly acceptable. The reasoning is sound, far from being considered an "abomination". Isn't it similar to using cars over horse-drawn carriages or spreadsheets over an abacus? Technology progresses, and it's important to adapt along with it. Otherwise, one risks being stuck in a certain era, unable to move forward or try new things. Timbert raised the question: What are people's general sentiments towards this practice? Personally, I find it distasteful. Am I the only one feeling this way? I'm accustomed to viewing ladder logic just like I would traditional relay logic. Is the small amount of time saved really worth it in the end?
While some RLL programming packages may mistakenly consider a data move instruction as an output, it is important to prioritize maintaining standards over resistance to change. Finding a balance between adhering to standards and promoting innovation requires compromising to ensure overall efficiency and effectiveness in programming.
In the world of RLL programming, the concept of a data move instruction being classified as an output has been a point of contention. Some argue that it falls into the same category as instructions that write values into memory or registers. For instance, an OTE instruction writes either a 0 or a 1 into boolean memory, while a MOV instruction transfers the value of one memory/register into another. Despite the distinction, both operations essentially involve writing values. The debate over whether these instructions are considered outputs ultimately boils down to how "output" is defined. Some argue that both OTE and MOV instructions can be considered outputs due to their writing nature, while others believe otherwise. However, the core function remains the same - writing values into memory/registers. When it comes to resistance to change in programming standards, the key issue is finding a balance between adhering to established norms and embracing innovation. Some resist change out of a desire to maintain standards, while others fear deviating from familiar practices. Nevertheless, progress should not be hindered by adherence to outdated standards. It's essential to evolve with the times and embrace new approaches, even if it means reprogramming oneself. While standards serve an important purpose, they can sometimes become outdated and overly restrictive. Striking a balance between tradition and progress is a challenge, as standards often lag behind technological advancements. It's crucial to avoid getting bogged down by unnecessary details and instead focus on practicality and efficiency. Embracing change and innovation is vital for staying relevant in the ever-evolving world of programming.
Siemens S7 offers the same functionality as its counterparts. Rather than using --()-- in the middle of a rung, it uses --(#)-- instead. This feature is widely used in various applications and is essential for efficient operations. Understanding electrical diagrams is crucial, as it is similar to tapping voltage in the middle of a circuit to drive a relay. DamianInRochester raised a valid point about lengthy standards documents affecting the bidding process. It would be more efficient if companies specified industry standards and regulations, along with a concise list of specific requirements. Oftentimes, the actual needs of the project are minimal compared to the extensive specifications provided. It is important to prioritize the key wishes of the stakeholders rather than getting lost in unnecessary details.
My journey in programming began with my first Fortran program on punch cards, and I have been hooked ever since. While my official title may not be programmer, my primary role is that of a control system designer. This entails programming various systems like PLCs, DCSs, SCADAs, HMIs, and more to bring our customers' concepts to life. It is crucial that anyone, whether a programmer or technician, can easily grasp the logic behind the control systems I create for troubleshooting or upgrading purposes. Over the years, I have learned the importance of balancing simplicity and efficiency in programming. It is essential to have clear and concise logic that is easy to navigate, especially during system downtime. Our ultimate goal is not just manipulating data, but creating tangible outcomes in the real world. Our work impacts the production of goods, safety of individuals, and livelihoods of families. When we are no longer here, it is vital that others can quickly understand and continue the work we have started. Therefore, it is crucial to prioritize clarity and functionality in our programming efforts.
What message did JHarbin just send?
JesperMP questioned JHarbin about the importance of programming with purpose.Click to see more. The debate revolves around whether one should simply code because they can, or if it is beneficial to consider the bigger picture. Some argue that if the program works, then there's no need for further analysis. However, others suggest that understanding the underlying logic of the PLC is crucial. My response aligns with the sentiments expressed in previous posts. If you disagree, that's perfectly okay.
I strongly dislike the complexity of debugging a machine with a ladder logic rung containing two screens of logic. It is incredibly challenging to troubleshoot. In terms of maintenance, individuals who cannot wire a machine should not be tasked with programming it. Our department has established rules banning this type of programming, which will not be allowed in our plant moving forward. Regards, James.
Timbert inquired about the general public's perception of a certain practice. Personally, I find it to be unacceptable. Am I the only one feeling this way? I am accustomed to traditional ladder logic similar to relay logic, so the switch to a different coding style makes me skeptical. However, upon closer inspection, I realize that transitioning to a new approach is essential when developing applications for modern controllers. This programming style is a necessity due to the distinct operation of CPUs that allow it. Adapting to this style is crucial for utilizing the advanced features of these controllers efficiently. Ignoring this transition would only lead to inefficiency and underutilization of resources.
According to James Mcquade, debugging a machine with complex logic can be a challenging task. He expressed frustration with having to debug a program with multiple layers of logic on a single rung. The idea that writing inefficient code is tied to using series OTEs is a misconception. While it is true that some programs in RSLogix500 may be poorly written, well-organized and readable code can still be created using series OTEs. Regarding maintenance, Mcquade suggests that if someone is unable to wire a system, they should not be able to program it. However, it is important to note that a ladder program is not the same as a circuit diagram. The sequential execution of instructions in a ladder program differs from the behavior of electrical circuits. This distinction is a fundamental concept in engineering, as highlighted in Ron's boot camp teachings.
DamianInRochester stated that there are two main types of instructions in programming: those that "test" memory/register values and those that "write" values to memory/registers. Despite some differences in functionality, both OTE and MOV instructions ultimately perform write operations on memory. Resistance to change in programming methodologies can stem from a desire to stick to familiar frameworks or outdated standards. While standards are important, they should not hinder progress and innovation in programming practices. Finding a balance between adhering to established norms and embracing new ideas is key to advancing in the programming field. Ultimately, it is crucial to evolve with the times while also respecting the foundations of programming principles.
The timing of this conversation is quite interesting. Just yesterday, I sent some code for review to a potential new client that included series OTE instructions. They mentioned that they are transitioning from Logix500 to Logix5000 and would prefer to avoid using it in their projects due to concerns about their electricians' familiarity with it. In my over a decade of experience with Logix5000, this is the first time a client has requested limitations on its usage. I assured them it wouldn't be an issue. They also expressed interest in incorporating sequencer instructions instead.
In a recent discussion, jstolaruk shared an interesting experience regarding a potential new customer's preference for programming instructions in their projects. The customer, transitioning from Logix500 to Logix5000, expressed a desire to avoid using series OTE instructions due to concerns about their electricians' familiarity with it. This request was a unique one for jstolaruk, who has over a decade of experience with Logix5000. While accommodating the customer's preference, jstolaruk found it intriguing how limiting the use of certain instructions can impact a project's capabilities. This situation highlights the importance of personal or corporate programming preferences in project development.
Inquiring about the limitations of programming OTEs in series may seem restricting, but in reality, it is a matter of personal or corporate preference. Restricting the use of certain instructions in a project may limit its capabilities, but it is essential to note that RSL5000 software stands out for its capability of utilizing OTE instructions in series, which sets it apart from other programming software options available in the market.
According to jstolaruk, the RSL5000 has the unique capability of using OTE instructions in a series, a feature that many other programming software packages lack. However, it is important to note that while BMWs are able to transport manure in their trunk, it is not recommended as it may restrict the vehicle's overall capabilities.
Do you enjoy playing word puzzles? I haven't criticized your initial comment in this discussion, so why criticize mine? I stand by my words and provided a clarification for better comprehension. Let's leave it at that.
According to James McQuade, having the ability to wire a system is essential before being able to program it effectively. This makes it necessary to approve of an OTE in the middle of a rung. It is a common practice in electrical circuits and is often done without much thought.
jstolaruk expressed surprise at the suggestion of playing word games. While they had not questioned the initial post in the thread, they were confused as to why their own post was being targeted. After clarifying their statement for better understanding, they stated that their intention was not to cause offense. The discussion in the thread had shifted towards the dos and don'ts of programming, with jstolaruk emphasizing the importance of writing code that is easy to interpret and troubleshoot. They shared their personal practice of avoiding certain instructions that may complicate the readability of their programs. Mentioning their aversion to programming OTEs in series due to the potential confusion it may cause, jstolaruk highlighted the need for code to not only function effectively but also be comprehensible to others who may review it in the future. They acknowledged the customer's perspective in wanting clarity in the program and apologized for any unintended offense caused in the conversation.
Apologies, JHarbin, your apology has been accepted. I wholeheartedly agree with the sentiments expressed in your post.
In a recent discussion, jstolaruk shared an interesting experience with a potential new customer. The customer expressed hesitation in using series OTE instructions in their projects as they transition from Logix500 to Logix5000, citing concerns about their electricians' familiarity with it. This was a rare request for jstolaruk, who has over 10 years of experience with Logix5000. The customer then mentioned their interest in using sequencer instructions instead. This situation could be frustrating, as jstolaruk would typically charge for such changes unless specified beforehand. It is important to avoid unnecessary changes, as constantly altering systems without valid reasons can be detrimental. In today's technology-driven world, simplicity may not always be the best approach due to the complexities of modern systems and processes.
I'm sorry Paully, the code I sent for review was previously used on a GM machine for a different client. I wanted to demonstrate my programming skills to a potential new customer as promised.
Paully's5.0 mentioned how frustrating it can be when customers request constant changes without valid reasons. In such situations, it is essential to provide a change order to cover the additional costs. Today's systems are becoming increasingly complex, making it challenging to rely solely on the KISS (Keep it simple, stupid) method. Despite the challenges, it is important to remember that while the customer may not always be right, they always remain the customer. This highlights the importance of addressing customer needs and concerns effectively.
"The importance of customer satisfaction is paramount, even in situations where the customer may be mistaken."
While the saying goes that the customer is not always right, they are the ones who ultimately determine the success of a business by signing the check.
DamianInRochester emphasized the misconception that writing poorly structured code is linked to the use of OTEs in series. While it is possible to write messy code without utilizing series OTEs, it is also possible to create organized, straightforward code with them. It is important not to equate the two concepts. Ladder logic is not the same as a circuit diagram. Even without the complication of series coils, the programming and wiring processes are not identical. Ladder programs do not function in the same way as electrical circuits do. This fundamental principle is emphasized in Ron's boot camp, with numerous examples demonstrating why this misunderstanding is flawed. Although ladder logic was initially designed to be a programming language that plant electricians could troubleshoot, advancements have led to additional functionalities. However, if programming is not done with electricians in mind, then using ladder logic may not be efficient. While tasks in PLCs could be completed much faster in C++, it may not be user-friendly for electricians. Ultimately, creating a balance between efficient programming and user accessibility is key.
Sequencers are an essential tool for electronic music production enthusiasts.
The PLC expert expressed frustration over the limited speed of tasks conducted in PLCs compared to the efficiency of C++. Although C++ is quicker, it is not user-friendly for electricians. This can pose challenges during startup and debugging processes. The Plc Kid can relate firsthand to these obstacles.
jstolaruk expressed difficulty during start-up or debug, but I have to disagree. I have successfully performed this task multiple times on systems where a PLC was inadequate. It is possible to troubleshoot and debug despite challenges during the start-up phase.
I strive to utilize a programmable logic controller (PLC) extensively in my work and aim to write code in a manner that can be easily understood by electricians and maintenance technicians, even in the middle of the night. While I may not necessarily enjoy working solely in computer languages, I acknowledge its feasibility. One of the advantages of utilizing a PLC is the assurance that it cannot be altered by unauthorized personnel on site, making it easier to pinpoint and troubleshoot issues with field devices.
If you need to halt operations, modify a program, download updates, and then reboot, it's feasible for a small independent app. However, for larger projects, this process can consume significant amounts of time.
My last project had around 2400 input/output operations. Out of all programming languages I know, ladder programming is the least efficient for me in terms of development speed.
The PLC expert mentioned that the previous project had around 2400 I/O, which he considered low. He admitted that ladder logic is his least preferred programming language in terms of development speed. He asked if the machine with 2400 I/O was programmed entirely in C++.
It's truly remarkable to see a system with a multitude of monitored inputs and mechanical outputs. Great job! Next month, I will be collaborating with three other independent contractors to program an assembly line for Ford, which will require a high number of inputs and outputs. We are adamant about using ladder logic supplemented with function blocks to ensure smooth operation without any interruptions for program changes. The stakes are too high to risk any delays in production. (Apologies for straying off-topic.)
The Plc Kid emphasizes the importance of coding PLCs in a way that can be easily understood by maintenance technicians even at 2:00 am. However, due to safety concerns, electricians at his company no longer have access to PLCs. The Plc Kid stresses that his PLC code is designed to ensure equipment functions properly, and if something goes wrong, it is due to a broken part. He urges technicians to use tools efficiently and adapt to new technologies for better performance. Sparky is encouraged to upgrade his skills or stick to traditional tasks until retirement.
In today's digital age, it is crucial to prioritize safety and efficiency in industrial operations. Electricians must have limited access to PLCs and should only use the program for troubleshooting purposes. If a machine malfunctions, the issue is likely due to a mechanical fault rather than a programming error. It is important to have a structured approach to maintenance, utilizing ladder logic and other programming languages to streamline the troubleshooting process. While personal preference and plant culture play a role in decision-making, it is essential to consider the long-term implications of our choices. By embracing new tools and techniques, we can minimize downtime and enhance overall productivity.
In certain situations, it may be necessary to limit access to the CPU's online functionality monitoring for those without proper qualifications. However, this tool remains essential for effectively troubleshooting modern automation systems. Permission settings can be easily adjusted, and visual code can be used to connect field devices to an "OK" OTE based on specific conditions. A skilled electrician or technician should be able to identify and resolve issues with a series circuit efficiently. Implementing HMI alarms for every component failure may not be practical for systems with a large number of I/Os.
dmargineau expressed doubt about the feasibility of implementing HMI alarming for each individual component failure in systems with hundreds or thousands of I/Os. The question arises: Is this statement realistically applicable in any practical setting?
In today's technology-driven world, HMIs have removed all barriers to identifying and showcasing faults, particularly on large-scale I/O projects. This advanced system ensures no fault goes unnoticed, making it an essential tool for industrial projects.
In today's rapidly advancing technological landscape, ensuring the safety and efficiency of PLC systems is paramount. It is crucial that electricians have proper access to PCs for connecting to PLCs without compromising safety protocols. Neglecting safety measures can result in potential lawsuits and operational hazards down the line. The primary purpose of PLC code is to optimize equipment functionality, not for the convenience of random electricians. When machines malfunction, it is essential to troubleshoot by examining the HMI, identifying faults, and promptly addressing any issues. Utilizing available tools efficiently is key to maximizing productivity. In some cases, PLC+HMI applications incorporate alarm systems for individual input devices to monitor performance and detect potential issues. Customizing systems based on customer preferences is standard practice, provided that all parties are well-informed about the implications of their choices. It is imperative to embrace new tools and technologies to adapt to evolving industry standards and optimize performance.
In all of our projects, regardless of size, we ensure that alarms are set up for all common error conditions, both simple and complex. Along with addressing basic issues, we also implement alarms for higher-level concerns, such as a lack of available space to unload a conveyor due to full bins or improper startup sequences. These proactive measures prevent potential problems caused by miscommunications or operator mistakes, ultimately minimizing downtime and confusion for plant operators. While this approach involves significant effort, it is crucial for ensuring smooth operations and prompts us to deliver quality service. Are there others in similar roles who also prioritize detailed error reporting and proactive problem-solving?
When it comes to resources, the human brain is crucial to the equation. If there are not enough available, it may be necessary to remove the "humanity" factor. Thousands of HMI alarm messages are only effective if the average operator can understand them. This level of detail is best left to competent developers and essential information systems.
Each alarm message provides clear and concise details about potential issues, such as "Pneumatic gate G3 not opening. Please check solenoid [=G3+H4-M1] and sensor [=G3+H4-B2], as well as the air supply and for any blockages." This information is designed to be easily understood by operators and maintenance personnel, ensuring speedy and accurate problem identification. If a maintenance worker struggles to interpret the error message and troubleshoot accordingly, they may not be qualified to work with PLC programs. Let's keep the focus on the topic at hand and avoid unnecessary distractions.
I find it engaging to constantly explore new programming techniques. Can someone provide a demonstration of how incorporating an OTE in the middle of a rung can be beneficial? Thank you! Learning new programming methods is always an enjoyable experience.
dbh6 expressed interest in learning new ways to program and requested a demonstration of the usefulness of using an Output Energize (OTE) in the middle of a rung. An example provided illustrates how utilizing an OTE in-line can significantly reduce memory usage and processing time. Rockwell engineered the Logix5000 systems with speed in mind, enabling various output functionalities to enhance processing power for demanding applications such as high-speed motion control. By implementing efficient programming techniques, like in-line outputs and series outputs, users can optimize processing time for complex tasks.
Thank you, @daba, for clarifying the number of instructions on the second rung. While you mentioned there are 7 instructions, I only counted 4. Is the parallel branch also considered an instruction since it operates as an "AND" function? Regardless, I appreciate the information and will definitely utilize this technique to simplify my logic in the future.
Bit_Bucket_07 mentioned that a data move instruction should not be considered an output, even though certain RLL programming software may treat it as such. The key issue lies in upholding standards, rather than resisting change. Balancing between standards and innovation always requires a compromise. I completely agree with the sentiment! One feature I believe should be added to the Logix editor is the ability to restrict the number of contacts and branches on a rung. This would encourage adherence to best programming practices among our contractors. Those who prefer a more flexible approach can simply uncheck the box and proceed as they wish.
In response to @daba, user dbh6 expressed gratitude for the clarification on ladder rungs. While dbh6 initially counted only four instructions on the second rung, it was pointed out that the parallel branch should also be considered an instruction due to its "AND" functionality. This insight will be helpful in simplifying logic. For a more detailed analysis, input this code into a program and double-click each rung. In the ASCII text editor located above the ladder window, you will be able to view the specific instructions utilized. The first rung includes instructions such as XICDrive_TrippedOTETripped_IndicatorXICReset_PushbuttonOTEDrive_Reset, while the second rung consists of XICDrive_TrippedBST OTETripped_IndicatorNXB XICReset_PushbuttonOTEDrive_ResetBND. This process will enhance comprehension and aid in optimizing functionality.
Thank you, Daba! Your feedback is appreciated.
Thank you for your comment, @dbh6. I personally embrace the flexibility of Logix5000's "de-restriction" of rung constructs, moving away from the limitations imposed by traditional electrical circuitry designs. While some may still adhere to the legacy viewpoint, I find it more beneficial to focus on the effectiveness of incorporating math comparisons and computational instructions in the code. Instead of viewing the code as resembling a relay panel, I interpret it through the eyes of the processor. Conditional instructions like XIC, XIO, EQU, LES, etc., have the power to alter the "Rung Logic Continuity," whereas unconditional instructions such as OTE, OTL, MOV, etc., do not have the same impact. In my practice, I often begin a rung with a MOV instruction to ensure that I am working with the most recent value in the MOV destination tag. This value may have been updated independently from the scan, either through I/O RPI or a periodic task. When organizing instructions on rungs, it is advisable to place those deemed most likely to be false at the forefront. This approach prevents unnecessary database retrievals once a conditional instruction turns a rung false. Similarly, prioritize input branches that are expected to be true at the top to streamline the evaluation process and avoid unnecessary database access. Moreover, it is essential to consider executing code only when necessary, which is where Periodic and Event tasks play a crucial role. By incorporating efficient methods to trigger specific events such as the start of an hour, day, month, new year, or changes in input states, the processor can allocate resources effectively to handle more critical tasks. By integrating these concepts and optimizations into your programming approach, you can enhance the efficiency of your code execution and enable the processor to focus on higher-priority tasks.
dbh6 commented on the intriguing discussion in the thread, expressing their continuous pursuit of innovation and enjoyment in exploring new programming techniques. They requested a demonstration showcasing the practical application of using an OTE in the middle of a rung. Can someone please provide an example? I have personally found similar techniques to be helpful in certain situations.
If the necessary tools are available, allow those who are proficient in using them to utilize them without hesitation. Surprisingly, no one has brought up comments yet. Personally, I am not concerned about the aesthetics as long as the commenting is thorough. The more intricate the task, the more important it is to provide detailed comments. This is crucial for us Electricians, especially during late-night emergencies. I often implement multiple RES in the middle of a sequence, such as to reset several timers or counters simultaneously. Be sure to include extensive comments! Now, I must attend to changing some light bulbs. Please excuse me.
There have been no mentions about commenting on this post yet. I believe that a well-thought-out comment adds immense value to the discussion. Click to expand and join the conversation. Well stated.
When it comes to dealing with technical issues, having updated documentation and receiving feedback in the form of comments is essential. I recently encountered a major headache while trying to address a problem at a tier 1 level, as my system has been targeted by hackers for the last decade. Unfortunately, the comments and documentation related to this issue are lacking and outdated. In order to effectively resolve the issues at hand, a significant amount of work needs to be done. Simply rewriting the program during a lunch break is not a feasible solution, as it is unclear what resources are available based on the existing documentation. Shutting down the production line is not an option, except during scheduled breaks, which could result in added costs. Despite the challenges presented, I am determined to tackle the issues and make necessary improvements to ensure everything runs smoothly. While this process may require additional expenses, I am committed to resolving the issue and potentially bringing in additional revenue for pharmaceutical companies. I thrive on challenges, up to a certain point!
@jstolaruk, your demonstration was excellent and really simplifies the logic. As many others have pointed out, if you have the ability to write logic in this way, why not? When I first encountered logic with an OTE in the middle of the rung, it was easy to understand by just applying the principles of XIO/XIC and OTE functions. It's pretty straightforward and neat. However, for less experienced users like maintenance personnel who may need to troubleshoot a machine issue at 2am, this type of logic may appear unfamiliar and confusing. In those cases, adding thorough comments to the program, as suggested by Geospark, can make a big difference. In my opinion, there can never be too many comments in a program.
A common occurrence I have noticed is Bubba examining the code at 2 am without prior coaching. It is essential for Bubba to gain hands-on experience with the code during regular working hours to prepare him for potential access at 2 am during critical times.
In essence, following Murphy's Law, "anything that can go wrong will go wrong." It's almost as if people are just looking for trouble.
When discussing topics related to programmable logic controllers (PLCs) and ladder logic programming, there are several key issues that often arise. Firstly, there is a misconception that utilizing the added flexibility of software like RSLogix5000 makes the code harder to comprehend and less readable. However, it is important to note that poorly written and disorganized code is what truly hinders readability and debugging, not the advanced features of the software. In fact, incorporating elements such as a series coil can actually simplify the code and improve its overall clarity. Secondly, when it comes to electricians, there are two main challenges that need to be addressed. There is a prevailing tendency to underestimate the capabilities of electricians while simultaneously expecting them to meet high demands. With the increasing complexity of modern machinery and technology, there is a growing need for electricians to enhance their skills and adapt to new advancements in the field. It is crucial to provide proper training and support for electricians to ensure they are able to effectively troubleshoot and maintain the sophisticated equipment they encounter. Additionally, the way in which electricians are trained plays a significant role in their understanding of programming and ladder logic. By teaching them the fundamentals of programming and emphasizing the importance of approaching ladder logic as a circuit diagram, electricians can develop a deeper understanding of the logic behind PLC programming. Lastly, it is essential to differentiate between the inability to understand a concept and the refusal to accept it. The resistance to embracing new methods, such as incorporating a series coil in programming, often stems from a lack of willingness to adapt rather than a genuine difficulty in comprehending the concept. By fostering a culture of openness to new ideas and approaches, we can encourage electricians to continuously improve their skills and stay current with the latest advancements in the industry.
The main concern I have regarding the series coil is not its complexity (which, let's be honest, is not that difficult to grasp), but rather the resistance some may have towards accepting it. Fortunately, this is not a problem for me, and I appreciate not having to deal with it.
In a recent statement, Lancie1 expressed relief that they do not have to face the issue at hand. This serves as a clear example of their perspective.
Are you looking for an advantage in your case? When RSLogix5000 was initially released, I decided to try out the demo version to familiarize myself with it. I soon discovered that this software was tailored more for high-level programmers in a quiet, controlled office environment, rather than for electricians working in the rugged conditions of a noisy plant like previous Allen Bradley programs. The developers seemed to have stripped away many real-world elements from the product. Since then, I have not shown much interest in it. Ultimately, it's all part of the competitive marketplace.
In my opinion, someone responsible for debugging a system should have the knowledge and skills to understand PLC code beyond just viewing it through a simple "contacts and coils" perspective. It is essential for individuals in this role to embrace new technologies rather than cling to outdated concepts like "mid-line coils." There are those who may resist these advancements, but they must learn to adapt in order to effectively work with PLCs. I recall encountering a PLC with inverted outputs in the past, possibly made by Telemechanique or Square D. How would someone limited to a narrow view of "contacts and coils" handle such a scenario? Training is essential for individuals like "Bubba" before they are granted access to PLCs, ensuring they understand the differences between relay logic and PLC ladder visualization. It is important to understand that the ladder diagram is merely a visual representation of a computer program that executes instructions sequentially. If "Bubba" were given a statement list equivalent of a sample rung, they should be able to comprehend its functionality. Those who struggle to grasp these concepts or refuse to accept them should not be permitted near PLCs.
When working with the GE 90-30 PLC using Proficy Machine Edition software, it's worth noting that it has inverted outputs. Upon first encountering this, one might question why the programmer chose inverted outputs over regular ones. While the reasoning may not be immediately clear, the fact remains that it effectively gets the job done.
When working with the GE 90-30 PLC using Proficy Machine Edition software, I discovered that it has inverted outputs. The first time I encountered this, I wondered why the programmer chose to use inverted outputs instead of regular ones. Although I couldn't find a specific reason, I must admit that it does the job effectively. I have utilized this feature to monitor multiple tags simultaneously, such as consolidating various fault tags into a single output.
The initial PLC software I utilized included Omron and Giddings & Lewis. Giddings & Lewis played a predominant role in my early projects, being pioneers in introducing unconventional programming capabilities for ladder logic. Their innovative approach included allowing all instructions to be in series, as well as incorporating NOT coils, P, N, NOT P, and NOT N contacts. What truly distinguished their ladder logic was the ability to create and download code that may have broken connections without affecting functionality. This feature enabled temporary disconnection of code segments without the need for deletion or additional disabling contacts. The grid-like layout of the ladder logic, resembling a spreadsheet, allowed for efficient code creation cell by cell, particularly if one memorized the hotkey combinations. I am intrigued about the software that first introduced the series coil instruction.
In many of the systems I have worked on, we have utilized a technique known as "Arbitration" to manage plant devices such as valves and pumps. The main goal of arbitration was to prevent SCADA interference with plant operations during a process sequence. Activating the arbitration control for these devices meant toggling numerous bits for each sequence, sometimes even exceeding 50 bits on a lengthy or intricate route. Visualize having to individually address each arbitration bit on separate branches or rungs – a tedious task indeed! Thanks to the series output capability of Logix5000, we were able to streamline this process by consolidating all bits on a single rung and utilizing "rung wrapping" on the display for easy access. Moreover, there are memory and speed considerations to take into account. Each branch adds an additional 3 instructions to the code, meaning that a branched setup for 30 coils would demand an extra 90 instructions, occupying memory and impacting execution efficiency. This approach not only depletes resources unnecessarily but also complicates code navigation. It may seem like we are underestimating Bubba's intelligence, as understanding a computer program displayed on a monitor should not be equated to a traditional relay panel with wires and terminals. Even early PLCs offered mathematical functions and comparison instructions that differ significantly from relay-based systems. Hence, it is reasonable to assume that Bubba can grasp the concept of an output "coil" instruction and its sequential or mid-line placement within the program.
I apologize for revisiting this topic, but I wanted to respond when I had the time and had cooled off a bit. It seems we may not be giving Bubba enough credit. It's possible for them to recognize that they are viewing a computer monitor displaying a computer program. It's unlikely that anyone would mistake it for a traditional metal box filled with relays and wires. As Homer J. Simpson humorously asked, "Where's the ANY key?" I find it interesting, rather than offensive, that there is a lack of confidence in "Bubba." I hope this term is used affectionately. There are numerous quotes I could reference from this discussion, but it's time to move on from the negativity. It's clear that not all electricians are as technologically challenged as some imply. In my experience as a contractor, I have encountered electricians with varying levels of proficiency. Some excel in domestic and commercial settings but struggle with industrial projects. Among those who are skilled in industrial work, a few show interest beyond basic tasks. However, truly knowledgeable PLC electricians are rare. I have also worked with subpar software engineers who lack attention to detail. One individual sent out faulty programs without properly commissioning them on-site. Their work was riddled with errors and flaws, causing significant issues. In contrast, a training session I attended proved to be a disappointment, with the instructor's lack of expertise in the specific platform being taught. Ultimately, there are both good and bad professionals in every field. As someone hired as a technician despite being an electrician by trade, I have diversified my skill set to include PLC programming. A thorough understanding of various tools and technologies can make an electrician more versatile and valuable in their work. In conclusion, everyone has their strengths and weaknesses. Some prioritize the technical aspects of PLCs, while others focus on practical application. Regardless, maintaining clear and organized coding practices is essential. Our company emphasizes the importance of easily understandable code, ensuring projects are well-documented and structured. In summary, Bubba's perspective offers valuable insights into the diverse skill sets and approaches within the electrical industry. It's essential to communicate effectively and maintain clarity in our work for the benefit of future readers and colleagues alike.
Geospark's insightful comments shed light on the importance of proper training in system debugging. It is crucial to avoid letting untrained individuals handle these tasks, as it can lead to various complications and safety issues. The term "Bubba" is not meant to be derogatory but rather refers to the individual tasked with maintaining and operating machinery without adequate training. While Bubba may not have the technical expertise of a trained engineer, he plays a vital role in keeping the production process running smoothly. Despite potential hiccups along the way, Bubba's efforts are essential for maintaining operations.
It's a missed opportunity that Rockwell doesn't recruit more talented software developers to innovate and shape the future of their technology. It seems they prioritize catering to high-level executives who sign off on major investments, neglecting the lower end of the market where other PLC developers are gaining traction. This customer-centric approach has allowed competitors to take a bite out of Rockwell's market share in the Allen Bradley space.
According to daba, the term "Bubba" is not intended to be derogatory. It is simply used to refer to the individual who may lack proper training on the equipment they are responsible for maintaining and debugging. Despite being perceived as "clueless," this does not imply that they are unintelligent. I was the first to use this term in this discussion, as it is easier to type than "Joe the average Maintenance Tech." Rest assured, no offense is meant by its usage. Bubba.
Hello everyone, Although this forum may be older, I wanted to share my thoughts on a topic that I found interesting. I came here seeking validation for my opinions and ended up learning a great deal from the community. I now understand that placing coils in the middle of a rung can lead to issues if not carefully considered. It is crucial to think before programming and testing thoroughly to avoid any potential troubleshooting challenges. However, when used correctly, a coil in the middle of a rung can enhance readability and efficiency. In my own experience, I found it necessary to add a condition to existing logic before allowing a part to move forward on a CV. The most straightforward way for me to achieve this was by placing a coil in the middle of a rung. Let me explain further. This particular rung controls the "Auto Start CMD" from CV 1 to CV 2, advancing the part to the next station. I needed to ensure that this advancement only occurred once a traceability signal was sent and received. By adding a "received" coil to the rung, I could easily accomplish this. However, the challenge then became triggering the action. While I could have created a separate trigger, it felt more natural to place a coil (Trigger) before the contact (Response). This allowed me to trigger the action only when necessary and immediately await the response. By having the trigger and response in close proximity, I eliminated the need to search for the trigger in case of a missed response. This approach also prevented the need to duplicate the entire logic before the coil, simplifying the process and ensuring logical consistency. I believe that maintaining logic sharing within a rung is crucial to prevent any discrepancies in case of future changes. While I could have isolated the new logic with a separate branch, it would have required additional work and potentially compromised the original design of the rung. By integrating a coil in the middle, I effectively established a handshake protocol. In regards to Logix, it's worth mentioning that [ONS]/OneShots/pulses are also considered coils, and in my experience, they are frequently positioned in the middle of a rung. This allows for flexible programming, such as pulsing one side and using the same tag elsewhere as a contact, which can be incredibly beneficial. Thank you for reading, and I hope this insight proves helpful in your own programming endeavors.
There was a certain individual at a previous workplace who consistently made errors in their coding, such as having the coil and unlatch instruction act on the same bit. They also had a tendency to use the same bit for both the last contact and coil in their coding. This individual is still causing issues in plants worldwide, despite their lack of competence in computer programming.
Cardosocea mentioned: "Click to expand...XIO1&XIC2&XIC3&OTE3." They explained that in a situation where the last contact and coil are identical, it can serve as a NOP instruction. This setup typically works by having the coil/last XIC bit triggered by the HMI when both XIO1 and XIC2 conditions are met. It remains latched until either XIO1 or XIC2 become false. This method is commonly used to latch HMI/IO buttons or signals.
PreLC noted that using NOP is one method of writing code. I recently encountered a system with numerous checks in place to ensure a particular bit remained active throughout the program. The bit would turn on immediately if both the MCR and Estop inputs were active. Following this, there were approximately 50 rings of checks that would assess various conditions and, if met, activate the bit. If any of the conditions within the rings were not met, the bit would be turned off. Additionally, these 50 rings were dispersed throughout the program.
PreLC mentioned that using a mix of latches is one method to write an NOP in a program. However, this approach can make troubleshooting difficult, as the bit will continue on only if the bit is on and the preceding bit is also on. Otherwise, it will turn off. Despite having logic elements that serve no purpose, this is how the system operates. This unique methodology has led to many integrators choosing not to work on this system, much to the dismay of my manager, who lacks knowledge of controls. The integrators refuse to work on the system, not due to cost concerns, but because they prefer to avoid the associated stress and complexities it brings to their work.
Resurrected like a Phoenix from the ashes, an old thread discusses the transition from electrical circuits to PLC logic. Initially praised for its simplicity, the ladder representation of code was deemed easy to understand for beginners. However, as PLC instructions became more complex, the distinction between computer language and hard-wired circuits blurred. Unlike physical hardware equivalents, PLC instructions exist solely as lines of code within a program. Despite the initial appeal of this analogy, some individuals continue to struggle with this concept even after decades in the industry. In my experience training with Rockwell, I emphasized that PLC instructions can be categorized into two types: those that observe a condition and those that carry out an action. Each instruction operates independently, solely dependent on the true/false state of the rung it is connected to. With the introduction of mid-line "coils" in the ControlLogix platform, I found them to be advantageous in terms of code efficiency and execution speed. These "do something" instructions solidify the logic flow, preventing unintended disruptions. Embracing mid-line coils in my projects, I have come to appreciate their benefits despite any reservations about their unconventional placement. As an industry veteran, my acceptance of modern PLC practices reflects my adaptability and continued growth in the field.
In all fairness, the individual mentioned was working with Siemens S5 coding, with some instructions later transferred to Rockwell that still reflect his familiarity with Siemens S5. Despite this, it's worth noting that he may have had experience with more advanced programming platforms. Personally, I have no issue with mid-rung OTEs or timers followed by the .DN bit.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Solve Your Operational Challenges with Oxmaint → Get Free Demo
Answer: 1. What is the purpose of placing an OTE in the middle of a ladder logic rung? - Placing an OTE in the middle of a rung allows for conditional activation of the output based on the state of other elements in the rung. 2. Is the XIC condition necessary for the OTE to be true when placed in the middle of a rung? - Yes, typically the XIC condition preceding the OTE must be true for the OTE to be activated in the ladder logic.
Answer: - The timer will run only when the preceding XIC condition is true. The OTE condition may affect the timing of when the output is activated.
Answer: - The timer's timing function is independent of the OTE activation. The OTE will be activated based on the state of preceding conditions, while the timer will run independently based on its own conditions.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.