WAGO 750-880: Warum Rollladenfahrten Lichter zum Flackern bringen

Ein Aktor schaltet – und irgendwo im Haus flackert ein völlig unabhängiger Lichtkreis mit. Kein Muster nach Uhrzeit, keine Korrelation mit der Netzlast, kein Zusammenhang mit einer bestimmten Gruppe. Nur: Rollladen bewegt sich, Licht flackert.

Genau dieses Symptom trat in einem Smart-Home-Projekt mit einem WAGO 750-880 auf, das Basic4web in Kärnten betreut. Die Ursache lag am Ende nicht in der Elektrik, sondern in einer Adresskollision im Speicher der Steuerung – ein Fehlerbild, das auf jeder WAGO-750-Anlage mit gemischten Bit- und DWord-Variablen entstehen kann.

Was Sie in diesem Artikel erfahren:

• Warum sich WAGO-SPS-Programm und Modbus-Master denselben physischen Speicher teilen
• Wieso eine 32-Bit-Positionsvariable (%MD) unbemerkt Licht-Bits (%MX) überschreiben kann
• Wie man die Kollision anhand der WAGO-Adressierungsformel selbst nachrechnet
• Die konkrete Lösung: Adressbereiche sauber trennen, ohne die SPS-Logik anzufassen

---

Das Symptom: Wenn der Rollladen das Licht mitreißt

Alle Raffstores liefen über eine SPS-Anwendung auf einem WAGO 750-880 (ETHERNET Programmable Fieldbus Controller), gesteuert wahlweise über physische Taster an der Wand oder über Home Assistant per Modbus/TCP. Sobald bestimmte Raffstores fuhren – egal ob per Taster oder per Home-Assistant-Befehl –, flackerten mehrere, scheinbar unzusammenhängende Lichtkreise kurz mit.

Die erste Vermutung ging in Richtung Elektrik: induktive Störungen beim Anlaufen der Rollladenmotoren, Spannungseinbrüche, ein möglicher Massefehler. Nach Ausschluss dieser Hypothesen – kein Zusammenhang mit der Last, keine Auffälligkeiten am Netzteil, Fehler auch bei einzelnen, isolierten Fahrten reproduzierbar – blieb als nächster Verdächtiger die Feldbus-Ebene: eine Adress- oder Speicherkollision im Controller selbst.

Ein Fehler, der bei jeder Bewegung auftritt, deutet eher auf eine strukturelle Adressursache hin als auf eine zeitkritische Race Condition. Das war der entscheidende Hinweis, die Suche vom Kommunikationsprotokoll weg und hin zum gemeinsam genutzten SPS-Speicher zu verlagern.

---

Der Verdächtige: Ein geteilter Speicher auf dem WAGO 750-880

Der 750-880 ist kein reiner Modbus-Koppler, sondern ein vollwertiger, mit IEC 61131-3 (CoDeSys 2.3) programmierbarer Feldbuscontroller. Er führt eigenständig ein Anwenderprogramm aus und stellt gleichzeitig über Modbus/TCP eine Schnittstelle nach außen bereit, über die Home Assistant lesen und schreiben kann. Beide Welten – SPS-Programm und Modbus-Master – teilen sich denselben physischen Speicher.

Genau dieses geteilte Speichermodell ist im WAGO-Handbuch zum 750-880 detailliert beschrieben, wird in der Praxis aber leicht unterschätzt – vor allem, wenn man mit Merkervariablen (%MX/%MW/%MD) statt mit direkt zugeordneten I/O-Adressen arbeitet. Relevant sind zwei Adressräume:

• Bit-Zugriff (Modbus-Funktionscodes 1/2/5/15): Der Bereich ist dem NOVRAM-Retain-Speicher zugeordnet und wird als %MX0.0 … %MX1279.15 adressiert
• Wort-Zugriff (Funktionscodes 3/4/6/16/23): Derselbe physische Speicher erscheint hier als %MW0…%MW12287

