Keep HMI indirect register selection and math in the PLC

What indirect register selection means

Indirect addressing is the documented way a PLC addresses an operand whose address is calculated at runtime: one register holds a number, the PLC treats that number as the address of another register, and it reads or writes through it. PLC and panel manuals both use the term, and it means the same thing in each: the address is computed while the program runs, not fixed in the tag.

The distinction that matters is where the number lives. A numeric tag on the panel that increments when the operator presses a button is panel data. It becomes an address only after a PLC instruction takes it, checks it and resolves it. If the number sits on the panel and the PLC never sees it, no register selection is happening: the panel is counting.

So commit to one arrangement. The selection value lives in a PLC register, written there by the panel over the ordinary tag link.

Why the panel should not own the address

An operator-entered number with no bounds check can read data nobody asked for, or write into a register another part of the machine depends on, and the machine will follow whatever it finds. The panel has no view of the register map, so nothing inside it can prevent that.

Keep the logic in one place for the troubleshooting reason as well. When selection, validation and math sit in one PLC routine, the next technician reads that routine and sees every allowed destination. When they are spread across panel objects, the same question needs two programs and a cable.

A recipe stays what its documentation says it is: a defined group of values loaded as a set. A general pointer into the register map is a different job, and the indexed path with a request bit does that job.

The request-and-response handshake

Give the exchange five logical values. Tag names and addresses follow the project's conventions; the roles are fixed:

• Selection: the operator's index, for example 0 to 15.
• Request: one bit the panel sets and the PLC clears, so a completed request cannot fire twice.
• Operand: the value to write, present only when the request is a write.
• Result: the value the PLC resolved or computed.
• Status: 0 for done, 1 for rejected, 2 for received and pending, in this article's convention.

The request bit separates intent from arithmetic. A changing selection is a number changing, and a number changing authorizes nothing. The operator sets the selection, then presses request; the PLC executes once, publishes the result and status, and clears the request. Publish the result to a fixed panel register, the same mechanism as writing a screen number from the PLC to a panel register, and show the status word beside it so a rejection is visible without opening a diagnostic screen.

If the same pattern runs across a network transfer instruction and its done bit never sets, work through a troubleshooting page for a transfer instruction's done bit that never sets before touching process data.

Bound the selector before any read or write

Take the range from the application's register map, then put one compare against the low bound and one against the high bound ahead of every indexed access or mapped branch. A 16-station machine defines indexes 0 to 15, so the PLC rejects 16 and above and every negative entry before any register is touched. On rejection the PLC sets the status word to the rejection code and changes no process register.

The same discipline covers paired values. An upper limit entered below its lower limit should be stopped before the PLC acts on it, which is the habit behind keeping a high and low setpoint pair valid before the values reach the PLC.

Put the arithmetic in the PLC

Read one register, add a number, write another register: that is one PLC routine with a fixed source, an operand, a destination and a trigger. The panel formats numbers for display; process math stays in the ladder or structured text, where the scan order, the data types and the fault behavior are defined.

Decide the operand's data type, signedness and scaling from the register definitions, and decide the overflow behavior at the top of the range. If the source and destination can be the same register, decide whether that case is allowed and test it deliberately. These are register-map decisions, and none of them is settled by how the value looks on the panel.

Worked example: read a preset, add 250, write it back

Scenario: a machine map holds 16 timer preset registers indexed 0 to 15, values in 0.1 s steps, and the operator wants preset 3 raised by 25.0 s. The interface carries five values: selection, request, operand, result, status.

1. The operator enters 3 as the selection and 250 as the operand, then presses Read. The panel writes selection = 3, operand = 250, request = 1.
2. The PLC sees request = 1 and compares: 0 ≤ 3 and 3 ≤ 15. Both pass, so status = 2, and index 3 resolves to the fourth preset register in the map, which holds 1250.
3. The PLC copies 1250 to the result register, adds the operand, 1250 + 250 = 1500, and writes 1500 to the destination register the map names. It sets status = 0 and clears request.
4. The panel displays result = 1500 (150.0 s) beside status = 0. The panel never addressed memory; the PLC ran two compares and one add.

Rejection path: the operator enters 18 and presses Read. The compare 18 ≤ 15 fails, so status = 1, request is cleared, and no register is read or written. The panel shows the rejection beside the entry field.

What this changes on the floor

The panel project shrinks to ordinary objects: two numeric entries, two buttons, two display fields. The logic sits in one PLC routine, so carrying the pattern to the next machine means changing the range and the map. Test the write path with noncritical data and the machine in a safe state before any motion depends on it, in the same order as an operator panel PLC link setup that tests writes before motion.

One safety note: on a machine that will run, never let an unbounded operator number become a write address. The bounds check ahead of the indexed access is what stands between a typed value and a register the machine depends on.

If the line also needs a notice board or an andon-style status board beside the machine, that is a separate screen with a separate decision, covered in factory status display or operator HMI. We build Android signage displays for boards like that; they are not operator panels and they do not stand in for the HMI discussed here.

The decision

Recommendation: keep the selection, the bounds check and the math in the PLC whenever the target register varies with operator input, and give the panel three jobs: hold a selection inside the application's range, set a request bit, and display the returned value and status. For a fixed target register, skip the handshake and bind the display object to the register directly. Use the panel software's own dynamic-address feature only where the manual for the installed software version documents it for your driver, and keep the PLC-side bounds check even then. For the arithmetic, write one PLC routine per operation, with type, scaling and overflow decided from the register map.

Questions