A startup ON button blocks the setup menu: fix the project first

Why does the panel show OFF for one second and then ON at power up?

The OFF-to-ON change you see is the project starting, not a hardware fault: the panel boots straight into the runtime, your momentary ON pushbutton sits on the screen the runtime loads first, and its state flips to ON the moment that screen appears.

Each symptom in this setup points to one thing:

• OFF for about 1 second, then ON, on every power up. The same screen loads on every boot, so the same transition repeats. The object's state goes ON as the startup screen is displayed.
• F1+F5 appears to do nothing. The two function keys are the documented setup entry on this panel family, and they belong at the instant power is applied. Once the project screen is live, that power-up window is gone.
• No reset button on the back. Correct for this panel. Recovery runs through the programming link and an edited project, and a factory restore would not help anyway, because the pushbutton lives in the project file.

How do I open the setup menu with F1+F5 during power up?

Press F1 and F5 together at the instant you apply power: the documented entry on this panel family is the two function keys F1+F5, and the OFF period your screen shows gives you about a 1-second window before the project takes over.

Hold both keys until the setup screen appears. If the first attempt lands after the project screen is already up, cycle power and press again the instant the display wakes. The setup screen holds panel-level settings, the items that live outside your project, and reaching it confirms the panel itself is healthy.

What setup cannot do is edit the project, so the ON command returns on the next boot until the file changes. Tapping the screen does nothing in this entry method; if you have been hunting for a hidden corner tap, our article on hidden setup screen access explains why taps never open it.

Is there a reset button or a factory reset on this panel?

No: there is no rear reset button on this panel, as you found when you checked the back, and the documented recovery runs through the programming link and the project file instead of a factory restore.

A factory restore would not fix this case even if one existed. The ON pushbutton lives in the project file you transferred, so a wiped panel would take the same project back and show the same symptom. The file is the thing to edit, and the link is the way in. A power cycle does not erase a project on its own; when a panel does lose its project around a power cycle, our article on panels that lose their project after a power cycle covers what actually wipes one.

How do I stop the ON button from firing when the panel starts?

Open the project in the panel's programming software, save a copy, then delete the momentary ON pushbutton from the startup screen or move it to a screen the operator opens deliberately, so nothing writes ON while the first screen loads.

Work in this order:

1. Save a copy of the project as it stands. That copy is your restore point if the revised project needs to go back.
2. Select the pushbutton and read its properties. The label "not a toggle" says little; the properties screen shows which tag or bit the object drives and when it writes: while pressed, on release, or whenever the screen is displayed. Confirm the address before you change anything else.
3. Clear the startup screen. Delete the pushbutton from it, or move the control to a screen the operator opens on purpose. If the machine needs the command, an operator-pressed action behind that deliberate screen change is the safe form; a button nobody has touched should never drive its bit ON at boot.
4. Leave the controller logic alone. Adding logic that forces the bit OFF at boot hides the display symptom and buries real faults under it.

Transfer comes next, and the check that proves the fix is simple: the OFF-to-ON transition disappears from power-up.

How do I transfer the fixed project back to the panel?

Connect the panel to the programming software over its documented link, USB or Ethernet on this family, start the transfer from the software, and cycle power if the panel comes up with a runtime error after the copy.

The hardware manual for the EA1-S3ML names a bad serial connection during a project transfer or firmware update as the most common cause of runtime errors, and its remedy is to cycle power and retry. Do one job at a time: this is not the moment to update firmware as well.

If the software never connects at all, the link is the suspect before the project is, and our article on the HMI programming cable power pin covers the check that comes first. If the panel refuses every transfer and setup stays shut, stop before undocumented reset sequences: no pin shorting, no wiring changes, no key combinations nobody documents. Take the panel maker's documented support path from there.

Can you show me an example of the fix from start to finish?

A bench panel on a packaging line shows OFF for 1 second, then ON at every power up, so the operator can never reach setup, and the example carries the fix through its numbers: three power cycles per shift, three unwanted ON states per shift, nine per day.

Situation. An EA1-S3ML on a packaging bench gets power-cycled 3 times per shift during commissioning, across 3 shifts a day.

Count. Every power-up produces exactly 1 OFF-to-ON transition on the startup screen, which you watch happen. 3 cycles per shift × 1 transition = 3 uncommanded ON states per shift; 3 shifts × 3 = 9 per day. Count transitions, not outputs: a displayed ON state is not, by itself, proof that an output coil energized, and the object's properties from step 2 are where you confirm the address behind it.

Timing. The setup window is the OFF period, about 1 second. Visual reaction to a cue you are watching for runs about 0.25 s, so pressing F1+F5 at the instant power lands fits with margin to spare; pressing after the screen shows ON means the 1-second window is already spent.

Fix and result. Save the project, delete the pushbutton from the startup screen, transfer over USB, power-cycle. The startup screen now comes up with 0 OFF-to-ON transitions, so 3 unwanted ON states per shift drop to 0, and F1+F5 pressed at power application opens the setup screen when you need it. The ON command the machine still needs waits behind a screen the operator opens on purpose.

What if the setup menu still will not open after the fix?

Compare what the panel shows with what the connected controller sees before you touch anything else: if the controller's copy of that bit reads OFF while the panel draws ON, the object's write behavior is what is left to correct, and if both read ON something else is driving it.

Work one factor at a time:

• Both places read ON: trace the controller logic and any other command source that can set that bit.
• The panel draws ON and the controller reads OFF: the write behavior still lives in the object, so go back to its properties and the startup screen.
• A power cycle alone does not prove the panel took the new copy, so watch the startup screen for the missing transition as your confirmation.

Then verify the repaired startup sequence end to end: confirm the object writes only when an operator acts on it, run a deliberate test with the machine still isolated, and restore the isolation only after the machine state has been checked. Our article on operator panel PLC link setup puts test writes ahead of motion for exactly this reason, and when you hang the next panel, our article on testing HMI startup and runtime first catches a startup command at the bench before it reaches the floor. Record the object action and the address that changed; that one line in the log separates a future panel startup question from a controller fault.

Recommendation: For any panel in this family with this symptom, fix the project and leave the hardware alone: keep objects that write their address ON off the screen that loads at power up, transfer the revised project over USB or Ethernet, press F1+F5 only at the instant power is applied, and if setup stays shut while every transfer fails, take the panel maker's documented support path instead of hunting for undocumented resets.

Questions