With a generic EtherNet/IP driver the HMI panel is the server, so a value entered into a panel input register lives in panel memory. Cycle panel power and the value is gone unless Use Input Retentive is checked; Use Output Retentive is the matching switch for output-register data. A power-cycle test proves which values survive.
On a generic EtherNet/IP connection the HMI panel is the server, so a value an operator enters on the panel lives in the panel's own memory, not in the PLC. Use Input Retentive keeps that value alive across a panel power cycle. Use Output Retentive is the matching switch for data flowing the other way. Leave the box unchecked and a panel restart wipes the entry: the PLC reads the register's power-on value instead of what the operator typed. Both switches sit under Panel Manager, Direct Connection, and if the Help button on that page opens nothing on your software version, this is what they decide.
The panel is the server, so the data is panel-resident
With the generic EtherNet/IP driver, the panel and the PLC exchange fixed register blocks over an I/O connection. The panel maker documents the arrangement for one PLC client talking to one panel server, and the useful mental model is a remote I/O drop: the client reads and writes, the server holds the data. So the register your Numeric Entry object writes is panel memory. The PLC reads it over the network each time the I/O exchange runs, but the stored value sits on the panel, and what happens to it at a power cycle is decided on the panel side, inside the panel project.
What each retentive switch covers
The two switches split by register direction. An input register, on this connection, is written on the panel and read by the PLC; the maker's help file uses an operator typing a value into a Numeric Entry object as its example. An output register is the mirror direction: the PLC writes it and the panel reads or displays it.
| Register class | Written on | Read by | Survives a panel power cycle when |
|---|---|---|---|
| Input register | The panel (a Numeric Entry object, for example) | The PLC | Use Input Retentive is checked |
| Output register | The PLC | The panel | Use Output Retentive is checked, then proved by test |
The names describe the register class, seen from the panel's side of the connection. Checking either box changes only the panel's memory. It does not make data in the PLC retentive; that is the controller project's business.
What a panel power cycle takes, and what it leaves
Cycle power on the panel and its non-retentive register data is gone; the help file states it plainly for input data. The PLC loses nothing of its own, because the panel held the value in the first place. What comes back after the restart is each register's power-on value from the project.
Retention covers a value, not a history. Trend and log data live in files and buffers with their own rules: one panel maker documents that its logging backup is not designed to prevent data loss during an outage, and that you can expect to lose data from the previous 40 seconds when power fails. If trend history matters, plan to archive it off the panel; the check for that failure is in HMI trend lost after power cycle: archive it externally. And if the panel comes back to blank screens instead of wrong values, the project itself did not survive the restart; that failure has its own checks in HMI panel loses its project after a power cycle.
Example: a 250 setpoint must survive a panel power cycle
Inputs. One panel project connected over the generic EtherNet/IP driver, the panel acting as server, and one PLC as client; the maker documents the driver for exactly that 1-to-1 arrangement. A Numeric Entry object writing a panel input register, the help file's own example object. A test value of 250, chosen because no live setpoint in the plant equals it, entered as a plain number through the Numeric Entry object. Use Input Retentive starts unchecked, as the project shipped. The input register's power-on value in this project is 0.
Rule in words. On this connection the entered value lives in panel memory. A non-retentive panel register reverts to its power-on value when panel power is removed, so after the restart the PLC reads 0 instead of the entry. With Use Input Retentive checked, the panel keeps the entered value through the power loss and the PLC reads it back unchanged.
Test and arithmetic. Enter 250 on the panel and confirm the PLC reads 250; record both. Remove power from the panel only, leave the PLC running, restore panel power, and wait for the project to load. The PLC now reads 0. Lost data = entered value minus after-restart reading = 250 − 0 = 250. Check Use Input Retentive, transfer the project again, and repeat the same sequence. The PLC reads 250 after the restart, so lost data = 250 − 250 = 0.
Result. The same entry survives the power cycle only in the run with the switch checked: the arithmetic lands on 0 in that run and on 250 in the other.
Decision. The pass threshold is a difference of exactly 0 between the recorded before-reading and the after-reading. Any other result means the value is not being retained: first check that the edited project actually transferred to the panel, then that the tested value belongs to the input register class, then that the switch was checked on the connection the screens use.
Which values to make retentive
Check Use Input Retentive for panel-entered data the process needs across a restart: setpoints, target counts, batch identifiers typed at the panel. Leave values non-retentive when the machine must start from a known state, when the PLC rewrites them every scan anyway, or when a restored value could start an action the startup logic does not expect. When a value that keeps disappearing is a setpoint on the controller side, the cause and fix usually sit in the controller project; why an HMI setpoint resets to zero after a power loss walks that cousin of this failure.
When to use the tag-based driver instead
If the controller addresses its data by tag name, the panel maker's own recommendation for those controller families is the tag-based driver rather than the generic one. The generic driver is the tool for register-style controllers. Plan the connection on the tag-based driver from the start instead of discovering the retention question on the floor, and do not swap a working production connection mid-troubleshooting to chase one vanished value: identify which register class owns the value and run the restart test first.
Recommendation: On a generic EtherNet/IP connection, check Use Input Retentive for every operator-entered value the PLC must still hold after a panel restart, and leave Use Output Retentive off until a controlled restart has proved one real output-register value on your project. If the controller addresses data by tag name, plan the connection on the tag-based driver from the start and keep the generic driver for register-style controllers. Restart behavior is cheap to check before you standardize on a panel at all; the bench checks are in choosing an HMI panel: test startup and runtime first.
Questions
Does Use Output Retentive need the same restart proof as Use Input Retentive?
Yes, if any process depends on it. Input retention is the documented case: the maker's help file describes an operator-entered value that the PLC must still read after a panel restart. The published material does not spell out output retention in the same detail, so prove one real output-register value across a controlled restart, with before and after readings recorded, before anything downstream depends on it.
Why does the PLC project need a matching generic EtherNet/IP module?
The generic driver exposes fixed register blocks, not named tags, so the controller project is configured as a generic EtherNet/IP module whose input and output sizes mirror the panel's register map. If the two sides disagree on size or order, the PLC reads values from the wrong offsets. Match the sizes to the panel project, then confirm one known value in each direction before trusting the connection.
Is a lost register value the same failure as a lost project?
No. The retentive switches protect a data value in panel memory. A project loss takes the screens, the driver settings and the retentive flags together, and it has its own causes, from a failed transfer to a storage fault. If the panel restarts to blank or default screens, treat it as a project problem and check the project storage first.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.