The lamp stays solid, never turns on, or changes state only once even though the logic contains timers or counters. Treat the flasher as a two-state sequence: one TON measures the OFF interval, a second TON measures the ON interval, and the second timer resets the first. Get the sequence cycling internally before assigning it to the physical Q output.
Stop using the usual quick fixes
A counter does not create a time base by itself. It counts transitions supplied by other logic, so adding more counter instructions only moves the problem: the program still needs a repeating pulse. Use a counter only when the required behavior depends on a defined number of flashes.
An SR latch can hold the lamp state, but it also needs dependable set and reset events. If both events are derived from incomplete timer logic, the lamp can remain latched after a stop, restart, or program transition. Add a latch only when the application needs retained state; it is not required for a basic flasher.
PWM may be suitable if Control IO provides that function and the output needs a repetitive duty cycle. Confirm that the function operates at a useful time scale and can drive the intended output. For a visible indicator with separately adjustable ON and OFF intervals, two chained TON instructions make the sequence explicit.
Check the command path before changing timers
Monitor the flasher enable condition and the internal signal feeding the physical output. Do not troubleshoot timing while an interlock, mode selection, or disabled output path is holding the command false.
| Reading | Outcome | Meaning | Next check |
|---|---|---|---|
| Flasher enable | False | The sequence is correctly prevented from running. | Trace the operating mode and permissives. |
| Flasher enable | True | The timing chain should be active. | Monitor the first TON. |
| Internal lamp command changes | Physical lamp does not | The sequence works; the fault is after the logic. | Check output mapping, output status, wiring, and the lamp. |
| Internal lamp command never changes | Enable remains true | The timing chain is not completing or resetting. | Follow both timer states through one cycle. |
When stopping the flasher matters, gate the first timer with the enable command. Removing the enable then resets the timing chain and drives the lamp command low instead of leaving an SR state behind.
Watch the first TON measure the OFF interval
Configure the first TON input from the flasher enable and the inverse of the second timer output. At startup, the second timer is off, so its inverted output permits the first timer to run. Keep the lamp command low while this first interval is accumulating.
Read the first timer input, accumulated time, preset, and done output. If its input is false, trace the enable and inverted feedback. If the input is true but accumulated time does not advance, inspect task execution and instruction status. If time advances but the done output never becomes true, compare the preset with the selected time units and confirm that upstream logic is not resetting the timer each scan.
When the first timer finishes, its output becomes true. Use that state for two purposes: turn on Q and start the second TON. The first preset therefore defines how long the lamp remains OFF.
Watch the second TON end the ON interval
The second timer input follows the first timer output. It must begin accumulating as soon as the lamp command turns on. Its preset defines the ON interval.
When the second timer finishes, its output becomes true and removes the input from the first timer through the inverted-feedback path. The first timer then resets, its output goes false, and both the lamp command and second-timer input go false. Resetting the second timer makes its output false again, which re-enables the first timer and begins the next OFF interval.
If the lamp turns on once and stays on, the second timer is not completing or its output is not breaking the first timer input. If the lamp stays off, the first timer never completes or an external condition holds its input false. If the command chatters at scan speed, the timer states are being bypassed, reset in another program location, or evaluated through conflicting assignments.
Build the two-timer sequence
- Create a non-retentive
TONfor the OFF interval and another non-retentiveTONfor the ON interval. - Drive the first timer from the flasher enable combined with the negated output of the second timer.
- Drive the second timer from the output of the first timer.
- Drive the internal lamp command from the output of the first timer.
- Map the internal lamp command to
Qonly after the internal sequence cycles correctly. - Set the first timer to the required OFF duration and the second timer to the required ON duration. For the stated example, use 2 seconds for the first interval and 1 second for the second interval.
First TON input = Flasher enable AND NOT Second TON output
Second TON input = First TON output
Lamp command = First TON output
Cycle:
First TON timing -> lamp OFF
First TON done -> lamp ON, second TON timing
Second TON done -> first TON resets, lamp OFF
Second TON resets -> next cycle begins
Keep only one assignment to the lamp command. Multiple coils or assignments can overwrite a correct timer result later in the scan and make the sequence appear intermittent.
Verify a complete cycle before releasing the output
- Run the sequence with the physical output disconnected from the internal command.
- Confirm the first timer accumulates while the lamp command is false.
- Confirm the first timer completes, the lamp command becomes true, and the second timer starts.
- Confirm the second timer completes, both timers reset in sequence, and the lamp command returns false.
- Repeat the observation for several cycles. Stop and restart the enable command during both intervals; each stop should force the command low and restart from the OFF interval.
- Connect the internal command to
Q. Compare the monitored command with the output status and the actual lamp.
If the internal command cycles but the lamp does not, stop editing timer logic. Test the mapped output point and field circuit according to the equipment documentation.
FAQ
Why does my Control IO flashing light turn on only once?
The ON timer is not completing the feedback loop. Confirm that the first TON starts the second TON and that the second timer output negates the first timer input.
Why does a counter not make the light flash?
A counter counts incoming transitions; it does not generate timed transitions. Build the repeating time base with two chained TON instructions, then add a counter only if the application must stop after a defined number of flashes.
When should I stop troubleshooting the flashing-light logic?
Stop when timer states do not follow the documented execution model, the output status conflicts with the monitored command, or the platform rejects the required timer feedback structure. Record the enable state, both timer inputs and outputs, accumulated values, presets, output mapping, and Control IO software details, then escalate to official support.