Control Sequence with a Single Push Button for Step-by-Step Process Completion

In response to OperaGhost's suggestion, it is recommended to place the PB and oneshot on their own separate rung at the start of the step process. This setup can be illustrated for step 20 and step 30 by using the abbreviation for gU_LhsCalibration[2] tags as the tag name after the period. For instance, the setup can be as follows:XIC(B_Verify) ONS(Cal1Verify_ONS[1]) OTE(Verify_Trigger)EQU(I_StepNo,20) [ COP(S_StepDesLiteral[1], S_StepDes, 1) , XIC(Verify_Trigger) MOV(30, I_StepNo) ]EQU(I_StepNo,30) [ COP(S_StepDesLiteral[2], S_StepDes, 1) , XIC(Verify_Trigger) MOV(30, I_StepNo) ]This arrangement eliminates the need for additional oneshots, ensuring that each press of the PB triggers only one step. To proceed to the next step, the PB must be released and pressed again. Can you confirm this approach? I have attempted it without success, as the transition from step 20 to step 100 happens too quickly. Parky has suggested resetting the ONS - how can this be done effectively?

• 04-12-2024
• Shivsrikakolum

Frequent chatter or bouncing of contacts is a common issue. Implement a timer of a quarter or half second when the switch is activated to prevent this problem. Additionally, tracking switch presses with a step counter can simplify logic and troubleshooting. By organizing actions based on the current step, it can streamline processes and make problem-solving more efficient.

• 04-12-2024
• jtn

Have you considered implementing the Verify_trigger function and reordering the step rungs? The sequence would be Step 100 rung followed by Step 90, Step 80, Step 70, and so forth. This reordering can optimize the execution of your processes.

• 05-12-2024
• 5618

It has been a while since I have worked on any RealWorld projects, but I believe the tag you assign to a oneshot is simply RST (or something similar). I am uncertain about how the ONS functions in RealWorld, but if it is not working for you, you could always create your own on the initial setup.

• 06-12-2024
• parky

It has been a while since I've delved into RW programming, but I believe the tag you assign to a one-shot can simply be RST. If the ONS functionality isn't working in RW, you can try creating your own on the first rung. In Rockwell, using the OTU (Unlatch) instruction didn't provide the desired outcome. In Sysmac, I typically reset it in the same way as you do. However, in RW, I am unsure of how to reset a one-shot.

• 06-12-2024
• Shivsrikakolum

In addressing the issue of chatter or bouncing on contacts, a recommended solution is to incorporate a quarter or half-second timer upon pressing the switch to prevent input errors. Implementing a step counter that tracks the switch presses can streamline the logic and simplify troubleshooting processes. While using a timer or counter can be effective, exploring the use of a oneshot method, as seen in Sysmac, may offer a more efficient solution. If challenges persist, resorting to a counter can be considered as an alternative approach.

• 06-12-2024
• Shivsrikakolum

I have recently shared a tutorial on creating custom oneshots to address issues with how RW handles oneshots. When a oneshot is triggered, it is only active for a single scan. By updating the PIO at the beginning or end of the scan, the chance of button jitter occurring is greatly reduced. Most inputs and outputs have a filtering delay of at least 10ms, unless they are used for interrupts. Nowadays, many PLCs have scan times ranging from 10 to 20ms even with complex programs, making button jitter unlikely to occur as a problem.

• 06-12-2024
• parky

Let's start by examining rung 3 and assuming that it marks the beginning of the process. When StepNo reaches 20, the EQU condition is met, triggering the COP to execute. If the button is pressed, the ONS allows passage and activates its bit, advancing StepNo to 30. Moving on to rung 4, where StepNo is now 30, leading to the execution of the COP. Despite the button still being pressed from the previous rung, the Cal1Verify_ONS[1] bit being ON causes the XIO instruction to be false. This results in the resetting of ONS[2] without executing the MOV instruction. Progressing to rung 5, where the EQU condition is false, preventing the COP from executing and resulting in the reset of ONS[3] without MOV execution. This pattern continues on subsequent rungs with similar logic. Upon reaching the end of the scan, the cycle restarts with rung 0. Moving back to rung 3, the EQU being false prevents the COP from executing, resets ONS[1], and avoids MOV execution. Transitioning to rung 4, the EQU condition being true triggers the COP to execute due to StepNo being 30. The operator likely still holds the push button as only microseconds or milliseconds have passed. This rapid button press sequence results in the execution of Step 20, Step 30, and Step 40 with each scan. A possible approach to this process involves utilizing a counter system. By using ONS.30 as the last step ONS, the process becomes adaptable to different step counts. Placing COP and MOV in close proximity for readability, the method remains effective even if they are in parallel branches.

• 06-12-2024
• Operaghost

Shivsrikakolum mentioned an Instruction known as OTU (Unlatch), but it did not work in Rockwell's Sysmac system. In Sysmac, the process of resetting is similar to what you would do. In RW, the method to reset a Oneshot is unclear. It should be noted that resetting an ONS should not typically be required as they are only active for one scan. However, if necessary, an OTU should be used, not a RES (reset).

