Scale a floating point level tag for an HMI bar

Why won't the shape's sizing animation take a floating point tag?

The sizing animation on a shape takes integer tags only, so a floating point level tag has no slot in that dialog; the restriction is in the object definition, and redrawing the rectangle or re-entering the tag gets the same refusal.

Two different objects draw a level bar. A shape, usually a rectangle, with its Y-axis size animated by a tag: the tag slot there expects an integer. A bar meter object: it accepts a floating point tag and draws its own fill. Once you know which object you have, the fix follows. For the shape, hand the animation an integer it can read, which means one conversion rung in the PLC. For the meter, assign the float and live with its styling.

Integer-only inputs are common across animation objects, and the same wall shows up elsewhere: gauge objects whose maximum value field takes whole numbers only hit it too. Some platforms soften it at the tag editor, where an I/O tag declared as real can carry its own conversion from raw values into engineering units. If your editor offers that, it is the same fix living in the panel instead of the PLC.

Nearby cases behave differently, and it helps to know which one you have. Visibility runs the other way: a floating point tag can drive HMI object visibility with no conversion at all. Trends carry the mirror problem, engineering values plotted as raw counts, and rescaling raw integer tag values on a trend is that fix.

How do I convert the float to an integer tag in the PLC?

Map the float onto a fresh integer tag with Y = Y_low + (PV - PV_low) * (Y_high - Y_low) / (PV_high - PV_low), then clamp the result to Y_low and Y_high so a failed transmitter cannot push the graphic off scale.

The variables are yours to choose:

• PV is the floating point level as the control program already holds it, with PV_low and PV_high its engineering span, 0.00 to 12.00 ft in the example further down.
• Y_low and Y_high are the integer span the animation will read, 0 and 1000 there.
• Y is a new integer tag, written every scan or on a timed task, and read by the panel.

Leave the control float alone. The conversion tag exists for the graphic; the float keeps running the loops and the alarms.

Three details make the rung dependable:

• Rounding: pass the result through the PLC's real-to-integer conversion and pick round or truncate once. Either lands within one count, invisible at the spans below.
• Clamping: two compare rungs, one holding Y at Y_low when it reads low, one holding it at Y_high when it reads high. Without them a broken wire writes a negative count and overrange writes past the top, numbers the animation was never set for.
• Span guard: if PV_high and PV_low are ever equal the divisor is zero, a runtime fault on most controllers. Trap it, or pick endpoints that cannot be equal.

One safety note belongs here. A clamped bar sits at empty or full exactly the way a healthy level does, so keep the transmitter's out-of-range alarm as its own lamp or message where an operator will see it. Test for tank full on the clamped integer, Y greater than or equal to Y_high, because equality compares on floats can miss when the low digits round.

If the float itself still needs scaling from loop current, scaling a 4-20 mA transducer for an HMI display covers the input end.

What integer span should the display tag use?

Scale into 0 to 1000 for a bar around 300 px tall: the fill then moves 0.3 px per count, while a 0 to 100 span moves it 3 px per count and the eye sees the bar jump.

The ceiling is the tag's own range. A signed 16-bit integer holds -32768 to 32767, so any span from 0 to 100 up to 0 to 10000 sits inside it with room. What picks the span is the bar's height in pixels: the fill cannot resolve finer than one pixel, so counts far beyond the pixel height are wasted, and counts below the pixel height make the fill step.

0 to 1000 is the working choice for bars from roughly 100 to 500 px tall. If a percentage readout sits beside the bar, divide by 10 in the numeric field with one implied decimal, the same format used for implied decimal values on a trend graph.

What does a worked example look like on a 12 ft tank?

A 12.00 ft tank scaled 0 to 1000 puts an 8.40 ft level at 700 counts, because Y = 0 + (8.40 - 0.00) x 1000 / 12.00 = 700, and the same rung puts 0.00 ft at 0 counts and 12.00 ft at 1000.

The scenario: a water tank with a 4-20 mA level transmitter scaled in the PLC to a float from 0.00 to 12.00 ft, and a bar graphic 300 px tall beside it. The rung becomes Y = PV x 1000 / 12.00, that is 83.3 counts per foot.

