Build an HMI I/O indicator screen for a module with no LEDs

What one lamp shows

Every lamp on this screen binds to one bit in the controller's data, and that bit means different things on the two sides of the module.

On the input side, the controller's input image follows the module's input circuit. A lit input lamp means the module sees voltage at its input terminal, exactly what the missing LED would have shown. That is the fact the grid exists to deliver, and it is strong enough to plan a diagnosis around.

On the output side, the lamp shows the output image, and the output image is the command. A lit output lamp means the controller has switched the point on. It is not a current reading: a blown fuse on the output common or a failed load leaves the lamp lit while the load sits dead. Header the two grids so nobody forgets which side they are on: Input state over the inputs, Output command over the outputs.

Both images also freeze when the panel loses its link to the controller, and a frozen lamp reads exactly like a quiet machine. The steps below add a heartbeat element so a stale grid announces itself.

What you need

• The controller's I/O configuration for the module: slot number, point count, and the address or tag of every channel.
• The electrical drawings for the terminal strips, including which channels share a common.
• A saved copy of the HMI project and your site's approved way to download a project to the panel.
• The site's electrical safety procedure, for the live check at the end.

Build the grid

1. Map the module before you draw. From the I/O configuration, list the slot, every channel number, and that channel's tag or address, with the terminal number from the drawings beside it. Trace 3 or 4 channels spread across the module from terminal screw to tag before you trust the table. An address inferred from physical position, or a tag list carried over from another machine, produces a grid that lights convincingly and lies.
2. Lay the grid out like the terminal strips. Most 32-point modules split the field wiring into four groups of 8 with one common per group; confirm yours on the drawings, then draw 4 rows of 8 lamps so each row sits on one common. Keep inputs and outputs on separate grids and title each one with its slot: Slot 3 inputs.
3. Bind every lamp to the verified tag. One indicator object per cell, bound to the exact tag or address from the step 1 table. If the project keeps I/O inside a structured tag, bind to the member inside that tag; it is the same technique that reads a PLC timer value on an HMI with member tags. The screen reads; it never writes to the controller.
4. Make every lamp readable without color. Size the labels for the distance a technician actually reads from; the worked example below carries the arithmetic. Pair each state color with a second cue, ON and OFF text or filled and outline shapes, so the grid reads the same to a technician who sees red and green as the same color. Label each cell with the channel number and the device name from the drawings: Ch 12 infeed photoeye. Mark unwired channels dimmed and labeled SPARE.
5. Give the grid a heartbeat. Bind a connection-status element in a corner box, or a bit the controller toggles a few times a second, so it drops out when the link drops. A dark heartbeat next to a full grid is the difference between stale data and a quiet machine.
6. Save, then download, then file the map. Keep the pre-change project copy, send the project to the panel through the approved process, and put the step 1 point map where the next tech looks: with the drawings, or on the panel itself as one of the readable maintenance procedure pages the HMI can carry.
7. Give the screen a front door. Add it to the panel's screen selector menu so anyone reaches it in two touches. Then let the controller do the reaching: changing HMI screens from the PLC drops the grid in front of the operator the moment a fault bit stops the machine.

Example: a 32-point input module in slot 3

Scenario: a palletizer has a 32-point DC input module in slot 3, mounted mid-cabinet, wired as four groups of 8. No LEDs on it anywhere.

• Rows. 32 points at 8 per row: 32 ÷ 8 = 4 rows of 8 lamps, one row per common group.
• Label size. The technician reads the panel from about 3 ft. The FHWA planning figure gives 30 ft of viewing distance per inch of capital letter height, and 20 ft per inch is the safer figure for fast reading. At 20 ft per inch, a 3 ft reading distance needs 3 ÷ 20 = 0.15 in capitals, so the channel labels are drawn at 0.15 in capitals or larger.
• Update period. Set the tag group feeding the grid to 250 ms, a working choice for a machine HMI on its own link. A point that changes appears within about a quarter of a second plus one controller scan. On a shared link, 500 ms still reads as instant; past about 1 second, people stop trusting the grid.
• Test. With the palletizer at rest and locked out, block the infeed photoeye with a card. The lamp labeled Ch 12 infeed photoeye flips on within half a second of the beam breaking.

Result: the whole module reads at a glance in about 2 seconds, and a dark row now says check that row's common fuse before anyone touches a meter.

How to check it worked

Three checks, in this order.

1. Re-trace 3 channels at random: lamp on the screen, tag in the project, screw in the cabinet. All three agree.
2. Operate one real input you are allowed to move at rest, with the machine locked out where the procedure calls for it. Its lamp follows within the update period you set. Meter work inside a live cabinet belongs to whoever the site qualifies for it; take readings at rest wherever that is possible.
3. Run a normal cycle and watch one output lamp against the sequence diagram, then compare two or three lamps with the controller's own values at the same moment. PLC live debug on a bound controller shows how to watch the data table while the machine runs.

One controlled point transition should agree at all three stations: the terminal, the controller data, and the lamp. If they ever disagree, stop using the grid for diagnosis until the binding has been re-traced.

Reading a fault from the grid

• One lamp stuck. An input stuck on while the machine says off is a held sensor, a jammed actuator or a conductor chafed to supply. An input stuck off is a failed sensor, a broken wire or missing voltage on that channel.
• One full row dark. Eight lamps in one line going out together is that row's common terminal, usually its fuse. It is a supply problem, not eight simultaneous sensor failures.
• Output lamps lit, load dead. The command arrived and the current did not: fuse, wiring or load. Compare against a feedback input if the machine has an auxiliary contact to spare.
• The whole grid frozen. Communications, not I/O. Check the panel's link first, then the module's own network status; a flashing I/O light after adding an Ethernet module is a module-side story, and it freezes every lamp on the screen, not one.
• Grid and machine disagree everywhere. Suspect the bindings and re-run the step 1 trace before anyone replaces a module.

When the machine HMI is the wrong screen

One grid per machine covers the technician standing at the panel. The rest of the line cannot see it. A line-side board that mirrors the same fault bits at the end of the aisle is a job for shop-floor signage: a display running your own Android app can carry a wall version of the board, with the app doing the data work, and whether live factory data belongs on signage or a dashboard is its own decision. Keep the HMI grid for the person troubleshooting; keep the wall for the shift.

Recommendation: build one 4-by-8 grid per 32-point module, bound point by point to a traced map, with a heartbeat on the same screen and a place in the panel's screen selector menu. Build it first for the worst module, the one mid-cabinet with no lights, and carry the layout into every new HMI project as a standard screen. The layout copies in minutes; only the bindings need re-tracing, one lamp at a time, on each new machine.

Questions