Zwei unterschiedliche Modbus-Funktionscodes greifen also auf denselben RAM-Bereich zu – nur mit unterschiedlicher Granularität. Das ist für sich genommen kein Problem, solange klar ist, dass Bit- und Wortadressierung im selben Speicher landen.

Wer eine WAGO-Steuerung generell erst für Home Assistant erschließen möchte, findet den Einstieg im Artikel WAGO Modbus & Home Assistant: Maschinendaten in Kärnten sichtbar machen. Eine konkrete Schritt-für-Schritt-Anleitung für Raffstore-Antriebe liefert die Praxis-Anleitung WAGO Raffstore-Steuerung mit Modbus in Home Assistant einbinden.

Wenn Sie wissen möchten, ob Ihre eigene WAGO-Anlage in Kärnten von einer ähnlichen Adresskollision betroffen sein könnte, helfen wir weiter: Smart-Home- und IoT-Beratung in Kärnten

---

Die Falle: Warum %MD kein eigener Adressraum ist

Neben %MX (Bit) und %MW (16-Bit-Wort) kennt CoDeSys auf der WAGO-750-Plattform noch %MD für 32-Bit-Werte (REAL, DWORD). Entscheidend – und leicht zu übersehen – ist, wie sich diese Adresse aus der Wortadresse ableitet:

%MDn  →  belegt Wort [2n , 2n+1]

%MD1 liegt also nicht „hinter” %MX1, sondern belegt exakt Wort 2 und Wort 3 – weil ein 32-Bit-Wert zwei 16-Bit-Worte braucht und die DWord-Nummerierung entsprechend nur halb so schnell hochzählt wie die Wortadressen. Der Modbus-Coil-Adressenrechner von Basic4web rechnet diese Umrechnung automatisch durch, wenn Sie eine eigene Anlage prüfen möchten.

Genau hier lag der Fehler in der globalen Variablenliste GVL_HomeAssistant, über die Home Assistant per Modbus mit der SPS kommunizierte:

Variable	Adresse	belegt Wort
HA_OG_Zimmer_Sued_Kl_Pos	%MD1	2, 3
HA_OG_Zimmer_Sued_gr_Pos	%MD2	4, 5
(alle Licht-Toggle/Status-Bits)	%MX2.x … %MX4.x	2, 3, 4

Auf den ersten Blick wirkte die Liste sauber: Auf/Ab-Bits in Wort 0/1, Positionswerte ab %MD1, Lichter ab %MX2. Rechnet man die %MD-Adressen aber gemäß obiger Formel in Wortadressen um, liegen %MD1 und %MD2 exakt auf denselben Worten wie so gut wie alle Licht-Flags.

Jedes Mal, wenn die REAL-Position eines Raffstores geschrieben wurde, überschrieb der Controller intern das komplette 32-Bit-Wort – und damit alle 16 Bits, die dort zufällig als Licht-Bits deklariert waren. Nicht als seltener Zufallstreffer, sondern als strukturelle Eigenschaft der Adressierung, reproduzierbar bei jeder einzelnen Fahrt.

---

Warum der Fehler auch am physischen Taster auftrat

Ein wichtiger Punkt bei der Eingrenzung: Der Fehler trat nicht nur bei Steuerung über Home Assistant auf, sondern genauso bei Bedienung über die Wandtaster – obwohl die Taster-Betätigung nicht über Modbus läuft. Der Blick in den CFC-Baustein (Continuous Function Chart) der Raffstore-Logik klärte das auf:

DI_M5_05 (physischer Taster)      ─┐
                                     OR ──► Up-Eingang FbSunblind_2
HA_OG_Zimmer_Sued_Kl_Up (%MX0.1)  ─┘

HA_OG_Zimmer_Sued_Kl_Pos (%MD1) ───────────► Pos-Eingang derselben Instanz

Taster-Signal und Modbus-Bit werden über ein einfaches OR-Gatter zusammengeführt und steuern dieselbe Funktionsbausteininstanz. Die Positionsvariable hängt direkt an dieser Instanz und wird während der Fahrt laufend aktualisiert, damit Home Assistant den Öffnungsgrad live anzeigen kann – unabhängig davon, wer die Fahrt ausgelöst hat. Der Auslöser war also nie relevant; die Kollision passierte eine Ebene tiefer, im Speicher selbst.

