Designing E-STOP circuits to ISO 13850 – when is a manual reset required, and when is an automatic reset acceptable?

Whether to use manual or automatic reset after an emergency stop has been triggered is best decided at the concept stage. Later, that decision is no longer a minor program setting and begins to affect the control architecture, drive and utility behavior, acceptance testing, user instructions, and the way disturbances are handled. In practice, the issue is not just the choice of reset type, but what state the machine reaches after the E-STOP is released and whether that state is safe without additional, deliberate human action.

Reset is not a detail

The question of reset after E-STOP is very often raised too late. Once the machine logic has been finalized, the process sequences written, and the control system assumptions defined for drive states and signals after loss of the safety function, changing the reset method is no longer a simple adjustment. It begins to affect the PLC program, safety functions in industrial automation, functional testing, documentation, and acceptance conditions. That is why the response after an emergency stop has been triggered should not be dictated by the designer’s habits or by pressure to shorten downtime.

This is an architectural decision. It needs to be tied to two questions: what state the machine is intended to reach after the emergency stop device is released, and whether that state is purely a safe state or already a state of readiness for motion. This is where the most common mistake occurs. It does not lie in choosing manual or automatic reset as such, but in the team failing to assess whether releasing E-STOP can bring the machine into a state the operator does not expect.

If releasing the button does more than clear the stop function, and also restores drive readiness, re-energizes pneumatics, or returns the process logic to a step from which motion can resume after a single start signal, this must not be judged solely in terms of convenience. You need to assess intended restart, prevention of unexpected start-up, and operating ergonomics: who performs the reset, from what location, and whether that position actually provides a clear view of the hazard zone.

What matters is the behavior of the whole system after the intervention, not just the E-STOP button itself. You need to know whether drives remain isolated, whether servo drives return to a ready state after release, whether the pneumatic system is re-pressurized after venting, whether signals in the controller are retained, and in what sequence acknowledgements and releases occur. A machine that remains stationary after the emergency stop is released and requires a separate, deliberate start command must be assessed differently from one that returns to an intermediate process step and almost automatically recreates the conditions for motion.

This is where the key design criterion emerges: do not start by asking what is formally permitted, but what machine state will actually occur after the E-STOP is released and whether that state is safe without additional human action. The normative reference helps structure that assessment, but it does not replace it. The focus is not on operator convenience, but on ensuring that reset does not itself create a hazardous situation.

Where risk and cost really increase

Most design errors do not occur where the machine simply stops after E-STOP is triggered, but where the stop occurs in an intermediate state. This applies in particular to packaging lines, robot cells, clamping systems, multi-axis drives, and circuits with stored energy in pneumatics, hydraulics, or mechanical components. In such systems, removing the cause of the stop does not yet mean it is safe to return to operation.

The product may remain jammed, an axis may stop outside a safe position, a gripper may still be holding the part, and pressure or torque may still be acting on the mechanism. In that situation, the choice between manual and automatic reset is not about operator convenience, but about what machine state is actually created after E-STOP is released and whether the person correctly interprets it.

From a design standpoint, the most dangerous solutions are the intermediate ones. Formally, they do not start the cycle, but in practice they restore the machine’s ability to move or trigger auxiliary motion. Automatic reset is tempting where availability and a fast return to production matter, but after E-STOP is released, the controller may restore drive readiness, arm outputs, restore pressure, or release brakes. The operator then sees the machine as still stopped, even though from the standpoint of energy and control logic it is no longer passive.

These are exactly the kinds of semi-automatic behaviors that most often lead to disputes during acceptance. The machine does not restart a full cycle on its own, but it regains energy, clamps a part, moves to a home position, or activates an auxiliary function. From a design perspective, these are not interface details, but decisions about the boundary between permissible restoration of readiness and impermissible resumption of operation.

