Your drum is not broken. Its outputs are written off by later manual rungs, and the last write in the scan wins. Give the drum and the panel separate internal request bits and drive each physical output from one arbitration rung.
The drum is not broken. The steps advance because the instruction runs; the outputs stay off because rungs later in the program write the same physical coils, and the last write before the end of the scan wins. Three manual rungs after the drum are enough to cancel every automatic command. The repair is to give the drum and the panel separate internal request bits, then drive each physical output from one rung that chooses between them. Fix that, and the stall at the event step clears on its own, because the motor finally turns.
Why does the drum sequence advance but the outputs stay off?
Because rungs placed after the drum write the same physical output coils, and a physical output takes the state of the last write in the scan, so each manual rung that is false writes the drum's outputs off every scan, every 10 to 50 ms on a typical small controller, while the drum keeps timing.
A drum instruction is a sequencer. Each step writes the pattern of outputs in that step's mask, for a set time or until an event input. Nothing in the step logic protects those outputs once it has written them. Three rungs later in the program, your manual commands solve, and each writes a physical coil. With no panel button held, those rungs solve false and write the coil off, scan after scan. That is why the panel commands looked fine while the drum commands vanished: the manual rungs are the last writes. Programming guides for scan-based controllers treat an output written in more than one place as a defect to remove, because the result depends on rung position instead of machine state.
How do I tell a double coil from a broken drum instruction?
Watch the step number and the outputs together: six steps advancing with all outputs off points at overwritten writes, a drum stuck on step 1 points at the drum itself, and manual commands working from the panel completes the pattern of a double coil.
| What you see | What it points to | What to check |
|---|---|---|
| Steps 1 to 6 advance, outputs never turn on | The sequencer runs; something later writes the coils off | Cross-reference each coil the drum drives |
| Panel buttons run the machine | The manual rungs are the later writes | Compare the coil addresses in the manual rungs with the drum's output mask |
| Drum sits on step 6, waiting on a limit switch | The motor never ran, so the switch never closed | Repair the output writes first, then watch the switch during the move |
| A coil flashes on in the data view, then reads off | Two writes landing inside one scan | Monitor the coil online while the drum runs |
The bottom row misleads. The coil really does turn on, for the part of the scan between the drum's write and the manual rung, and a data view that refreshes every 100 ms or so shows it as a flicker. Read the writes, not the flicker.
Where are the writes that overwrite the drum outputs?
Cross-reference every physical coil the drum is meant to drive and read each rung that writes it; on this fault the extra writes sit in the manual-command rungs at the end of the program, three of them in the case this article describes.
Every PLC programming package has a cross-reference or a find-all for an address. Run it on each coil the drum drives. On a program with this fault you get two writes per coil: one from the drum's output mask and one from a manual rung near the end. Then watch one coil online while the drum runs. The bit sets when the step pattern is written and clears where the manual rung solves false. That clear is the fault. The same tracing settles a PLC tag that changes back after an HMI write: list every writer, then let one of them own the address.
Why does the sequence stall at the event step?
The event step is waiting for a limit switch that closes only when the motor moves, and the motor never moved because its output was being written off each scan, so the stall at step 6 is a symptom of the same overwrite, not a second fault.
Step 6 waits on a limit switch that closes when the motor reaches position. The motor never ran, so the switch never closed, so the drum waits. Lengthening the five timed steps teaches you nothing: their timing was already correct. Forcing the event input advances the drum past a step whose machine action never happened, which is a worse place to be than a visible stall. Repair the output writes, run the cycle, and the switch closes in normal motion. If the drum still waits after the motor has actually turned, the switch or its input address is a genuine second fault, and you can chase it then.
Which bits should the drum and the panel write?
Neither should write the physical coils: the drum instruction accepts internal control relays as its outputs, so point its mask at internal bits, and give the panel's buttons their own separate internal bits that only the panel writes.
The drum instruction's documentation gives you the choice directly: its outputs can be physical outputs or internal control relays, and the instruction turns on a flag bit when the sequence completes. Where the drum writes through a mask word, the instruction reference states it uses the lower 16 bits of each output mask address and reserves the upper 16, so one word carries a 16-output pattern.
Choose control-relay addresses nothing else in the program or the panel uses. If the panel writes the same control relay the drum drives, the conflict has moved from the coil to that bit, and the symptom returns. Set the panel buttons up as command bits that PLC logic acts on, the pattern in making an HMI button turn on a PLC output through a command bit, so a button never drives a coil directly. The same separation is what makes drum step times editable from an HMI panel safe: the panel writes a preset value, and the drum still owns its own outputs.
What does the arbitration rung look like in a three-output example?
One rung per physical output, of the form drum request AND auto mode, OR panel request AND manual mode, driving the coil; with three outputs you build three rungs, and each physical coil then appears exactly once in the whole program.
The names below are illustrative. Map them to your own addresses.
- Drum requests: C101, C102, C103, one per function, written only by the drum mask.
- Panel requests: C111, C112, C113, one per function, written only by the panel.
- Mode: C120 AutoMode, driven by a physical selector; manual mode is AutoMode off.
Y1 := (C101 AND C120) OR (C111 AND NOT C120)
Y2 := (C102 AND C120) OR (C112 AND NOT C120)
Y3 := (C103 AND C120) OR (C113 AND NOT C120)
Run the numbers of this repair. The drum keeps its six steps: five timed, one event. The three manual rungs at the end of the old program go away, replaced by three arbitration rungs. Six internal bits appear: three drum requests plus three panel requests. The cross-reference across the three coils drops from six writes, two per coil, to three, one per coil.
With the selector in auto, each coil follows its drum request through steps 1 to 5, the motor runs, the limit switch closes, and step 6 releases. With the selector in manual, each coil follows its panel request and the drum can energize nothing. Put the machine permissives that must be true for motion, illustrated here as RunOK, in series after the OR block so one contact gates both sources:
Y1 := ((C101 AND C120) OR (C111 AND NOT C120)) AND RunOK
If a function must jog in both modes, write that into the rung as an explicit OR branch with its own condition. Decide in logic, never by rung position, which is the same discipline behind decoding one HMI switch that commands two outputs in the PLC.
Example scenario: six-step cycle, three coils, two writes each
Take the machine as found: one drum with 6 steps, 3 physical coils, and 3 manual rungs at the end of the program. The cross-reference shows 2 writes on each of the 3 coils, so 2 x 3 = 6 writes in total across 3 addresses. During each of the 5 timed steps, every coil is written twice per scan: once by the drum's mask, once by a false manual rung. On a scan time of 10 ms, the coil is on for only the fraction of that 10 ms between the drum's write and the manual rung, so the motor sees effectively 0 percent of its commanded on-time and never moves, which is why step 6 waits on a limit switch that never closes.
After the repair, the same cross-reference shows 1 write on each of the 3 coils, 1 x 3 = 3 writes in total: 6 writes minus 3 removed manual rungs equals 3. The drum writes 3 internal bits, the panel writes 3 different internal bits, and 3 arbitration rungs drive the 3 coils. On the next cycle the motor runs through steps 1 to 5 in their programmed times, the limit switch closes on real motion, and the drum leaves step 6 without touching the event input.
Recommendation: give the drum internal control-relay outputs, give the panel separate request bits, and drive every physical coil from exactly one rung of the form drum request AND auto mode, OR panel request AND manual mode, with the machine permissives in series. Apply this whenever two sources command the same coil, which is every machine that has both a sequence and a manual screen.
How do I check the fix on the machine?
Cross-reference first: every physical coil you touched must show exactly one write; then run the sequence with the motor prevented from moving and watch the request bits and the coils agree in both modes before you let the machine move.
- Save a copy of the project, make the changes, and cross-reference every coil you touched. One write each, the arbitration rung.
- Download, follow the machine's lockout procedure so the motor cannot move, and put the selector in auto.
- Start the drum and confirm in the data view that each coil follows its drum request through steps 1 to 5.
- Put the selector in manual and press each panel button. Only its coil responds, and the drum stays idle.
- Restore the machine and run one full cycle. Confirm the limit switch closes on real motion, the drum leaves step 6, and the sequence repeats.
Step 2 carries the safety: after this repair the sequence can move the machine for the first time, so keep hands and tools clear until that first full cycle is done.
Questions
Can I fix it by moving the manual rungs above the drum?
You can, and automatic will then work, but the change only picks a different winner. With the manual rungs earlier, a pressed panel button gets overwritten by the drum's step pattern instead, so manual control dies in auto. Rung order decides who wins; a single write per coil ends the conflict.
Do internal control relays follow the same last-write rule?
Yes. Any address written in two rungs keeps the state of the last write, physical coil or internal bit alike. That is why the drum and the panel get different bits in this repair, and why you cross-reference internal bits exactly the way you cross-reference coils before you use them.
What if the drum pattern needs more than 16 outputs?
One output mask address carries 16 bits, the lower half of the word, and the upper half is reserved by the instruction, so 16 functions per mask word is the ceiling. Run a second drum on a different output word and combine the two patterns at the final output rungs with OR logic, instead of merging them into one word.
Should the auto and manual selection come from the panel or a switch?
Use one AutoMode bit from a physical selector, and let manual be its off state. Keep the selector in the rung, not in the panel software: a screen tag can be pressed by anyone at any time, while a hardware selector is what machine procedures assume separates auto from manual. One selector, one mode bit, referenced by every arbitration rung.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.