Consider creating a state transition diagram for the code in your PLC to refer back to in the future. In some cases, maintenance HMI graphics have been designed to mimic a state transition diagram, allowing for easier navigation and understanding of possible options. If frequent reference to the PLC code is necessary for maintenance tasks, it may point to weaknesses in the HMI development. When called for service, I always strive to resolve issues using the HMI interface first, providing clients with transparency and empowerment in problem-solving. This approach ensures that clients are equipped with the tools needed to navigate issues independently, fostering trust and confidence in the service provided.
Introducing a unique feature in SWAG (Wild mode): a bit-wise sequencer known as "Step". This sequencer works by activating different steps, from Step.0 to Step.31. But what happens when you need to go beyond Step.31 in your sequence? There are various methods to tackle this challenge. One common approach (although not my preferred one) is to introduce a new DINT called "Step32", where Step32.0 represents step 32, Step32.1 represents 33, and so on. This workaround ensures that your sequence can continue uninterrupted.
I strongly dislike using bits as a sequencer because it limits functionality. Instead, opt for using an integer which can offer over 32,000 potential steps (though you likely won't need that many). To make editing easier, organize steps in banks of 10 or another convenient grouping so that inserting an additional step doesn't require rearranging existing ones. By using integers, most HMIs can utilize text lists to display the current operation or integrate with databases to load corresponding text based on the value. This setup also allows for easy navigation both backwards and forwards.
Is OP (@Maintenance Man) attempting to diagnose, analyze, or comprehend an existing program, or are they aiming to improve an existing program through refactoring? If they are facing difficulties with certain aspects, it is important to recognize that every step in a state machine consists of two components: the sequence logic directing transitions between steps and the business logic executed for each step. While these components may be intertwined in some cases, well-designed programs keep them separate to enhance readability and comprehension. If the process is halted at "Step_32," it is advisable for OP to investigate the sequence transitions from that step. However, without access to the actual code, our efforts are somewhat aimless.
Are you able to access the program online? If so, locate the logic by searching for the step number. I typically begin at step 1 to get acquainted with the program and machine sequence. Is step 2 activating? If not, identify the faulty part in the rung that is preventing it from progressing to step 2. Resolve this issue. Next, check if step 3 is activating. Continue examining the program to pinpoint the source of the problem. Eventually, you will uncover all the steps, possibly within the reset logic. - James.
I want to express my gratitude for all the insightful responses. I truly value the input provided. My apologies for any lack of clarity in my initial query. I was attempting to grasp the concept of a step 32 bit process. Our current program showcases the necessary logic that must be in place before proceeding to the subsequent step. Interestingly, within the same program, there exists a step 32 bit element, which appears to be a duplicate process. I've been informed that this redundancy is to maintain consistent logic while utilizing different memory addresses, allowing for the reuse of a lengthy step program in various instances without the need for extensive ladder rung inputs.
My primary query revolves around how to accurately determine the status of devices like push buttons and contactors within the program. Is it necessary to reference the tags for this information? It seems that troubleshooting may not be straightforward with this setup. I encountered a similar scenario in a recent program I examined. Once again, thank you all for your valuable assistance.
- 30-09-2024
- Maintenance Man
The presence of documentation and whether "AOI" is a standard can determine the significance of the link provided by RW. It may be necessary to review any available documentation to understand the functionality of the program. The RW program appears to have an HMI-accessible interface. If the sequencer was originally set up in a similar manner, it is possible that certain screens are password-protected or have been removed. Without information on the creator of the sequencer, providing accurate assistance is challenging. Siemens offered a sequence control with bits, primarily used by German engineers. It may be more efficient to create a customized solution, as deciphering the existing program could be time-consuming. If the program is not functioning properly, it is likely due to a condition not being met, such as a sensor error.
In the world of maintenance, one of the challenges faced is determining the status of devices such as push buttons and contactors. Knowing whether these components are on or off is crucial for troubleshooting processes. Ideally, this information would be easily accessible on a Human Machine Interface (HMI) screen, allowing for quick identification of any issues. However, if the HMI does not provide detailed information, accessing the Programmable Logic Controller (PLC) using software like RSLogix/Studio 5000 IDE in online mode is necessary. It is important to keep in mind that the displayed values in the IDE may not always match the real-time logic evaluation, so caution is advised. Additionally, when dealing with a common Add-On Instruction (AOI) handling multiple sets of discrete inputs, there may be a way to observe specific instances for a better understanding, although the process can vary.
When using a sequencer, I prefer to avoid using bits as it can be limiting. Instead, I recommend using an integer with potentially over 32,000 steps. You can easily group steps in banks of 10 to allow for inserting additional steps without having to rearrange existing ones.
By using an integer, most Human-Machine Interfaces (HMIs) can display the current operation using text lists or a database that loads text based on the integer value. This makes it easy to navigate back and forth between steps.
Personally, I find the use of EQU( Step, x ) --- -- MOVE ( x+1, Step) sequencers to be cumbersome. While they may appear clean, the numerous EQU instructions can make it difficult to track which apply to a specific step.
Instead, I recommend utilizing a bitwise sequencer where you can quickly find the information you need by cross-referencing Step.7. To combine both techniques, consider using a Step DInt and an OnStep Bool Array in your code.
By implementing Onstep.x and Onstep.y with appropriate conditions, you can easily manage and track the sequence of steps. Additionally, incorporating Onstep.StepLast ensures that each step is completed within a full scan to prevent skipping steps unintentionally.
In conclusion, by combining the best of both worlds - using integers and Bool arrays - you can have a sequencer that is easy to understand, manage, and maintain. This approach provides the flexibility and clarity needed for efficient programming and troubleshooting.
It seems like that editor may not be very efficient. Many popular editing software tools have the ability to search for specific text, such as "Step 10". This feature can greatly improve your productivity and workflow.
Aardwizz expressed a preference for bitwise sequencers over EQU-based sequencers. While EQU instructions can be clean, they can lead to confusion when multiple conditions are triggered by the same variable. Using a bitwise sequencer allows for quicker cross-referencing and easier identification of specific steps. A combination of both techniques, utilizing a DInt for Step and a Bool Array for OnStep, can provide the best of both worlds. This approach ensures that each step is active for at least one full scan and helps prevent issues like skipping steps. Bitwise sequencers also offer improved manageability, searchability, and troubleshooting capabilities, as each bit state can be documented individually.
Based on your description, it appears you have a Grfacet sequencer (a French-style sequencer, as I've been informed). I am familiar with two versions of this sequencer. Essentially, in the ladder logic of an SLC 500, pressing the auto start button turns on bit b13:0/0 for auto cycle run. The next rung checks for bit b14:0/0 for the auto cycle run. In the main routine, the file b13 is copied to b14. When the rung looks for b14:0/0, it then checks for the next sensor (part in place) and completes two actions: first, it turns on b13:0/1 and then unlatches b13:0/0.
In Logix 5000, the process is similar with b13:0/0 (tag name step 1) turning on. The next rung involves b13:0/0, followed by copying the files and running the program as described above. Logix 5000's tend statements are beneficial as they eliminate the need to worry about logic scan time, unlike in SLC 500. This approach is akin to line scan programming, but without the issue of intermittent logic failures. I hope this explanation clarifies things for you.
James
Although it may be impossible to document sequential integers, a quick text search can easily locate them if the user has added comments in the program. While I acknowledge that symbols may only have one description, text search is just as effective. It is practical to use the seq. word in a text list to display process messages, especially when there is an HMI or Scada system present.
I want to express my gratitude to everyone who has helped me. Your assistance in answering my questions means a lot to me.
- 02-10-2024
- Maintenance Man
Parky contended that there is value in documenting sequential integers, as a simple text search can still locate them as long as the OP includes comments. While symbolic descriptions are limited to one per item, the usefulness of text search remains significant. Especially in systems with HMI or Scada interfaces, displaying process messages using sequential integers can be beneficial. By assigning a unique power of 2 value to each step, the HMI can still effectively track them. The true value lies in the cross-referencing capability, allowing immediate identification of all instances where a specific step, such as step 2, is relevant. Utilizing this method enables the retrieval of all instances of all steps when searching for integers.
When searching for specific steps in a process, you can simply look for the relevant text in the comments. The steps are often organized into groups of 100, with the first 100 designated as start conditions and subsequent groups assigned for different tasks, such as CIP steps between 100-199. For over 50 years, this method has proven to be the most efficient and hassle-free approach, with no complaints. It's easy to insert new steps as needed and rearrange them when required, as long as there are enough spare steps available. This streamlined system ensures smooth workflow and easy access to specific instructions.
Parky explained that it is unnecessary to search for the step number; instead, focus on the text in the comments which contain references to the step being used. The sequence is often divided into segments, like 0-99 for start conditions and 100-199 for a specific group of steps. Utilizing this method for nearly 50 years, Parky finds it to be the most effective way without any complaints. Adding steps is easy with spare steps available and rearranging them is also simple. It is important to highlight the text accurately to prevent any issues later on. Using an actual address as a search parameter can prevent any failures. In the end, personal preference dictates whether to use text markers or actual addresses.
Finding issues in programs without symbols or comments can be a challenging task. If the symbols or comments do not accurately reflect the code, it can be difficult to diagnose and resolve the problems. Many programmers, including myself and others I have collaborated with, prefer using bits to control sequences. In the past, PLCs were primarily based on boolean logic, but I encountered a system where integers were used for sequences. Despite the lack of source code and documentation, I was able to easily understand the intentions of the original programmer. This method of utilizing bits to control sequences can be efficient and effective in programming tasks.
Parky pointed out the challenge of troubleshooting programs without clear symbols or comments, highlighting the importance of accurate code representation. He and others prefer using bits to control sequences, especially in the era when PLCs operated mainly on boolean logic. Integers for sequences were a new concept for him, discovered in a system with limited documentation. This method made it easier to understand the original programmer's intent.
In a debate, Parky rebutted the argument against using comments by demonstrating the efficiency of finding step 5 actions or outputs using bits instead. While a program with no comments may yield countless results for each step, focusing on the bit for step 5 narrows down the search to relevant actions only. This approach contradicts the reliance on comments for code navigation.
How can you identify step 5 in an uncharted program in a master PLC of an 8 PLC system any better than I can? This search involves navigating through 37 CIP routes spread across 7 channels to control 21 batching tanks. I recently cross-referenced a random step number and tested multiple others in a text field, finding only a few occurrences. Therefore, I believe I have not contradicted myself in my analysis.
Parky mentioned the challenge of identifying step 5 bits in an undocumented program within a complex 8 PLC system. This system includes 37 CIP routes spread across 7 channels, controlling 21 batching tanks. While conducting a cross-reference of step numbers, it became apparent that step 5 is the destructive bit amidst XICs and XIOs for control, most likely in word.5 format.
It's clear that preferences differ when it comes to using bits versus words. Both methods have their advantages and disadvantages, which can be discussed to help others make informed decisions. While appreciating the respectful disagreement, it's time to move on from this topic.
In the discussion, parky mentioned the challenges of locating specific operations within different programming routines. While identifying tasks in a sequence routine may be straightforward due to their logical sequence, finding specific actions in a program like Valves_Motors can be more challenging. The arrangement of tasks may be based on I/O tags, making it difficult to pinpoint exactly what occurs at a specific step. Using specific search terms, such as OnStep.5, can help narrow down the search results and locate the relevant code more efficiently.
The mention of "undocumented code" in the conversation is dismissed as a strawman argument, implying a lack of receptiveness to alternative coding methods. It is acknowledged that each programmer may have their preferred approach, whether it's using different sequencers or coding techniques like ladder or SFC. Ultimately, programming decisions are subjective, and it's essential to respect the existing system and avoid unnecessary modifications simply for the sake of personal preference. This aligns with the original poster's goal of working within the given framework, even if it may be somewhat cumbersome.
Aardwizz expressed a preference for bitwise sequencers over EQU sequencers. When using a bitwise sequencer, the user can easily find specific actions triggered by a particular step. To achieve this, Aardwizz uses both techniques, utilizing a Step DInt and an OnStep Bool Array. By annotating the Bool, Aardwizz can clarify the purpose of a step and quickly identify what occurs during that step.
In contrast, Aardwizz favors using a numeric step number instead of a single bit. By assigning a numerical tag to each step, the user can easily track their progress through the sequence logic and tie it back to the Functional Design Specification. This approach also eliminates the possibility of being on multiple steps simultaneously.
The numeric sequencer offers advantages such as the ability to drive outputs with LIM instructions based on complex combinations of bits, manually redirect a sequence by changing a single tag, and easily categorize stages of the sequence for documentation purposes. Aardwizz finds numerical sequencers easier to program, commission, and understand compared to bit-driven sequencers.
Overall, Aardwizz cannot think of any disadvantages to using a numerical sequencer, highlighting its simplicity and efficiency in programming and commissioning large projects. The end users also find numerical sequencers easier to comprehend and control, making them a preferred choice for project implementation.
I am pleased to find others who share my viewpoint on the matter. Personal preferences play a crucial role in determining one's choice of using controlled sequences in programming. My stance is that while I personally dislike controlled sequences, I acknowledge that others may find them useful and comfortable to use. The idea of "Only destructive bits in program" is puzzling and seems unfounded.
The configuration of a program also influences the number of integers needed for sequencing. In a scenario where I implemented a system with 7 channel CIP and 21 tanks, each tank only required one sequence word for a typical process. The batching process involved numbers ranging from 0 to 2000, while the CIP routes for that tank were numbered from 2500 to 3000, and so forth.
It is worth noting that this approach has gained acceptance among floor engineers, who seldom need to scrutinize the program for faults. Additionally, two major companies I have worked for have adopted this method as their standard control practice. This has been further reinforced by other Systems houses collaborating to establish standards, such as User Requirement Specification and standard control blocks, for any potential suppliers.
When comparing bit-driven sequencers to numerical-driven sequencers, I find that the latter have significant advantages in terms of program ease, commissioning simplicity, and user understanding. While both types can have drawbacks, such as a scattering of EQU instructions and management complexities when coding valve operations, these issues can be mitigated with proper programming techniques. For instance, utilizing indirect addressing to set a corresponding bit alongside the integer tracking the step number can provide specific annotation, facilitate locating actions on specific steps, and ensure that a step remains active for a full scan. This approach combines the benefits of integer tracking with the clarity of bit annotations, allowing for efficient programming and maintenance. Whether or not to adopt this technique is up to individual preference, as programming methods vary among professionals. Ultimately, the goal is to share knowledge and improve programming practices within the industry.
Aardwizz pointed out that while there is no inherent superiority between using bit sequencers versus numeric sequencers, bad implementations are more commonly seen with bit sequencers, especially when excessive latching and unlatching are involved.
One drawback that may occur is the extensive scattering of EQU instructions in the coding process, not necessarily to control the sequence, but to command I/O functions, enable alarms, and interact with other sequences. This can make it challenging to cross-reference the numeric tag to pinpoint a specific EQU instruction for a particular step.
In some cases, a valve may need to open on one step and close on another, with these commands possibly separated from the transition management rungs. Using a bit allows for descriptive annotations like "Start Recirc," which can help clarify the code.
Programming techniques can help mitigate these issues, such as using only one EQU for each step to streamline the coding process and improve readability. However, this approach can result in lengthy and complex rungs that may be difficult to follow.
Occasionally, sequences may need to diverge and then merge back, with different tasks being initiated independently during separate steps. Using a bit sequencer can handle this scenario more effectively than an integer sequencer, which can only accommodate one number at a time.
Ensuring proper sequencing is crucial, as premature transition conditions can lead to the program skipping steps without the sequencer progressing as intended. One recommended solution is including common logic on each sequence advantage rung or arranging the rungs in reverse sequence order.
While not advocating for the exclusive use of bit sequencers, the author suggests a technique involving indirect addressing to set a bit corresponding to the integer tracking the step number. This method allows for specific annotations, facilitates locating actions on specific steps, and ensures that a step remains active for a full scan.
By incorporating this technique, programmers can enjoy the benefits of utilizing integers for step tracking while also leveraging the advantages of bit sequencing. Ultimately, the choice to adopt this approach is up to individual preference, as this platform is dedicated to sharing knowledge and techniques among skilled programmers who navigate the common pitfalls associated with sequencers.
Aardwizz suggested that while both bit sequencers and numerical sequencers have their drawbacks, numerical sequencers seem to have an edge. The use of EQU instructions to command I/O and manage transitions can lead to code scattering, making it harder to follow. An alternative approach involves using indirect addressing to link an integer with a corresponding bit, providing specific annotation and simplifying code navigation. This method also ensures that a step remains active for a full scan, addressing potential issues with sequence continuity. While the decision to adopt this technique is up to individual preference, it offers advantages such as HMI reporting and code simplification.
While this method may streamline logic, it may also introduce complexities that could be challenging for maintenance personnel to grasp, especially during late-night troubleshooting. It is essential to consider the implications of extending step logic across multiple rungs or networks, as well as the potential impact on code integrity when making adjustments. Implementing a "sequence engine" to handle step progression and logic redirection can help prevent errors and maintain sequence continuity, even in the event of power failure.
In contrast to bit sequencers, where power loss can disrupt the entire sequence, numerical sequences offer the benefit of retaining the step number, allowing for seamless continuation after a restart. When developing PLC sequences, it is crucial to prioritize simplicity to facilitate future modifications and ensure ease of troubleshooting for maintenance personnel.
While there are numerous EQU functions available, it is not hard to locate a constant step number through a text search. Typically, numbers within code are used for comparisons, but if well-documented, it is not difficult to identify and implement for specific outputs like motors or valves within a certain range of steps. Using >= and <= with two EQU functions can simplify this process. However, using step bits may require additional steps to hold the output, which could be less intuitive. Personally, I lean towards using sequence integers over bit sequences, as I have observed that sequence control tends to be more effective. I have had the opportunity to rewrite six different control systems provided by the same Italian company, all of which presented their own challenges. After successfully rewiring one system using sequence integers, I was commissioned to do the same for the remaining five systems. Although I have used bit sequencers in the past, I find that sequence integers offer a more efficient solution for larger systems.
Perhaps someone has already recommended this, but for improved readability and troubleshooting, consider organizing each step into its own routine and calling all step routines in reverse order from the main routine. This setup allows for easy access to the logic of a specific step, such as Step 32, if there are transition issues. Regardless if step indication is in bits or integers, this method can streamline the troubleshooting process.
However, complications may arise if actions need to be carried out across multiple steps. If your PLC brand does not support separate callable routines, it may limit your troubleshooting capabilities. It is crucial to separate sequence logic (transitions between steps) from business logic (actions to perform at each step) for effective debugging. Whether addressing sensor failures or output device issues, this separation can simplify the process.
Has anyone fully understood the exact issue faced by OP (@Maintenance Man)? It seems they used a global integer for step numbers and a bit for indicating Step 32, possibly for controlling business logic. Consider using bits in contacts instead of complex instructions like EQU/NEQ for better control over business logic.