Wie sich eine Registerbelegung auch ganz ohne Herstellerdokumentation zuverlässig nachweisen lässt, zeigt der Artikel Modbus-Register ohne Herstellerdokumentation reverse-engineeren – dieselbe Sorgfalt bei der Adressanalyse, nur für den umgekehrten Fall einer unbekannten statt einer selbst angelegten Registerkarte.

---

Die Lösung: Adressbereiche sauber trennen

Der Fix war konzeptionell einfach, sobald die Ursache klar war: Bit-Bereich (Auf/Ab-Taster, Licht-Toggle/Status) und Wort-Bereich (REAL-Positionswerte) dürfen sich keine Worte teilen. Die 30 %MD-Variablen wurden um 9 Indizes verschoben:

%MD1  … %MD30   →   %MD10 … %MD39

Damit landen sie ab Wort 20 – weit außerhalb der genutzten %MX0…%MX4 (Wort 0–4), mit ausreichend Puffer für künftige Lichtkreise.

Da CoDeSys-Programme Variablen über ihren symbolischen Namen referenzieren, musste die eigentliche Programmlogik an keiner Stelle angefasst werden – nur die AT-Bindung in der GVL. Auf der Modbus-Seite sieht das anders aus: Home Assistant kennt keine Symbolnamen, sondern ausschließlich rohe Registeradressen. Jede der 30 Positions-Entities musste also mit der neuen Adresse aktualisiert werden, nach der Formel:

Registeradresse = 12288 + 2 × MD-Index

Eine Verschiebung um +9 im MD-Index entspricht dabei einer Verschiebung um +18 in der Modbus-Registeradresse.

Drei Punkte, die sich auf jedes WAGO-750-Projekt mit gemischten Bit- und DWord-Variablen übertragen lassen:

1. %MX, %MW und %MD sind keine getrennten Adressräume, sondern drei Sichten auf denselben physischen Speicher
2. Beim Anlegen einer GVL immer in belegten Wortadressen rechnen, nicht in Variablentypen
3. Ausreichend Puffer zwischen funktional unabhängigen Gruppen einplanen – für künftige Erweiterungen ebenso wie zur Fehlervermeidung

Eine technische Einordnung zu Modbus im Industrieumfeld liefert das Modbus-Organisationskomitee (modbus.org), Details zur Programmierumgebung die CODESYS-Projektseite.

---

Fazit: Was WAGO-Projekte in Kärnten aus dieser Adresskollision lernen können

Am Ende war es kein Software-Bug, sondern eine Adresskollision aus der Kombination zweier für sich genommener plausibler Entscheidungen: Bit-Variablen ab %MX2, DWord-Variablen ab %MD1 – beide sinnvoll gewählt, in Kombination aber überlappend. Die Praxis zeigt, dass genau solche Kollisionen leicht übersehen werden, weil man beim Anlegen einer Variablenliste selten in „belegten Worten” denkt, sondern in Namen und Typen.

Wer eine ähnliche Symptomatik beobachtet – ein Aktor „reißt” beim Schalten andere Kanäle mit, unabhängig vom Auslöser – sollte als Erstes die Speicherbelegung aller AT-gebundenen Variablen in Wortadressen umrechnen und auf Überlappungen prüfen. In den meisten Fällen liegt die Antwort nicht in der Elektrik, sondern im Adressplan.

Dieser Beitrag richtet sich an Haustechnik-Verantwortliche, SPS-Programmierer und Smart-Home-Integratoren in Kärnten, die WAGO-750-Controller mit Home Assistant kombinieren. Basic4web unterstützt bei der Analyse und Bereinigung solcher Adresskollisionen – nehmen Sie Kontakt auf, wir prüfen Ihre Merkerbelegung und zeigen den nächsten Schritt.