In practice, the issue is usually mixed in nature, combining safety with work organization. A manual reset reduces the risk of unexpected restart, but if it is poorly designed, it quickly creates costs of its own. If the reset button is located outside the visible area of the zone, requires extra walking, or is not clearly separated from E-STOP release and the start command, operators begin to treat the procedure as an obstacle. That is when workarounds appear, along with maintenance interventions, instruction updates, and additional training. If the user cannot clearly distinguish between releasing the mushroom button, resetting the safety circuit, and restarting the process, the problem lies not only in the wording of the standard but in the entire operating architecture, including HMI messages and the division into machine zones.

A good example is a cell with a conveyor and a pneumatic gripper. After E-STOP is actuated, the conveyor stops, the gripper remains in an intermediate position, and the part is not set down. Once E-STOP is released, the control system restores the pneumatic supply because there is no separate logic for safely relieving the system. Formally, no start command has been given, but the cylinder regains energy and the actuator makes a short, unexpected movement caused solely by the return of pressure. This kind of case can be difficult to reproduce during testing, but it very quickly undermines the user’s trust in the machine.

The consequences go beyond the risk of injury itself. Maintenance interventions appear, acceptance is prolonged, the program needs correction, exceptions are added to the instructions, and disputes arise over whether pressure or drive torque should be removed after E-STOP, or whether it is enough merely to block further motion commands. Similar problems occur with automatic homing after a stop and with a central E-STOP circuit covering zones with different visibility and different effects when energy is restored.

At this stage, referring to EN ISO 13850 and emergency stop requirements helps bring order to the discussion. The mere fact that releasing E-STOP does not trigger a full cycle start does not in itself determine whether the solution is acceptable. It is necessary to assess whether the return of energy, restoration of drive readiness, gripper actuation, axis brake release, or movement to the home position creates a hazardous condition or one that is misleading to the operator. That is why, in practice, the focus should be not on the reset signal alone but on the entire sequence.

How to make the design decision

The decision on reset after emergency stop actuation should begin with a description of the machine states, not with a question of operator convenience. It is necessary to define clearly what happens after E-STOP is pressed and after it is released: which energy paths are disconnected, which remain energized, whether drive readiness is restored, whether axes are unbraked, whether cylinders can complete movement due to residual pressure, gravity, or stored elastic energy, and whether any automatic sequence exists once readiness is restored.

Only on that basis can you determine whether releasing the mushroom button is neutral from a safety standpoint or whether it already constitutes a change of state that may expose a person to risk. If releasing E-STOP restores energy in a way whose effects the operator cannot fully see, or that may change the position of actuators, then a manual reset becomes the starting point. If, on the other hand, release does not cause movement, does not restore hazardous energy, and does not initiate any sequence, an automatic return to the ready state may be considered, but only if further process start-up requires a separate, unambiguous command.

In practice, it helps to separate three actions that are too often combined into one signal or one operator message. Releasing the emergency stop device is a mechanical action and means only that the button has returned to the ready position. Resetting the safety function is a separate confirmation that the safety conditions may again be regarded as fulfilled. Process start-up is something else again: the decision to begin movement or resume the cycle.

If these levels overlap, the user stops understanding whether releasing E-STOP already starts something or merely removes a lockout, and the design team loses the ability to defend the adopted logic during conformity assessment for machinery. For the same reason, the location of the reset button is a design issue, not a cosmetic one. The person performing the reset should be able to assess the zone for which readiness is being restored, or the system must provide another reliable method of confirming the condition.

In more complex lines, this may mean a local reset for a given zone while keeping the rest of the installation ready, but only if the zone boundaries, dependencies between drives, and the effects of restoring energy are clearly defined. Such a decision must result from functional design analysis, not from a desire to simplify operation.

A good decision test is to describe the sequence, not just the electrical schematic. The team should be able to answer several check questions:

• whether releasing E-STOP restores energy or actuator readiness in a way that has a tangible effect on the machine,
• whether any movement can occur without a separate start command,
• whether the person performing the reset can see the entire zone and can rule out the presence of a person and any intermediate process state.

If the answer to any of these questions is not unambiguously safe, automatic reset becomes difficult to justify. This applies in particular to systems where, after stopping, the part remains clamped, the actuator has stopped in an intermediate position, the axis is held by torque, or loss of locking could cause dropping or movement. In such cases, manual reset is not a formality; it forces a deliberate check of the situation before readiness is restored.

