> For the complete documentation index, see [llms.txt](https://docs.voltmasters.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.voltmasters.io/dso-rtu/io-module-emergency-stop.md).

# IO module emergency stop

For installations that require a **physical** emergency stop, the DSO RTU emergency-stop signal can drive one or more relay outputs on a **Moxa IO module**. When the grid operator triggers an emergency stop, the EMS drives the configured relay output(s) to their stop state. Those relays are wired into the installation's emergency-stop circuit.

This is the hardware layer described in [How DSO RTU works](/dso-rtu/how-telecontrole-works.md). It is **in addition** to the software stop; assets are always curtailed in software as well.

{% hint style="info" icon="lightbulb" %}
Use the IO module when a stop must be enforced **independently of the asset's own communication**, for example to drive an external contactor, an EPO loop, or the emergency-stop input of switchgear.
{% endhint %}

The IO module can do two things for emergency stops:

* **Carry out an emergency stop** — a relay output (DO) is switched to its stop state. Most of this page is about this.
* **Trigger an emergency stop** — a digital input (DI) connected to a physical contact (such as a stop button) can switch the emergency stop on by itself, on top of the one the grid operator can send. See [Triggering an emergency stop](#triggering-an-emergency-stop-digital-input) below.

### The hardware

* **Module:** Moxa ioLogik E1214 with 6 digital inputs (DI) and 6 relay outputs (DO).
* **Communication:** Modbus TCP/IP.
* The relay outputs are potential-free contacts that you wire into the installation's safety/stop circuit. The digital inputs are available for status feedback if needed.

### Place the IO module

Where the module goes, and **how many modules you need**, depends on the physical layout of the installation. A relay must be wired to the asset or switchgear it has to stop, so a module is placed close to those assets; an installation spread over several cabinets therefore needs a module in each cabinet that has to be stopped.

See [Installing the IO modules](/dso-rtu/io-module-installation.md) for the full placement and cabling guidance. Note each module's IP address, port and Modbus slave ID, since you need them when adding the device on the platform.

### Wire the emergency stop

* Assign one or more relay outputs to each emergency-stop action you want to enforce (production and/or consumption). Several outputs can act on the same action, useful to stop multiple assets or cabinets at once.
* Wire each relay into the emergency-stop / EPO input of the asset it has to stop.
* How a stop maps to the relay depends on the **relay actuation mode** you choose per output (normally open / normally closed and what the closed contact means). The contacts can be wired so that an active stop **energizes** or **de-energizes** the relay (see *Behaviour*).

### Configure the IO module on the platform

**1. Add the IO module as a device**

* Device type: **IO Extension**
* Brand: **Moxa**, model: **ioLogik E1214**
* Connection: **Modbus TCP/IP**, with the module's IP address, port and slave ID.

**2. Assign the emergency-stop output(s)**

Open the device's **Ports** page (or **Project settings → Telecontrol**) and, for each relay output (DO) you wired, set its function to **Telecontrol emergency switch** and choose:

* **Action**: *Injection* (driven by *emergency stop production*) or *Consumption* (driven by *emergency stop consumption*).
* **Relay actuation mode**: how the contacts are wired (normally open / normally closed) and what the closed contact means. This determines whether an active stop energizes or de-energizes the relay (see *Behaviour*).

You can assign **multiple outputs to the same action** (for example one per cabinet), each with its own actuation mode, and you can configure only the action you need.

The configuration is delivered to the EMS controller automatically as part of the project configuration; no manual controller changes are needed.

### Behaviour

An **Injection** output acts on *emergency stop production*; a **Consumption** output acts on *emergency stop consumption*. When the relevant stop is **active**, the EMS commands the asset OFF; when it is **cleared**, the asset is allowed to run. The **relay actuation mode** translates that into the digital-output value, so the relay can be wired either way:

| Relay actuation mode                                                   | Relay on **active** stop | Relay when **cleared** |
| ---------------------------------------------------------------------- | ------------------------ | ---------------------- |
| `NO-ON`: NO contacts, on when closed (default) → *de-energize to stop* | De-energized (open, 0)   | Energized (closed, 1)  |
| `NC-OFF`: NC contacts, off when closed → *de-energize to stop*         | De-energized (0)         | Energized (1)          |
| `NO-OFF`: NO contacts, off when closed → *energize to stop*            | Energized (closed, 1)    | De-energized (open, 0) |
| `NC-ON`: NC contacts, on when closed → *energize to stop*              | Energized (1)            | De-energized (0)       |

The relay state is re-evaluated every control cycle (≈ 1 second), so it follows the DSO RTU state with sub-second latency. When several outputs are mapped to the same action they are all driven together. Outputs that are **not** assigned as a telecontrol emergency switch are unaffected and remain available for other uses.

### Triggering an emergency stop (digital input)

A **trigger** is a digital input (DI) wired to a physical contact — a stop button, safety relay, protection contact — that switches an emergency stop on. It's an extra way to start the same emergency stop the grid operator sends: the emergency stop is on if **either** the grid operator **or** any trigger calls for it. You can add several triggers to one emergency stop (production or consumption); any one of them is enough.

Wire it "the quiet way round": the emergency stop turns **on when the input goes low**. So the contact should hold the input **high** in normal operation and **pull it low** for an emergency stop (e.g. a normally-closed contact that opens).

{% hint style="danger" %}
**If the IO module can't be reached, its triggers do nothing.** A "low" reading only counts as an emergency stop when the EMS has actually read it from a reachable, healthy module — otherwise an offline or not-yet-read input (which also looks low) could trip the installation by mistake. So one lost connection never starts an emergency stop on its own; the emergency stop stays as set by the grid operator and any working triggers.
{% endhint %}

**To set one up:** in **Project settings → Telecontrol**, open the emergency stop you want and, under **Triggers**, add the **IO extension device** and its **input port** (set as a Digital Input). **Fluvius** is always there as a built-in trigger and can't be removed.

### Safety and requirements

{% hint style="danger" %}
**Choose the actuation mode with power/communication loss in mind.** With a *de-energize-to-stop* mode (the default), the relay drops out when the controller or the Modbus link fails, which drives the installation to its stop state, the failsafe choice.

With an *energize-to-stop* mode the relay must be actively energized to stop, so a controller failure or broken link cannot enforce the stop on its own. In that case configure the **Moxa Communication Watchdog** (in the module's web console) so the relay is driven to its **safe (stop) state** on communication loss. The watchdog, not the EMS logic, is the safeguard there.
{% endhint %}

{% hint style="warning" %}
The IO module must be in **managed** mode. A module set to *unmanaged* is only read, never written, so its outputs will not be actuated.
{% endhint %}

### Monitoring and troubleshooting

If a DSO RTU emergency stop is **active** but the EMS cannot actuate the configured output (for example the module is offline or its relay state cannot be read back), a **critical incident** is raised. It clears automatically once the module is reachable again and the output is confirmed.

If you see this incident:

* Check network connectivity to the IO module (IP, port, slave ID).
* Verify the module is powered and reachable over Modbus TCP.
* Confirm the module is configured as **managed**.

Voltmasters tests the hardware emergency stop end to end during [commissioning](/dso-rtu/commissioning-and-certification.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.voltmasters.io/dso-rtu/io-module-emergency-stop.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.