I encountered an issue where resetting counters while their inputs were active resulted in the reset value being set at 1 instead of 0. To rectify this, I have implemented a solution to reset the inputs in conjunction with the counters. Any suggestions for enhancing or expanding upon this approach?
div1311 inquired about potential enhancements to the logic presented. Suggestions include resetting the count (counter object accumulator) rather than the counter object itself (C1, C2), waiting for the input logic to turn false before resetting the counter, or utilizing one-shots (rising edge detectors) on the input to the counter instructions. In summary, the count's "reset value" is always 0, never 1, for a counter during the scan cycle when the RST instruction is executed. The RST instruction not only resets the counter's internal bit related to the input rung state memory but also helps in detecting the rising edge of the input rung state. However, the effectiveness of RST on X0 and X1 may be limited if the inputs remain active or the buttons are still pressed. During the subsequent program scan cycle evaluation, the input rung state may be true, but the "input rung state memory" bit value could be 0 due to RST C0 and RST C1. In such cases, the counter instruction detects the rising edge, incrementing the count from 0 to 1 and updating the input rung state memory to prevent further rising edge detections as long as the input remains true. For a detailed understanding, refer to the flowcharts on pages 68 and 69, illustrating the behavior of counter instructions. Pay close attention to the diamond block ".CU is True" on page 69, representing the internal "input rung state memory." Additionally, note that the "RES (RST) instruction resets counter_1 by clearing the status bits and the .ACC value." These principles are often applicable across various PLC vendors, not limited to Allen-Bradley Logix controllers.
Your approach seems pretty solid, but have you considered implementing a debounce function? By ensuring that the reset input is stable for a certain amount of time before it takes effect, you might avoid false triggering caused by noise or short fluctuations. It might add some complexity to your process, but could be beneficial in making the system more reliable.
Your approach certainly seems sound based on what you've shared. Another strategy could be to integrate a brief delay between resetting the counter and the inputs; this might ensure your counter set correctly to 0 before the inputs start coming in again. It's all about the sequence and perfect timing. But, remember to test this design under various scenarios for confirm its robustness.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: 1. Why does resetting counters with active inputs result in the reset value being set at 1 instead of 0? - This issue occurs because the counters are reset before the inputs, causing the reset value to be set at 1 instead of 0.
Answer: - The suggested solution is to reset the inputs in conjunction with the counters to ensure accurate output control in GXWorks3.
Answer: - To enhance the approach, you can consider synchronizing the reset of counters and inputs more effectively, or explore additional functionalities within GXWorks3 that may offer improved control and accuracy.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.