Now the two fault cases, handled by the clamp rungs. A broken wire drops the loop to 0 mA, which scales to (0 - 4) / 16 x 12.00 = -3.00 ft and a raw count of -250; the clamp holds Y at 0 and the bar stays empty while the alarm does its work. Overrange at 20.8 mA scales to (20.8 - 4) / 16 x 12.00 = 12.60 ft and a raw count of 12.60 x 83.3 = 1050; the clamp holds 1000 and the bar sits full.

On the panel side the animation minimum is 0 and its maximum is 1000, the same pair the rung writes.

How do I point the animation at the converted tag?

Point the Y-axis sizing animation at the new integer tag and enter the same two numbers the PLC writes, 0 and 1000 in the example, as the animation minimum and maximum; any other pair skews the whole bar.

1. Add the integer tag to the panel's tag database with the address the rung writes.
2. Select the rectangle, open its sizing animation, and choose that tag.
3. Type the rung's two endpoints, 0 and 1000, into the animation minimum and maximum.
4. Check direction: force a mid value and confirm that rising level grows the fill from the bottom of the tank upward. If it fills the wrong way, reverse the endpoint order or the direction setting in the dialog.
5. Force 0, 500, and 1000 and watch the bar reach empty, half height, and full.

The classic mistake lives in step 3. If the animation maximum is left at 4096, a habit carried over from raw analog counts, the bar tops out at 1000 / 4096, which is 24 percent of its travel, and stays there no matter how full the tank gets.

Why is the bar stuck, reversed, or full too soon?

Most of these trace to the pair of numbers at each end: a bar that tops out early has an animation maximum above the PLC's Y_high, one that pins full early has it below, and a frozen bar has a dead tag link.

• Tops out below full: animation maximum larger than Y_high. 1000 written into a 4096 maximum stops the bar at 24 percent of its travel.
• Pins full partway up the range: animation maximum smaller than Y_high. A 100 maximum against a 1000 span reads full from one tenth of the tank upward.
• Fills from the top down: endpoint order or the direction setting in the animation dialog. The PLC math is fine; fix it at the object.
• Frozen at one value: tag link or address. Read the tag in the PLC first with a programming monitor; if it moves there, check the panel's address and data type.
• Steps instead of sliding: span too coarse for the bar's height in pixels. Move to 0 to 1000.
• Snaps to empty or full on a transmitter fault: the clamp rungs are missing, so the panel sees the negative or overrange count raw.

What can I do if the PLC program cannot be changed?

Use a bar meter object on the float tag and set its background color to match the screen background: bar meters take floating point tags directly, and setting up the tank fill with a bar meter object walks through the object itself.

The swap: delete the rectangle, place a bar meter, assign the floating point level tag, set the meter's low and high to the engineering span, 0.00 and 12.00 ft, and set its background to the screen's background color.

Two limits decide whether it ships. A narrow dark border stays around the meter; on a black screen it vanishes, on a light one it shows. And the meter's background is a solid color, so placed over a raster image of the tank it covers the artwork. Test it on the production background at its final position. If the border or the opaque box fights the layout, the PLC integer tag is the path. If the program freeze is temporary, add the rung at the next outage and keep your shape.

How do I check the bar tracks the level before it goes live?

Force the tag to three values, 0, half span, and full span, and watch the bar reach empty, half height, and full: 0, 500, and 1000 counts on the example tank, matching 0.00, 6.00, and 12.00 ft.

Work the whole path, transmitter to bar, in this order:

1. Force the float to 0.00, 6.00, and 12.00 ft and confirm the counts read 0, 500, and 1000 in the PLC.
2. Confirm the bar on the panel reaches empty, half, and full at those same three points.
3. Force the float past the ends, to -3.00 and 12.60 ft, and confirm the clamps hold 0 and 1000 while the alarm announces the fault.
4. Break the comms link in a safe moment and see what the panel shows for a stale tag, then brief the operators on that display so a frozen bar reads as a fault.
5. Watch one real fill or drain cycle if the process allows one safely.

Recommendation: Add one integer display tag in the PLC, scaled 0 to 1000 across the tank span with clamp rungs at both ends, and drive the shape's Y-axis sizing animation from it with matching limits. Take the bar meter object on the float only when the PLC program cannot be touched before the screen ships, and only after its border and solid background have been checked on the production screen.

Questions