The Problem
Writing configuration parameters to SEL protective relays via Modbus can brick the relay. Not crash it temporarily — brick it. When this happens, the relay becomes completely unresponsive and requires a full firmware reflash via direct serial connection using SEL’s AcSELerator software to recover. On a live site, that means the protective relay is offline, the equipment it’s guarding has no relay protection, and someone needs to get on site with the right tools and cable to bring it back.
Why It Bricks
SEL relay firmware does not handle unsolicited Modbus write commands to configuration registers the way you’d expect. Instead of rejecting the write or applying it gracefully, the firmware enters a faulted state it cannot recover from through normal communication. The relay stops responding to all Modbus traffic, front panel interaction becomes unresponsive, and the only path back is a firmware reflash.
This is a firmware-level bug, not a configuration error on your end. The relay simply cannot process a Modbus write to certain registers without corrupting its own operating state.
GE Multilin — No Issue
For comparison, GE Multilin relays handle Modbus configuration writes without this problem. You can read and write registers via Modbus as expected. This makes the SEL behavior particularly dangerous — if your team has worked with GE Multilin relays and assumes the same Modbus behavior applies to SEL, they’ll brick a relay the first time they try it.
How It Happens in Practice
The most common scenarios:
- PLC Modbus master with write-enabled function blocks — The PLC is polling the SEL relay for metering data (voltage, current, power) using Modbus read commands. Someone adds a write block to push a setpoint or configuration change. The relay bricks on the first write.
- SCADA configuration push — The SCADA system is configured to write relay settings as part of a batch configuration update. Works fine on the GE Multilin relays in the same system. Bricks every SEL relay it touches.
- Commissioning tool with write access — A Modbus testing tool or commissioning utility sends a write command during troubleshooting. The engineer is verifying communication and doesn’t realize the write will destroy the relay’s firmware state.
What You Should Do
- Modbus to SEL relays must be read-only. Full stop. Use Modbus for metering, status, and event data. Do not write to configuration registers.
- All configuration changes to SEL relays must go through AcSELerator via direct serial or Ethernet connection — never through the PLC or SCADA Modbus interface.
- Audit your PLC Modbus blocks. If you have function blocks pointing at SEL relays, verify they are read-only (FC 03/04, not FC 06/16). If any write blocks exist, disable or remove them.
- Audit your SCADA poll lists. Ensure SEL relay addresses only appear in read poll groups, not write groups.
- Document this in your project standards so it doesn’t get rediscovered the hard way on the next project. Include it in commissioning checklists as a verification item.
- Label it in your PLC program. Add a comment on every Modbus block communicating with an SEL relay: “READ ONLY — DO NOT ADD WRITE REGISTERS — SEL firmware will brick.”
The Bottom Line
Until SEL releases a firmware update that handles Modbus writes without self-destructing, treat every Modbus connection to an SEL relay as strictly read-only. One accidental write command can take a protective relay offline and leave critical equipment unprotected until someone can get on site to reflash it. That’s not a recoverable error — it’s an outage.