By contrast, where the system remains passive after the E-STOP is released and motion requires a separate operator action or a higher-level sequence, automatic reset can reduce downtime without lowering the level of safety. One example is a station with a guarded work area and a drive that loses the ability to move after an E-STOP, but after release regains control power and a ready state without moving any axis or actuator. The same controller setting becomes questionable, however, in a transfer machine where releasing the E-STOP releases an axis brake, restores pressure to directional valves, or allows an interrupted sequence step to be completed.

That is why the decision must be captured not only in the code, but also in the design documents: schematics, the state matrix, the restart sequence description, HMI messages, jam-clearing procedures, and factory acceptance test scenarios. If this logic cannot be explained to the user in one coherent description—what releasing the E-STOP does, what reset does, and what starts the process—it is usually a sign that the division of functions is wrong or overly complex.

Practice first, then the normative reference

In practice, the reset method after an emergency stop has been triggered is not determined by the function name, but by the answer to a simple question: what exactly will happen to the machine after the mushroom button is released, and is that state unambiguously safe. This is a design decision, not a user preference or a shortcut carried over from a previous project.

The team should be able to describe the full chain of events: stopping, removing energy to the level required by the risk assessment, releasing the device, resetting the function, confirming readiness, and only then restarting. If any of these stages overlaps with another or depends on the controller’s default behavior, it creates room for disputes during acceptance and for operating errors that cannot later be corrected by the manual alone.

This is easy to see when retrofitting an existing cell where the user expects shorter stops after minor disturbances are cleared, and the integrator proposes automatic reset after releasing the E-STOP to simplify operation. At the level of a general description, the solution looks reasonable: the operator removes the cause of the stop, releases the device, and the machine returns to readiness without an additional reset button. The problem appears only in the intermediate state.

If, after the working medium is restored, the actuator regains pressure in a position where it can make a stroke, advance, or unload the gripper without a new operator command, then returning to readiness is no longer a neutral logical state. In reality, it becomes part of the process motion, only hidden under a different name. Such a case usually requires more than minor program changes; it calls for a return to the function architecture: separating release from reset, adding explicit readiness confirmation, or redesigning the venting and re-energization sequence.

This example also shows what design evidence matters. It is not enough to declare that nothing starts after release if the acceptance tests did not verify the behavior of drives, valves, brakes, and sequence steps at the exact moment the E-STOP was released. The technical documentation for machinery should include a risk analysis entry for this scenario, a description of states on the HMI, a test scenario after releasing the emergency stop, and clear confirmation by the user of the agreed restart logic. These are the materials used later to assess whether the solution is consistent: during machine acceptance, when updating procedures for entering the zone or LOTO procedures, when handling exceptions for setup and service mode, and, in the event of an incident, when determining whether the operator could have foreseen the system’s behavior.

Only against that background is it worth referring to ISO 13850. The standard clarifies the role of emergency stop: it is intended to stop a hazardous process or reduce the effects of a hazard, and releasing the device must not in itself create a new hazardous state. For the designer, the practical conclusion is simple: returning the E-STOP device itself to the released position cannot replace the deliberate action required by the machine safety concept.

In the Polish and EU context, however, this is not only about logical compliance with the standard. Equally important is the consistency of the entire solution with technical documentation compliant with the Machinery Directive, the operating instructions, the results of the risk assessment, and, after modification, the scope of the updated validation of safety functions. These are the elements that will later be examined in the supplier–user relationship, not a single entry in the controller program.

The practical conclusion is clear. If the designer cannot show what happens after the E-STOP is released, which energies are restored, which components may change position, and why that condition is safe, procedural exceptions such as “the operator should not be standing in the zone at that time” should not be added. The solution is to go back to the function, the sequence, and the division of responsibility between release, reset, and restart. Only a solution that can be justified in the schematic, during acceptance testing and machine safety assessment, in the manual, and in the risk assessment can be considered technically mature.