HMI indicator button that also changes screens

Can one indicator button also change the screen?

One object can do both jobs only when the panel's software has an event manager: the pushbutton toggles an internal tag and the tag's on-state event runs the screen change action; without it, use two objects, an indicator light with a screen change button beneath.

The event-manager build gives the operator a single target: press it, the internal tag flips, the tag event fires on the transition and the panel opens the diagnostics screen. The two-object build reaches the same result with objects every panel family offers, and it fails in friendlier ways: if the light is bound wrong the navigation still works, and if the button target is wrong the condition still shows.

The screen change button in either build is the standard navigation object covered in Set up HMI screen navigation with change screen buttons. Give it a word label such as FAULT DETAILS so its job is readable at a glance.

Navigation at the panel serves the operator standing in front of it. When the same condition also has to be readable from across the cell, that is a separate notice-display job, and our shop-floor and andon-style boards are built for it.

Which method does your panel support?

Look for an event manager or a tag-event list in the navigation area of the programming software: if it is there, one pushbutton can do both jobs, and if the function area only offers a tag database, plan the two-object build instead.

Work down this list before you write any objects:

• An event manager, an events section, or any way to attach an event to a tag means the one-object build is available on that panel family.
• The documented scale of the feature varies. One vendor documents up to 16 actions from a single event, with screen change, writing a tag value, playing a sound file and sending an e-mail among them. If your software's documentation lists the same feature, plan on the tag-event build.
• A tag database on its own is storage. The event exists only where the software lets you attach a trigger and an action to a tag, so adding a tag and finding no event properties means the feature is absent, not hidden.
• Two documented routes cover software without a classic event manager. Some runtimes attach a value-changed event straight to a tag or variable. Others follow a screen number tag of integer type that the controller writes, set to update continuously, and activate the screen by number when the value changes.
• Small panel families commonly ship without these features at all. Once you have looked through the function or events area and found nothing, stop searching and build the two-object version.

Recommendation: build the two-object version, an indicator light with the screen change button directly beneath it, unless your software documents an event manager or tag events and you specifically need a single touch target; on a panel that has tag events, trigger on the tag's on state and point the screen change action at the diagnostics screen.

What do you need before you build either version?

You need the fault tag address from the PLC program, the diagnostics screen already built in the project, the panel's programming software on your laptop, and the transfer method the panel family uses, usually a USB or Ethernet download.

Gather these before you touch the layout:

• The fault tag address, and what it means in the controller program: the bit or value that goes to its bad state when the condition you are indicating occurs.
• The diagnostics screen already in the project, with the detail content on it and its own plain screen change button for the return trip.
• The panel programming software on your laptop and a saved copy of the current project, so you can roll back if a download goes badly.
• A window when the panel can come out of service, because you will download a project and force a test condition.

How do you build the two-object version on a small panel?

Build the status and the navigation as two separate objects on the source screen: an indicator light bound to the fault tag, and a screen change button placed directly beneath it with its destination set to the diagnostics screen.

The steps:

1. Open the source screen and place an indicator light object. Bind it to the fault tag and set two states: the normal color for the good condition and red for the bad one. If the equipment behind the condition has no lamp of its own to copy, the object choice is the same as when you build an HMI I/O indicator screen for a module with no LEDs.
2. Test the light before adding navigation. Force the condition from the controller or the simulator and watch both states. If the light is bound to the wrong address, fix it here; a navigation button cannot repair an indication.
3. Place a screen change button directly beneath the light so the two read as one group, and set its destination to the diagnostics screen.
4. Label the button in words, FAULT DETAILS or the equivalent in the operators' language, so its job is carried by label and position as well as color.
5. Open the diagnostics screen and check that its return screen change button targets the right screen. If more than one screen leads here, set and verify a return target for each path.
6. Save the project and download it to the panel through the family's normal transfer workflow.

How do you build the one-button version with an event manager?

Use the event manager build when the software offers tag events: configure the pushbutton as a toggle that writes one internal tag, add a tag event on that tag's on state, and assign the screen change action with the diagnostics screen as its target.

The steps:

