In this shade controller, switch bounce caused intermittent behavior while the PLC loop ran at about 1 ms; changing to Fixed Scan Mode with a 20 ms iteration time stopped the observed problem. Treat that setting as a proven restore for this setup, not as a universal debounce specification: a fixed scan changes when the logic samples inputs, but it does not by itself prove that the input signal is electrically clean.
Stop relying on the RC circuit alone
The input circuit already had an RC network intended to suppress bounce, yet the controller still misbehaved intermittently. Replacing or retuning that circuit without measuring the switch signal risks changing response speed without addressing the actual failure mode. The suspected explanation was that the circuit was tuned for speed while this switch produced slower bounce; verify the waveform before changing component values.
A second possible quick fix is a PLC input filter. A suggestion was made that the Click CPU setup might offer one, but its availability and settings were not confirmed. Check the exact PLC model and the installed programming software’s CPU setup before relying on that option. Do not select an arbitrary filter duration: it must reject the measured bounce while still recognizing the shortest legitimate switch operation.
Do not solve this symptom by making the logic scan faster. The observed controller already ran at roughly 1 ms and had strange behavior in an estimated 5–10% of cases. Faster execution does not make a bouncing contact stable; it can expose more transitions to the logic.
Separate bounce from other intermittent input faults
Contact bounce produces rapid input transitions around a single physical operation. PLC logic may then interpret one press or release as multiple changes, or may evaluate the input in an unexpected state. A fast loop can observe transitions that a slower sampling schedule does not happen to capture. That explains why the reported 20 ms setting could restore operation, but it does not establish the exact electrical bounce duration.
| Observed condition | Likely check | Decision |
|---|---|---|
| Intermittent behavior follows switch operation; the input bit changes repeatedly near the operation. | Monitor the PLC input state during operation; if possible, measure the signal at the input. | Investigate contact bounce, wiring, and the existing RC network. |
| The PLC input state remains stable, but the shade logic still behaves unexpectedly. | Trace the input bit through the program and check how state changes are counted or latched. | Investigate program sequencing rather than adding a filter by default. |
| Behavior changes with scan configuration. | Record the configured mode and iteration time, then repeat the same switch operations. | Use the 20 ms setting as the demonstrated restore for this installation; continue diagnosis if faults remain. |
Intermittent symptoms alone do not prove bounce. A loose terminal, noisy wiring, a failing switch, or logic that responds to a level instead of a single transition can create similar behavior. Observe the input and the program’s response together before deciding which layer needs repair.
Use the 20 ms fixed scan as the demonstrated restore
The reported change was to enable Fixed Scan Mode and set the iteration time to 20 ms; the shade controller then worked as expected. Apply that value only after confirming that the controller and application can tolerate the resulting update cadence. The original ~1 ms loop and the 20 ms setting are the only scan figures established for this installation.
- Record the current scan configuration and save a recoverable copy of the PLC program.
- In the PLC configuration, enable Fixed Scan Mode and enter a 20 ms iteration time, as used in the working setup. Use the correct CPU configuration screen for the installed model and software.
- Download or apply the configuration using the normal procedure for that controller, then confirm that the PLC is in the intended operating mode.
- Operate the switch repeatedly under the same conditions that produced the intermittent behavior. Watch the input state and the resulting shade command rather than judging only by one successful cycle.
This is a production restore, not proof that the switch or input circuit has been repaired. A 20 ms scan can alter which transitions the program samples, and it can also alter response latency. If the shade must respond faster than that or the control logic depends on a different scan cadence, stop and validate the application timing before leaving the change in service.
Choose a permanent debounce method from the measured signal
After restoring operation, decide whether to retain fixed scan timing, configure an input filter, or correct the switch and input circuit. First measure or trend how long the input oscillates after actuation and confirm the minimum valid switch-pulse duration. Then choose a filter interval that rejects the observed bounce without suppressing a real operation. The evidence provides no bounce duration or minimum valid pulse width, so those values must come from measurement and the equipment requirements.
- Fixed scan: Retain the 20 ms setting if the machine timing is acceptable and repeated tests remain clean. Do not describe it as an electrical filter.
- PLC input filter: Use this only if the exact Click controller provides a configurable filter and its setup is available. Verify the setting and observe the input after applying it.
- RC or switch repair: Inspect the existing circuit and the switch signal before changing components. Replace or retune hardware only from measured behavior and component specifications.
For a software debounce, accept a new state only after the input has remained continuously stable for a selected interval, and reset the qualification whenever it changes again. Select that interval from the measured bounce and required response time; do not copy an unverified numeric value. Make sure the program does not count the same sustained state repeatedly when it only needs one event.
Use scan counts for shade position only with calibration
Once the scan interval is fixed, the reported controller used a simple up/down counter to estimate shade position and removed timers from that calculation. The useful mechanism is that repeated control iterations have a known configured interval, allowing the program to count motion intervals in a consistent way. A counter is still an estimate: the source gives no travel time, position feedback device, counter scale, or motor stopping behavior.
Before relying on this method, establish the number of counted iterations between known shade endpoints and define how the logic handles direction, reversal, and endpoint conditions. Increment only while the relevant motion command is active, decrement for the opposite direction, and prevent further changes at known limits. Confirm how the controller applies the configured iteration interval and whether the counter advances once per intended interval; do not assume that a count directly equals a physical position without calibration.
Power loss, manual movement, slipping, or a missed command can make an open-loop count diverge from the actual shade position. If the application needs reliable absolute position after any of those events, use feedback or a defined re-reference procedure rather than treating the count as measured position.
Verify the restore before releasing the controller
Test enough operations to expose the intermittent failure rather than accepting one clean cycle. Repeat both switch transitions, confirm that a single physical operation creates the intended logic event, and confirm that the shade moves in the commanded direction and stops as intended. Observe whether the input bit chatters, whether the program creates duplicate actions, and whether the 20 ms cadence adds unacceptable delay.
Record the final scan configuration, any filter setting actually present, the test conditions, and the counter calibration reference. If the symptom persists with a stable input, trace the logic path and output behavior; if the input continues to chatter, inspect the switch, wiring, and RC circuit. Restore the prior configuration if the new scan timing causes unacceptable machine behavior, then pursue input conditioning or a hardware repair.
FAQ
What happens if I leave the Click PLC at a 1 ms scan?
In this shade controller, the roughly 1 ms loop coincided with strange behavior in an estimated 5–10% of cases, traced to switch bounce. A faster scan is not a debounce method; monitor the input and use a validated filter or the demonstrated 20 ms fixed scan if application timing permits.
What happens if I set Fixed Scan Mode to 20 ms?
That setting restored the reported shade controller. It changes the logic sampling cadence and may change response latency, so repeat the fault-producing operations and verify the control timing before releasing the machine.
What happens if the switch still bounces after the scan change?
Check the input signal and exact CPU setup for a supported input filter, then inspect the switch, wiring, and RC circuit against measured bounce and required response time. Stop changing scan or filter values if the controller’s timing becomes unacceptable or the fault remains; document the configuration and measurements, and escalate through AutomationDirect’s official support channel.