Let a PLC bit gate numeric entry with two HMI objects

How do you let a PLC bit decide when a numeric entry can be edited?

Stack two objects on one spot: a numeric display that shows the value in both states and a numeric entry object over it, visibility driven by opposite states of one PLC permission bit, because panel software offers object visibility and no PLC-driven enable or disable on an entry object.

Panel software puts a visibility property on every object: in that property you enter a tag and pick which state of the tag makes the object visible. That is the whole mechanism, so the trick is only in how you point it. Bind the entry object's visibility to the permission bit in the permitted state. Bind the display-only object to the same bit in the other state. Entry objects read and write a word in the PLC, so the value underneath does not care which object is drawn; the tag keeps its value and the screen keeps showing it.

If you have already used one PLC tag to drive two object visibility conditions elsewhere, this is that same pattern aimed at one specific job: the entry keypad.

Why is a password the wrong tool for machine-controlled edits?

A password checks who the operator is, and the condition you want to enforce is a state of the machine, so the two answer different questions; the permission to edit a setpoint has to live in the PLC as a bit the machine logic sets and clears.

Keep passwords for user levels and for protecting the project file. For edits allowed only while the cycle is idle, wire the conditions that define idle into one bit in the PLC, name it for what it permits, and let the screen read it. The screen then follows the machine, and no login state can contradict it.

What do you need before you build the screen?

You need four things: the value tag with its real limits, one named permission bit, the display format both objects will share, and the visibility property every object already carries. Collect them in the editor first and the build itself is a few minutes of work.

• The value tag and its limits. An entry object reads and writes a word in the PLC. Check the tag's minimum and maximum in the tag database: many editors create a new analog tag with a minimum of 0 and a maximum of 100, and a setpoint above 100 stays unreachable until you raise that maximum to your real range.
• One permission bit. Driven by the machine conditions that define when edits are allowed, such as cycle idle and guard closed. Name it in the PLC for what it permits, SETPOINT_EDIT_OK in the example below, so the visibility settings still read clearly a year later.
• The shared format. Decimal places, gain and offset, and the units text. Both objects will use it.
• The visibility property. Every object carries one; you enter the permission bit there and choose the state.

How do you stack the two objects step by step?

Build the display-only object first, the entry object second, and make them identical in position, size and format before you touch visibility. The seven steps below take minutes; checking that the two objects match is where the real work is.

1. Add the numeric display-only object. Bind it to the value tag and set the format: in the worked example below that is gain 0.1, offset 0, one decimal place.
2. Add the numeric entry object. Bind it to the same value tag and enter the identical format: same decimal places, same gain, same offset, same units label.
3. Place the entry object exactly over the display-only object: same X and Y, same width and height, so the digits sit still when the objects swap.
4. On the entry object, open the visibility property, enter the permission bit, and make it visible when the bit is 1.
5. On the display-only object, enter the same bit and make it visible when the bit is 0.
6. Read both visibility settings back and confirm the on/off convention in the editor's own terms: choose the state from the property's options, and do not judge the polarity from the bit's name.
7. Download the project and run it against the real PLC.

How do you keep the number from jumping when the objects swap?

Give both objects the same scaling, the same decimal places and the same size, because the panel redraws the raw tag value through whichever object is visible. A gain on one object alone turns a 175.0 °C reading back into the raw 1750 the moment the bit drops.

Match the font and the text color as well, and leave both objects on the same grid position. The swap happens between panel scans, so with matching formats the operator sees one steady number that happens to become editable. When the PLC changes the value while the entry is hidden, the display twin shows the new value on its next scan, which is the behavior you want during a recipe download.

What does a worked example of the gate look like?

Take a seal-bar setpoint: the tag holds tenths of a degree as an integer, the entry writes 1750 for 175.0 °C, and the PLC accepts it only while the machine is idle. The numbers below carry one edit, one reject and one mid-entry swap.

Scenario. A seal bar needs its setpoint edited only while the cycle is idle. The value tag holds tenths of a degree in a 16-bit integer; the working range is 100.0 to 220.0 °C, so the PLC word runs from 1000 to 2200. Both objects use gain 0.1, offset 0 and one decimal place, and both sit at the same position.

• Edit while idle. SETPOINT_EDIT_OK is 1, so the entry object is visible. The operator types 175.0; the entry writes 1750 into the word, and the panel draws 1750 × 0.1 = 175.0 °C. The PLC's acceptance rung sees the bit at 1 and copies 1750 into the working setpoint.
• Attempt while running. The bit is 0, so the entry object is hidden and the display twin shows the previous value: 1680 × 0.1 = 168.0 °C. Nothing on the screen can be typed into. Suppose a stale second panel still manages a write; the acceptance rung sees the bit at 0 and keeps the word at 1680, so the setting stays 168.0 °C and the screen shows it.
• Bit drops mid-entry. The operator has typed two digits when the cycle starts and the bit goes to 0. The entry object disappears, the display twin appears at the same position, and the number on screen comes from the same word with the same gain, so it does not move.

The value is on the screen in all three cases, editable in the first only, and the PLC word is the authority in every one.

How do you prove the PLC rejects the write while entry is hidden?

Test three cases with the panel live: edit while allowed, attempt while forbidden, and the bit dropping mid-edit. The screen test shows the keypad come and go; the PLC test is the one that matters, so watch the tag value in the controller while you do it.

Run the five checks in this order:

1. Bit at 1: the entry object is visible at the shared position; type a new value and confirm the working setpoint takes it.
2. Bit at 0: the value is still on screen, the entry object cannot be selected, and the word holds.
3. Force a write while the bit is 0, from a second screen or a forced write to the entry word: confirm the acceptance rung keeps the old value. Write that rung so it moves the entry word into the working setpoint only when the permission bit is 1, and clamp the range while you are there; clamping HMI numeric entry limits in ladder logic covers the range half.
4. Change the value from the PLC side in both states, a recipe download for instance, and confirm the visible object follows in each.
5. Drop the bit mid-entry and confirm the swap leaves the number steady.

Visibility is presentation. It decides what the operator can reach on the screen and nothing else, so the rung in check 3 is the gate that holds when a second panel, a stale screen or a project error leaves an entry path open. One boundary belongs to the safety system alone: if the setpoint can move something that can hurt someone, the permission bit is an operating convenience, and the guarding must stand where no screen state can reach it.

What if both objects show at once, or neither does?

Check the two visibility expressions and the bit's polarity first, because this symptom means the two conditions are not opposite states of the same bit. Then confirm both objects point at the intended value tag and that the panel is running the latest project download.

Three symptoms cover the rest:

• The wrong object stays editable. The entry object's visibility is fixed on, or it references a different bit than the display twin does. Set the entry object's condition to the bit at 1 and the display twin to the bit at 0.
• The number jumps at the swap. The two formats differ: compare decimal places, gain, offset and units text object by object.
• The value changes while entry is disabled. A hidden entry object cannot be the writer, so something else owns the tag: another panel, a recipe task, or the acceptance rung copying without its condition. Trace it with finding what owns a tag that changes back after an HMI write, then gate that logic on the same permission bit.

Recommendation: Use the two-object pair whenever a machine condition must decide editability: a numeric display underneath, the numeric entry object over it, identical position, size, gain, offset and decimal places, and visibility driven by opposite states of one PLC-named permission bit such as SETPOINT_EDIT_OK. Keep passwords for user levels, keep the write rejection in the acceptance rung, and the gate holds no matter which screen reaches the tag.

When the same line also needs a board the crew reads from the aisle, that is a screen with no entry at all: a shop-floor signage display showing the status offline from a memory card does that job.

Questions