1. Create one internal tag in the project's tag database. It exists only to carry the trigger.
2. Configure the pushbutton as a toggle that writes that tag on each press, the pattern documented for one-button toggle control, with no logic needed in the controller.
3. Give the pushbutton two graphic states driven by the same tag so it reads as the indicator as well, the same technique as showing two text states from one PLC bit.
4. In the event manager, add a tag event with the trigger set to the tag's on state, which is the off-to-on transition of a press, and assign the screen change action with the diagnostics screen as the target. On panels whose documentation lists more actions, the same event can also write a tag, play a sound or send an e-mail.
5. Keep the plain screen change button on the diagnostics screen for the return trip.
6. Download the project and test with a forced press before the panel goes back into service.

This is the same event-driven screen change described in changing screens when a PLC alarm bit turns on, with the toggle supplying the transition the alarm supplies there.

What does a worked example look like on a small panel?

A 4.3 inch panel at 480 x 272 pixels gives a pixel pitch of 0.198 mm, so at a 2 ft viewing distance the button label needs capitals about 13 pixels tall and the button underneath works at 160 x 48 pixels.

The scenario: a cell control on a small panel assumed to be a common 4.3 inch format, 16:9, 480 x 272 pixels, with the operator standing 2 ft away. Treat the panel numbers as the example's inputs and substitute your own panel's diagonal and resolution; the arithmetic is the same.

Screen area: width = 4.3 × 16 / √(16² + 9²) = 4.3 × 16 / 18.36 = 3.75 in = 95.2 mm, height = 4.3 × 9 / 18.36 = 2.11 in = 53.6 mm. Pixel pitch: 95.2 mm / 480 px = 0.198 mm per pixel.

Label height: signage planning starts from 30 ft of viewing distance per inch of letter height, an FHWA planning figure, and 20 ft per inch is the safer choice for fast reading. At 2 ft the 30-to-1 ratio allows 2 / 30 = 0.067 in = 1.7 mm of capital height, about 9 pixels. The 20-to-1 ratio asks for 2 / 20 = 0.1 in = 2.5 mm, and 2.5 / 0.198 = 12.6, so the label gets 13 pixel capitals. A fault control is read at a glance while the line runs, so use the 13 pixel figure.

Button: 160 x 48 px converts to 160 × 0.198 = 31.7 mm wide by 48 × 0.198 = 9.5 mm tall. The label FAULT DETAILS is 13 characters; at 13 pixel capitals a typical character box runs about 8 px wide, so the text occupies 13 × 8 = 104 px, leaving 160 - 104 = 56 px, which is 28 px of padding per side.

Indicator light: a 24 px circle measures 24 × 0.198 = 4.8 mm across, which reads cleanly as a status pip at 2 ft. Keep the label to one line; a second line needs 1.7 × 13 = 22 px of line spacing.

Result: the group stacks to 24 + 4 + 48 = 76 px tall by 160 px wide, which is 160 / 480 = 33 percent of the screen width and 76 / 272 = 28 percent of its height. It sits beside the process graphic with the line label and the rest of the screen still free.

How do you check the whole path before the shift starts?

Test the two halves separately, then together: force the fault condition and watch the light, press the control and confirm the diagnostics screen opens, read the details, take the return button back, then clear the condition and watch the light drop out.

Run the checks in this order:

1. Put the machine in a safe test state and force the fault condition from the controller or the simulator.
2. Watch the light reach its red state. If it stays in its normal color, the fault is in the tag binding or the condition logic, and no navigation change will fix it.
3. Press the control. On the two-object build the button opens the diagnostics screen; on the event-manager build the toggle fires the tag event and the same screen must open.
4. Read the details on that screen against the forced condition. Opening the right screen and showing the right values are two separate results, so check both before signing off.
5. Take the return button and confirm the source screen comes back.
6. Clear the condition and watch the light drop out, with navigation still available throughout.

When something fails, sort it by half:

• Light wrong, navigation right: the fault is in the light's tag binding or the condition logic.
• Light right, navigation wrong: on the two-object build, check the button's destination; on the event-manager build, check the event's trigger state and the action's target screen.
• Screen changes once, then refuses a second change: that is a different fault with its own fix, covered in resetting the screen change tag.

Questions