Use a floating point tag to control HMI object visibility

Why will the visibility option not accept a floating point tag?

The visibility option on an HMI object takes a discrete on/off tag, so a floating point tag like F8:36 never appears in its picker: the field wants one bit, and F8:36 holds a 32-bit number such as 2250.0.

When you select a discrete tag, the option window shows ON/OFF radio buttons for choosing which state displays the object. That is the shape of input the field accepts. Keep the number and the decision separate: the value stays in F8:36 for the numeric display, and one comparison turns it into the yes/no the visibility field reads. Some HMI packages widen the same field into a discrete expression, and those expressions can hold the analog tag directly, for example a tank level test at or above 75. On a panel whose visibility field is a plain tag picker, use one of the three routes below.

Can the panel do the comparison, or must the PLC set a flag?

Three routes produce the discrete result you need: a tag-compare condition on the object itself, the panel's Event Manager watching the real-number tag and writing a discrete tag through a Tag Action, or a compare rung in the PLC that sets a flag at 2250.

The Event Manager holds events that watch panel conditions for as long as the project runs and execute actions when a condition is met; a Tag Action is the piece that writes your discrete tag. Keep the threshold in one place. If the panel and the PLC each carry their own copy of 2250, the two copies drift and the object misbehaves in ways nobody finds later. Turning a condition into one bit and driving the display with it is the pattern behind most shop-floor HMI work; when the condition is two discrete signals instead of one number, combining two conditions into one PLC tag is the piece to read.

Recommendation: Use the object's own tag-compare condition when your panel offers it, because one object, one threshold and one setting travel together. Use the Event Manager with a Tag Action when several objects must share the condition or the condition is a band. Set the flag in the PLC when the comparison must also drive logic beside the display; the panel then reads the bit, and the threshold has a single owner.

Should the comparison be greater than or greater-or-equal at 2250?

Use greater-than-or-equal: the test F8:36 >= 2250.0 must be true at exactly 2250.0, and a strict greater-than hides the object at the one value the requirement names.

Equality is reachable in a running process: a setpoint of 2250, a batch stopped at 2250, an operator entry of 2250. A 32-bit IEEE 754 float stores every whole number up to 16,777,216 exactly, so 2250.0 in the tag is 2250.0, with no 2249.9999 hiding underneath. In the band from 2048 to 4096 the representable step is 2^-12, about 0.00024, so the first value above 2250.0 sits at 2250.00024 and nothing rounds across the boundary by accident. Write the condition as >= and the boundary belongs to the visible state.

What do I need before configuring it?

You need the panel tag mapped to F8:36 and updating live, the threshold set at 2250 in the tag's own unit, one spare discrete tag or PLC bit for the result, and edit access to the object plus, for two of the three routes, the Event Manager or the PLC program.

• The mapped tag, checked live: change the value in the PLC and watch the panel number follow before you build anything on it.
• Agreement between the panel's number and the PLC's number. If they disagree, settle the scaling first; why the scale value differs from the PLC analog input covers that check.
• The threshold in the tag's engineering unit. A tag scaled from a 4-20 mA loop already holds the engineering value; the comparison uses that scaled number, not the raw counts.
• One spare discrete tag on the panel or one spare bit in the PLC, its address written down.
• The visible state chosen. With a discrete tag selected, the option window shows ON/OFF radio buttons; decide now that ON means visible.

How do I set the visibility condition step by step?

Build the comparison, produce one discrete result, bind that result to the object's visibility, then download and test: six steps once the tag is mapped and updating.

1. Check the mapped tag for F8:36 updates: nudge the value in the PLC and watch the panel read it.
2. Create the comparison in your chosen route. On the object: set the visibility condition to the panel tag >= 2250.0. In the Event Manager: set the real-number tag's minimum to 2250 and its maximum to the top of the tag's range. In the PLC: add a compare rung that sets the bit when F8:36 >= 2250.0 and clears it otherwise.
3. In the Event Manager, add the Tag Action that writes the discrete tag when the condition is met, and the opposite write for when it stops being met. One event, both directions.
4. Open the Object Visibility option and select the discrete result tag, then pick the ON radio button so the tag's 1 state shows the object.
5. Apply or download the project through your normal workflow.
6. Test the boundary before the panel goes back to the line.

What does a worked example with F8:36 and 2250 look like?

A fill value sits in F8:36 with a full scale of 3000, and the object may appear only at 2250.0 and above: the Event Manager route takes a minimum of 2250, a maximum of 3000 and one Tag Action on a single discrete tag.

Three snapshots from the run:

The unit of F8:36 is whatever the transmitter writes into it, and the arithmetic uses that scaled number as-is, with no conversion. The maximum sits at 3000 because that is the tag's full scale: set the maximum to the top of the range unless you want the object to hide again above a real limit. When the intent is a window, show between 2250 and 3000, the same minimum and maximum pair is exactly the tool, and that is the case where this route beats a single compare on the object.

How do I test the threshold and the way back down?

Drive F8:36 through four values, 2249.9, 2250.0, 2250.1 and back to 2249.8, with the discrete tag and the object on screen together: hidden, visible at the boundary, visible above it, hidden again on the return.

The two off-boundary values are safe test points because of the float step: near 2250 the representable spacing is about 0.00024, and 0.1 is roughly 410 of those steps (0.1 / 0.00024 = 410), so 2250.1 reads strictly greater and 2249.9 strictly less with no rounding doubt.

The return leg is the one that fails in the field. A result tag that sets at 2250 but never clears leaves the object on the screen for the rest of the run. If the tag flips and the object stays put, the visibility tag or the ON/OFF polarity is wrong. If the tag never flips, fix the comparison or the action and leave the object settings alone. On the PLC-flag route, check the flag's reset path with this same test.

Can an operator still press the object while it is hidden?

No, on panels that document the behavior an object hidden by its visibility tag also leaves the touch layer, so a hidden button cannot be pressed while its condition is false.

The comparison that reveals the button therefore also gates it, which is handy for step-through screens. Try the press during the same test pass and note the result for your panel model. When you want the button present but inactive below the threshold, gating button visibility on a timer done bit shows the pattern. Keep any real interlock in the PLC: visibility is presentation, and the machine must stay safe with the screen dark.

Questions