HMI button visibility from a PLC counter completion bit

Short answer: bind the button's visibility condition to the counter's done bit, the discrete status bit that sets when the accumulated count reaches the preset. With a preset of 100 parts, that bit sets on the cycle that brings the count to 100 and clears when a reset runs. The button therefore appears once per batch and hides on reset. The accumulated-value word V1001 is a number, not a flag: a visibility condition bound to it follows bits of the count instead of completion. And the crazy number you saw is a format mismatch, not a bad address, because 100 stored in BCD is 0x0100 and 0x0100 reads 256 as plain binary. Point the visibility setting at the counter's discrete status element and set it visible when the bit is ON. Then download the project to the panel and run one batch through all 100 cycles.

What each symptom points to

Match what the screen does to a cause before you edit anything. Each of these has one fix, and only the last one lives in the PLC:

• The button stays hidden even at a count of 100. The condition is bound to a word tag. A word used where the software expects a bit gets mapped by the driver, and the two common mappings are lowest bit or nonzero means ON. The lowest-bit reading leaves you hidden at exactly 100, because 100 in binary is 1100100 and bit 0 is 0.
• The button shows up from cycle 1 and stays visible. That is the other mapping, nonzero means ON, so any count of 1 or more satisfies it.
• A crazy number sits where a count belongs, 256 instead of 100. The count word is BCD on one device and binary on the other.
• The button shows at 100 but is gone before the operator reacts. A reset rung fires right after the hundredth count, the done bit clears, and the screen follows it at the next update.
• The done bit stays off in the PLC monitor. The counter logic is the fault: a preset the machine never reaches, or a reset that holds the counter at zero every scan.

Causes in order of likelihood

Work down this list; the first cause covers most misbehaving prompts:

1. Wrong visibility source. The condition reads the accumulated-value word, V1001 in V-memory addressing, where the counter's discrete status element belongs. The word carries the count; the element carries completion. One word in place of one bit explains a button that appears at wrong counts or stays hidden at the right one.
2. A number-format mismatch. The word displays correctly in the PLC and reads as nonsense on the panel: BCD against binary, or signed against unsigned. Count 100 as BCD is 0x0100, and 0x0100 read as binary is 256.
3. Inverted polarity. The visibility option pairs the discrete tag with an ON or OFF choice, and the wrong choice hides the button exactly when the bit sets.
4. Counter logic upstream of the HMI. A preset typed in the wrong format stretches the wait: BCD 100 entered into a preset the counter reads as binary is a wait for 256 cycles. A reset that dominates the rung holds the count at zero.

Check the counter before touching the HMI

Open the PLC in run mode with the live monitor up and watch two things: the accumulated value and the done bit. You want the count to climb one per machine cycle, reach 100 on the hundredth cycle, and DN set on that scan. DN is the done bit, true whenever the accumulated value is equal to or greater than the preset, so 100 against a preset of 100 reads true. Let the machine run on: the count passes 101, 102 and 103, and DN stays set, because a counter keeps accumulating past its preset until a reset instruction executes. Then fire the reset the way the logic does and watch ACC return to 0 with DN clearing. If DN stays off through all of that, fix the count pulse, the preset or the reset rung first; the HMI can only show a state the PLC produces.

The fix: bind visibility to the done bit

In the HMI project, open the button's visibility setting. It pairs a discrete tag with an ON or OFF state, so give it a discrete tag. In V-memory style addressing, reference the counter itself as a bit: CT1. In tag-based software, pick the counter's done member from the counter tag, usually named DN or Done. Set the visible state to ON, then download the project to the panel; a project that is only saved changes nothing on the screen.

The panel polls that bit on its own screen cycle, so expect the button within one update of the DN transition rather than on the exact PLC scan. Every visibility tag adds a point to the panel's comms scan. On a link that already carries several devices, the HMI connection limits article gives you the arithmetic on what fits. The same bound-condition pattern is how SCADA screens handle it, and configuring bound button-visibility logic walks through the equivalent setup. Do not hunt through neighboring addresses for the flag: V1002 and V1003 hold whatever data lives there, and neither is a completion bit.

Worked example: a 100-part batch

Take CT1 with a preset of 100, one count per machine cycle and a 6 s cycle time, and follow the arithmetic:

• Time to the prompt: 100 cycles × 6 s = 600 s, so the button appears 10 min into the batch.
• On cycle 100, ACC moves from 99 to 100 and DN sets, because DN is true when ACC is at or above the preset, and 100 is at or above 100.
• The machine runs on to counts 101, 102 and 103; DN stays set and the button stays visible.
• Reset executes: ACC returns to 0, DN clears, and the button hides at the next screen update.
• The 256 you may still see on a count display comes from the format: the PLC writes 100 in BCD as 0x0100, and the panel reads those 16 bits as binary, 1 × 256 = 256.

The cycle time is the only input to replace: at 3 s the prompt arrives after 5 min (100 × 3 s = 300 s), at 12 s after 20 min (1200 s).

Test it, then keep it fixed

Run one full batch with the project downloaded and check four states: hidden at counts 1 through 99, visible at count 100 within one screen update, still visible at 101 and beyond, and hidden again after the reset. Keep ACC and DN side by side on a commissioning screen so the next engineer watches the bit move with the count.

Visibility alone records nothing. If the process needs proof that an operator checked the parts, make the button press write an acknowledge bit to the PLC. Let the PLC reset the counter only when that acknowledge arrives; the logic stays the single master of the prompt, and you test the handshake by watching the acknowledge bit set. Hold the machine in a safe state while you download project changes, the same way you would for any logic edit.

One touch note while you test: if presses register from a hand near the button instead of on it, that is a capacitive-sensing quirk of screens on metal housings. The false button triggers article explains the mechanism and the cure.

When the prompt needs hardware instead

A screen button is only as good as the screen it lives on. Gloves, hose-down and direct sun all argue for hardware: a sealed pushbutton actuated through the housing wall keeps the prompt physical, and the sealed pushbutton article covers how a mechanism works through a sealed wall without losing the rating.

If the display is the weak point, a stainless HMI housing cut for one panel PC is the clean upgrade. A 10.1 in housing suits a 10.1 in panel PC, and a 15.6 in housing suits a 15.6 in panel PC. Both are 304 stainless with a gasketed rear cover, and the front seal is an IP65-type seal with the display installed, a manufacturer rating and not UL listed. Both are cut to your drawing and delivered in 10 business days from drawing approval. The HMI enclosures category covers display sizes from 7 in to 23.8 in, and the cutouts, glands and HMI windows guide has the cutout detail if you add a physical button beside the screen.

Catalog dimensions to compare

Compare these catalog dimensions with your component layout. Open each enclosure for its rating, material and usable space, then check those specifications against your application.

Questions