• 06-12-2024
• Operaghost

One way to optimize ladder logic programming is by rearranging the order of individual steps while keeping the PB ONS rung at the top. Consider structuring each step as: Code XIC PB_PULSE, followed by EQU for step number comparison, and then performing actions like COP and MOV. This adjustment can help improve the efficiency and organization of the ladder logic program.

• 06-12-2024
• joseph_e2

Operaghost explained a process starting at rung 3, assuming it as the beginning point. When StepNo reaches 20, the EQU condition is met, triggering the COP to execute. Pressing the button allows passage through the ONS, setting its bit to on and moving 30 into StepNo. Moving to rung 4, StepNo is now 30, causing the COP to execute. Despite the button still being pressed, the Cal1Verify_ONS[1] bit being on makes the XIO instruction false, resetting ONS[2] without executing the MOV. This pattern continues in subsequent rungs until reaching rung 0 and then jumping back to rung 3. In this scenario, a counter could be used as a more efficient method. By utilizing ONS.30 as the final step indicator, the process can be streamlined, eliminating the need to specify each individual step number. OG expressed gratitude towards those who contributed ideas and suggestions for improving the process.

• 06-12-2024
• Shivsrikakolum

One effective method to accomplish this task is by creating an intermediate copy of the step number to evaluate the start of each rung. By copying the step into an intermediate variable, this ensures a minimum scan duration for each step and eliminates the need for oneshots. This strategy optimizes the process and enhances efficiency in ladder logic programming.

• 06-12-2024
• robertmee

To improve the efficiency of your ladder programming, consider placing the rungs in reverse order. For example, if your steps progress from 10 to 100 in increments of 10, simply enter them in reverse: 100-10. This method can streamline operations and enhance the functionality of your ladder logic.

• 06-12-2024
• parky

I completely agree with Operaghost's suggestion. In my initial response, I may have oversimplified things and neglected to consider the possibility of multiple steps being initiated during the same scan. My main focus was on preventing a step from being triggered in the following scan.

• 06-12-2024
• voos.charley

Hey @Shivsrikakolum, it's important to understand that your code executed as intended, even if the outcome wasn't what you were hoping for. One aspect of PLC ladder logic to consider is that most instructions take action when the rung is evaluated, regardless of the input's state. Instructions like [-] and [-and-]/[-) always output either True or False. Additionally, instructions like [-] and [-andONS) perform a Boolean AND operation between their operands and the input state. The ONe-Shot instruction writes either 0 or 1 to its memory bit and uses that information to detect changes in the input state on the next scan cycle. The value of the memory bit is updated on each scan cycle, with 1 written for True and 0 for False. This value is crucial for identifying rising edges in the current cycle. In your code, the ONe-Shot instructions were evaluated on every cycle, even when the initial condition (EQU ..._StepNo #instruction) was False. This mismatch in the input state affected the memory bit's value and subsequently impacted the evaluation in the following cycle when the button was pressed.

• 06-12-2024
• drbitboy

Here is a slight variation to @robertmee's methodology, aimed at enhancing your understanding of how the PLC scan cycle operates. While not intended to replace his approach, which is more straightforward and therefore preferable, it can assist you in grasping the concept better. It's worth mentioning that in this code, the transition between steps occurs upon releasing the button, as opposed to @robertmee's code where it happens upon pressing the button. To switch the behavior in this code, you can simply interchange the integer variables. Additionally, it is advisable to consider implementing a debounce mechanism for the button press, as previously suggested in the discussion.

• 06-12-2024
• drbitboy

In my process, I ensure that each stage sets a "Stage#_Complete" tag before moving on to the next stage. The ladder logic in my program is structured in a way where the next stage is positioned above the previous stage. This can be visualized in the rungs as follows: PB----ONS Stage 6 Rung if Stage 5 is Completed, Stage 5 Rung if Stage 4 is Completed and Stage 6 is Not Active, Stage 4 Rung if Stage 3 is Completed and Stages 5 & 6 are Not Active, and so on until Stage 1 Rung is activated if Stage OneShot is triggered and Stages 2-6 are Not Active. This approach ensures a systematic progression through each stage based on completion status.

• 06-12-2024
• I_Automation

In the realm of automation, it is recommended to reverse the order of stages to ensure that the oneshot function activates only one rung at a time. While this may make the code appear more complex to those other than the original programmer, it is essential for most sequences where certain conditions must be met, such as a sensor being triggered before advancing to the next step. However, there are instances where no external conditions are required, in which case resetting the oneshot on the "True" of the rung can prevent subsequent rungs from being triggered. There are various methods available to ensure that only one rung is activated with a single button press, and although using slug timers or counters is not commonly practiced, it has not posed any issues in my experience. In addition to automated sequence cycles, some machines also feature a manual step mode, allowing users to progress through steps one at a time with each press of a button.

• 06-12-2024
• parky