LOGOs vernetzen (Master/Master)

Achtung: teilweise veraltet!
Dieser Artikel wurde zu einem Zeitpunkt verfasst, als es noch keine LOGO 8 gab und LogoSoft v7 die aktuellste Version der Programmiersoftware war. Daher sind Teile dieses Artikels nicht nicht mehr ganz aktuell. Für eine LOGO 7 würde ich weiterhin die hier propagierte Client-Server-Architektur empfehlen, für die LOGO 8 hingegen müsste die Situation neu bewertet werden. Mit der LOGO 8 und LogoSoft v8 hat Siemens einige neue Funktionen eingeführt, die Vernetzung und Datenaustausch zwischen mehreren Logo8 deutlich vereinfachen. Eine Sache bleibt jedoch: Finger weg vom Master-Slave-Modus! Mit den neuen vereinfachten Netzwerkfunktionen der LOGO 8 fällt das Argument, dass Master-Master zu kompliziert wäre, endgültig weg.

Bei mir zu Hause sind aktuell 4 LOGOs 0ba7 in den Unterverteilern der verschiedenen Stockwerke (1xDG, 2xEG, 1xUG) verbaut. Dank Ethernet-Schnittstelle können diese miteinander kommunizieren. Dies nutze ich z.B. für die Alle-Rollos-Runter-Funktion oder ganz einfach um das Flurlicht im DG von der Treppe im EG (zwei verschiedene LOGOs) einzuschalten. Die LOGO bietet 2 Arten der Kommunikation: Master/Slave und Master/Master. Bei ersterer läuft nur auf der Master-LOGO ein Programm und die Ein-/Ausgänge der Slaves werden einfach mitbenutzt. Das hört sich zwar zunächst recht einfach an, bedeutet jedoch auch, dass das ganze Schaltprogramm max. 400 Blöcke umfassen darf (die Slaves bleiben ja dumm). Außerdem gab es bei mir Probleme, dass ein Tastimpuls an den Eingängen der Slaves nicht zum Master übertragen wurde, wenn der Taster nicht mindestens 150ms gedrückt wurde. Ein KO-Kriterium für mein Hausautomatisierungs-Projekt.

Bei der Master/Master-Kommunikation darf dagegen jede LOGO ihr eigenes Programm abarbeiten und damit jeweils bis zu 400 Blocke verbrauchen. Weiterhin kann so z.B. der Tastimpuls künstlich verlängert werden, damit er lange genug für die Netzwerkkommunikation anliegt. Prinzipiell rate ich jedem sich mit der Master/Master-Kommunikation auseinanderzusetzen, da sie deutlich mehr Flexibilität bietet.

Leider wird die Konfiguration relativ schnell kompliziert, wenn man mehr als 2 LOGOs betreibt und alle mit allen kommunizieren können sollen. Dann müssen auf jeder LOGO mehrere Server und Client-Verbindungen eingerichtet werden und für jede Logo die Schreib-/Leseoperationen der einzelnen Speicherbereiche der anderen LOGOs koordiniert werden. Ich habe bei dieser Über-Kreuz-Kommunikation schnell den Überblick verloren, so dass nach bereits kleinsten Änderungen nichts mehr funktionierte. Die Fehlersuche gestaltete sich dann so Zeitaufwendig, dass ich entschloss nochmal von Grund auf anzufangen und mir ein klares Konzept für die Speicherbelegung zu definieren. Dieses möchte ihr hier vorstellen. Ich behaupte nicht, dass dies die ultimative Lösung ist und es keinen besseren Weg gibt, aber für meine Zwecke hat dies alle Probleme gelöst.

Client-Server

Grundidee ist, dass keine Über-Kreuz-Kommunikation mehr stattfinden darf. Eine der LOGOs wird zum Server ernannt und alle anderen kommunizieren nicht mehr direkt miteinander sondern nur noch über diese Server-LOGO. Dies verlängert natürlich die Signallaufzeiten im Worst-Case um das doppelte, allerdings fand ich das immer noch ausreichend schnell. Der Vorteil ist jedoch, dass es nun eine zentrale Stelle gibt, an der alle Fäden zusammen laufen, die den Status aller Ausgänge/Merker… aller Clients kennt und diese auf Anfrage an andere Clients weitergibt.

Ich habe die Logos durchnummeriert in 1, 2, 3 und 4 und auch die IP-Adressen nach dem Muster benannt (bei mir fangen die manuellen IPs ab x.x.x.200 an, somit haben alle Logos die IPs x.x.x.201-204. Die Logo 1 habe ich zum Server erklärt. Die Logos 2-4 schreiben als Client den Wert ihrer jeweiligen Ausgänge und Merker alle auf die Logo 1 ab Adresse VBx00 wobei x für die Logo-Nummer steht, also VB200 (Logo 2), VB300 (Logo 3), VB400 (Logo 4). Dabei stehen alle Merker an VBx00-VBx03 und alle Ausgänge an VBx04-VBx05. Damit verfügt Logo 1 nun über alle Zustände von Logo 2-4. Die Eingänge habe ich bewusst nicht übertragen, da ich Taster an den Eingängen verwende und der Tast-Impuls nicht lange genug anliegt um übertragen zu werden. Ich muss den Tastimpuls also mit einer Ausschaltverzögerung verlängern und das Signal dann über einen Merker übertragen.

Nun lese ich auf den Logos 2-4 den Inhalt von VB200, VB300 und VB400 der Logo 1 aus und kopiere sie lokal an genau die gleiche Adresse VB200, VB300 und VB400. Zusätzlich lese ich noch die Ausgänge und Merker von Logo 1 (QB0-1 und MB0-3) und kopiere sie lokal an VB100 nach dem gleichen Muster.

Hier die Ethernet-Konfiguration aller LOGOs:

Der Vorteil ist, dass ich nun alle Merker und Ausgänge aller 4 Logos an allen 4 Logos verfügbar habe und zwar immer nach dem gleichen Adress-Schema:

VB100-103: Merker von LOGO 1
VB104-105: Ausgänge von LOGO 1

VB200-203: Merker von LOGO 2
VB204-205: Ausgänge von LOGO 2

VB300-303: Merker von LOGO 3
VB304-305: Ausgänge von LOGO 3

VB400-403: Merker von LOGO 4
VB404-405: Ausgänge von LOGO 4

Möchte nun also LOGO 2 einen Schaltbefehl an LOGO 4 senden, muss auf der LOGO 2 nichts anderes gemacht werden als irgendeinen Merker (z.B. Merker 15) zu setzen. Dieser steht dann auf der LOGO 4 im VM-Speicher unter VB201 Bit 6 zur Verfügung und kann ganz einfach mit einem Netzwerkeingang in die Schaltung integriert werden:

Netzwerkeingang