New ✨ Introducing Oxmaint Asset Hub for Machine Builders and OEMs. Explore Now

Q&A Community

Efficient Debouncing Method in Ladder Logic Using TOF Timer Controls

Question:

Hello everyone. Is this the most efficient method for debouncing inputs in Ladder logic (with 2 inputs being debounced)? The use of a TOF timer controls the process. I anticipate having numerous timers if I continue with this approach due to the abundance of inputs requiring debouncing. Creating an AOI could potentially add complexity (requiring a tag for each AOI and an intermediary tag for writing into the AOI input). Any recommendations for optimizing, streamlining, or enhancing this process?

Top Replies

Upon initial assessment, your proposed solution may seem excessively intricate. To better understand your goals, could you provide more detail on the desired outcome? Typically, I utilize a single timer for debounce; are we aligned on this concept? When the pressure is within the acceptable range, does this mean the contact is closed? Thus, my logic would dictate: if the system is operational and the pressure remains low for a specified duration, trigger an alarm using a singular timer.

Ken Moore expressed that your solution seems overly complex at first glance and requested further clarification on your objectives. He mentioned that he typically uses a single timer for debounce and questioned if you have the same understanding of "debounce." In the scenario where a wired input triggers an alarm after a 2-second confirmation period, it is essential to ensure the input remains stable. Without a reliable method, the alarm may continuously trigger, causing frustration for the operator. To address this issue, a Time-Off Delay (TOF) function is utilized to confirm that the alarm has been cleared before it can reoccur. The goal is to prevent the alarm from repeatedly cycling on and off, ensuring that it is genuinely cleared before resetting. Although the term "debouncing" is commonly used, there may be a language barrier as the discussion involves French-speaking individuals.

In English, debounce is a widely-used term. A well-known pattern for debounce can be found here, but it’s important to determine if it fits your specific requirements. While debounce on the release may not always be top of mind, it is a key component of this established pattern and aligns with the context you’ve outlined.

This approach utilizes just 1 timer, resulting in a debounced signal of GRT.ACC 4999. It is important to assess if this method is suitable for your specific circumstances. While this may not be clearer, I personally believe that stacking timers can be unnecessarily confusing.

That's exactly what I'm referring to. In my industry, there isn't a strong inclination towards embracing technology, with a reliance on basic devices like mechanical pressure, level, temperature, and flow switches. These devices often exhibit erratic behavior when operating near the setpoint, so I implement debouncing techniques similar to using hysteresis on analog inputs. Sometimes, I even apply debouncing on analog devices. Otherwise, operators monitoring alarm systems for 40 hours a week become frustrated when switches cycle on and off unnecessarily. I have developed a custom quick-use block in Function Block Diagram (FBD) programming, as ladder programming can be laborious and time-consuming. I am searching for a more efficient solution than what I have described here.

More Replies

In a similar vein, the usage of just one timer can result in nearly the same outcome; the debounced signal would be GRT .ACC 4999. It is important to assess if this approach aligns with your specific needs. Personally, I find that cascading timers can be overly complex. Attached is a visual reference for further clarification. I also share your sentiment about the clutter caused by parallel timers - your method appears to be more streamlined. I will experiment with it to determine if it offers a faster solution. Thank you.

Dalporto mentioned that they are not a fan of having multiple parallel timers as it takes up a lot of space. They prefer a leaner approach and will test to see if it improves speed. One way to simplify this is by creating an array of integers to loop through inputs and use the array as timers. An example of this is a 16-bit loop.

Looking to implement a Function Block or AOI in your Codesys program? Check out this function block I frequently use in Codesys for debouncing inputs. Within the function block, there are input variables for the boolean input signal, the on delay time, and the off delay time. The output variable is a boolean representing the output signal. The function block also includes timers for the on delay and off delay processes. To execute the on and off delay processes, the function block triggers the timers accordingly. The output signal will only change after the on delay is completed and will remain unchanged until the off delay is finished.

In a previous post, I mentioned that setting up an AOI could be quite challenging. My frustration stems from the need to create superfluous tags for timers. I attempted to simplify the process by using EnableIn on the rung as the input, but that approach proved to be incorrect. Based on my current understanding, using an AOI necessitates the creation of an intermediary tag for the debounce block or a meaningful reference. Additionally, each block requires its own instance of the AOI, which can get cumbersome quickly, even though using an array could potentially streamline the process. Another step involves adding a rung to transfer the intermediary tag to the AOI. At the moment, I still find the TON / TOF scheme with a timer array to be my preferred method.

While it is not necessary to rely on a timer, you can still implement debounce without one, as it is a sensitive and intuitive feature.

Currently, I am waiting for approval from the timer. I will update you on its status. Stay tuned for more updates.

I have developed an Automatic Output Inverter (AOI) for debounce functionality. The output will stay high for a set period of time (In_OnDebounceTime) after turning on, and it will only go low once the timer for turning off (In_OffDebounceTime) has elapsed.

Creativepaper discussed the creation of an AOI for debounce in PLC programming. They pointed out that the In_Sensor XIC and XIO instructions on Rung 3 may be redundant as the corresponding .DN values can only be 1 if the feeding instructions evaluate to True. Additionally, the .TT XIO instructions on Rung 3 may also be unnecessary since the behavior of the I_SensorOnDelayTON and I_SensorOffDelayTON bits are interdependent. Clarity is essential in PLC programming, and unnecessary logic can reduce it. Concerns were raised about using OTL and OTU for the output, as this could lead to incorrect states when the PLC exits and re-enters RUN mode. A suggestion was made to follow a Start/Stop Circuit pattern for better control: using XIC I_SensorOffDelay.DN as the Start condition, XIO I_SensorOffDelay.DN as the Stop condition, and Out_SensorState as the Seal-in/Run bit.

In a previous post, dalporto expressed concern about the challenges of building an AOI (Add-On Instruction) due to the need for multiple tags and intermediary steps. The idea of creating unnecessary tags for timers was particularly frustrating. The hope of using EnableIn on the rung as the input turned out to be impractical. Based on current knowledge, using an AOI would require: - Creating an intermediary tag or reference to send data to the debounce block - Creating multiple instances of the AOI for different blocks - Adding a rung to send the intermediary tag to the AOI Despite these challenges, dalporto still prefers using a TON/TOF scheme with a timer array. To simplify the process, the suggestion is to create a Debounce Function Block/AOI and a structured array to manage tags more efficiently. This approach consolidates all necessary tags in one accessible location.

It appears that you are facing challenges with process issues while programming the control system, which is not ideal. Have you considered why your alarm is excessively loud? Could it be due to inadequate physical design or the use of the wrong instrument?

Frequently Asked Questions (FAQ)

FAQ: 1. What is the efficiency of using TOF timer controls for debouncing inputs in Ladder logic?

Answer: - Using TOF timer controls for debouncing inputs in Ladder logic can be efficient, but it may lead to numerous timers if there are many inputs requiring debouncing.

FAQ: 2. Are there alternative methods to optimize the debouncing process without using numerous timers?

Answer: - One alternative method to optimize the debouncing process without using numerous timers is to consider creating an AOI (Add-On Instruction), although it may add complexity by requiring additional tags.

FAQ: 3. How can the debouncing process be streamlined or enhanced in Ladder logic?

Answer: - To streamline or enhance the debouncing process in Ladder logic, you can explore different approaches such as optimizing timer controls, using AOIs efficiently, or seeking alternative solutions that balance efficiency and complexity.

You must be a registered user to add a comment. If you've already registered,
sign in. Otherwise, register and sign in.