Modul LOGO für die Mikrosteuerung Siemens Logo 7/8

[John]

Hallo Thomas,
besten Dank für die Rückmeldung.

habe Dein Modul mal probiert. Installation auf Cubietruck (ARM7) nach Deiner Anleitung ohne Probleme

kannst du mir bitte alle  Dateien im Ordner "opt/fhem/build/john/build/arm_v7-linux" zusenden.
Wenn ich die übersetzten Libraries habe, wirds für die anderen User einfacher das ganze zu installieren.

Auf den Bereich 923-983 meiner Logo7 kann ich damit nur zugreifen, wenn ich eine Logo8 eingestellt habe.

Richtig, ich begrenze den Zugriff auf 899.

V923.0 erreichst du über den Area Code I1

define BRENNER_EIN LOGO_BINARY I1

Die analogen Areas sind jedoch noch nicht implementiert auch nicht die Netzwerk-basierten. (NI)

Könnte man mit Zugriff über Port 10001 "nachbilden", zumindest wenn man nicht gleichzeitig mit LogoSoftComfort in der Logo drin ist.

Das ist ein anderes Protokoll, hast zu dazu mehr Informationen ?

Ich finde das mit dem polling ziemlich unschön - entweder man ist sparsam, kriegt Änderungen dann aber erst spät mit oder man pollt häufig, bremst aber FHEM an sich dann ganz schön aus

Du musst nicht sparsam sein.

A. Das Modul optimiert den Zugriff und schafft i.d.R alle Datenbereiche mit einem einzigen Read-Request.
  Es nutzt dazu die MultiRead - Funktion des S7-Protokolls, in dem sich diskontinuierliche Bereiche mit einem einzigen Request erfassen lassen.

B. Eine Polling Sequenz dauert ca. 5..10 ms. Da muss FHEM ganz andere "Verzögerungen" in Kauf nehmen.
  Ich habe das ganze so geplant, daß man es auch in einem Thread auslagern kann.
  Aber als ich mit 5 ms konfrontiert war, habe ich darauf verzichtet.

Snap7 kann ja nun auch einen Server darstellen. Wäre es nicht möglich dieses feature zu nutzen um sich von der Logo über Änderungen informieren zu lassen?

Hab mir das Teil vor einiger Zeit angesehen und Instabilitäten festgestellt. Mag sein daß das nun behoben ist.
Mit dem Client habe ich jedoch sehr gute Erfahrungen gemacht.
Möglich ist das allemal, wäre aber dann auch ein neues Modul.

Auch das ist ein spannendes Projekt
http://sourceforge.net/projects/settimino/
damit könnten Arduino-Daten direkt in der Logo landen, ohne Vermittlung von FHEM.

John

[thmarx]

Die Dateien sind im Anhang.

V923.0 erreichst du über den Area Code I1

Schon klar. Aber wie greife ich auf AnalogMerker16.Bit1 zu? (Beispiel) Ich meine, man sollte die Möglichkeiten nicht unnötig einschränken.

... Könnte man mit Zugriff über Port 10001 "nachbilden", zumindest wenn man nicht gleichzeitig mit LogoSoftComfort in der Logo drin ist.

Das ist ein anderes Protokoll, hast zu dazu mehr Informationen ?

Ein paar. Das ist der Port, über den LogoSoftComfort mit der Logo kommuniziert. Wenn man an den Port die Zeichenkette "\x55\x17\x17\xAA" schickt, kommt entweder "\x06\x01" (running) oder "\x06\x02" (stopped) zurück. Der String "\x55\x18\x18\xAA" schaltet in run, der String "\x55\x12\x12\xAA" in stop. Mit "\x55\x19\x19\xAA" kriegt man (unter anderem) den gesamten E/A-Bereich zurück (zumindest bei der 0BA7). Mit der letzten Funktion logge ich bisher meine Logo...

Zum polling:
Ich finde halt unter Umständen schon 1 Sekunde recht langsam. Wenn ich auf einen Tastendruck reagieren will kann eine Sekunde (oder im Worst case auch 2 Sekunden, wenn der "Sensor" an Logo1 und der "Aktuator" an Logo2 hängen und FHEM dazwischen ist) schon spürbar zu lange sein und dadurch für Verwirrung / Unsicherheit beim Nutzer führen.

Gruß
Thomas

[John]

Hallo Thomas,
dank dir für die Dateien, werde das im nächsten Setup berücksichtigen.

Schon klar. Aber wie greife ich auf AnalogMerker16.Bit1 zu? (Beispiel) Ich meine, man sollte die Möglichkeiten nicht unnötig einschränken.

Ich werde in der nächsten Version den kompletten V Bereich freigeben.

Ein paar. Das ist der Port, über den LogoSoftComfort mit der Logo kommuniziert. Wenn man an den Port die Zeichenkette "\x55\x17\x17\xAA" schickt, kommt entweder "\x06\x01" (running) oder "\x06\x02" (stopped) zurück. Der String "\x55\x18\x18\xAA" schaltet in run, der String "\x55\x12\x12\xAA" in stop. Mit "\x55\x19\x19\xAA" kriegt man (unter anderem) den gesamten E/A-Bereich zurück (zumindest bei der 0BA7). Mit der letzten Funktion logge ich bisher meine Logo...

Ich hab einige Beträge vorher den Workaround mit dem Merker beschrieben. Damit kann man jetzt schon den RUN/Stop Zustand ermitteln.
Der Port 10001 ist für die IDE gedacht und nur 1x verfügbar. Ist das wirklich sinnvoll ?

Ich finde halt unter Umständen schon 1 Sekunde recht langsam. Wenn ich auf einen Tastendruck reagieren will kann eine Sekunde (oder im Worst case auch 2 Sekunden, wenn der "Sensor" an Logo1 und der "Aktuator" an Logo2 hängen und FHEM dazwischen ist) schon spürbar zu lange sein und dadurch für Verwirrung / Unsicherheit beim Nutzer führen.

Was würdest du denn für sinnvoll erachten ?
Ist das nicht ein Thema, das die Logos unter sich ausmachen können ?

John

[thmarx]

Hallo John,

dank dir für die Dateien

Gerne!

Der Port 10001 ist für die IDE gedacht und nur 1x verfügbar. Ist das wirklich sinnvoll ?

Ich sag ja auch erstmal nur, dass man "könnte". Zumindest darf man den Port nicht blockieren, also dauerhaft öffnen. Ich kann mir allerdings durchaus Szenarien vorstellen wo es vorteilhaft ist, schnell mal aus der Ferne die Logo auf STOP zu stellen ohne die IDE bei der Hand zu haben.

Was würdest du denn für sinnvoll erachten ?
Ist das nicht ein Thema, das die Logos unter sich ausmachen können ?

Sinnvoll ist m.M.n. "je schneller je besser". Sicher können das LOGOs unter sich aus machen. Geht aber nicht immer. (Bsp.: Ich plane als nächstes eine Logo zur Rolladensteuerung, hab da so ein nettes Logoprg. gefunden mit Beschattung nach Bedarf, Lüftung nach Bedarf usw. Da soll FHEM als übergeordnete Instanz dienen und u.a. auf einen Funk-Taster reagieren. Der stellt auch eine "Doppelklick"-Funktion zur Verfügung, hat also schon prinzipbedingt eine Verzögerung bis die Info 1x/2x geklickt bei FHEM ankommt. Jetzt noch die Verzögerung zur Logo dazu, dann sind wir schon in einem Bereich bei dem der Nutzer denkt "habe einmal gedrückt, es passiert aber nichts")

Naja, sind ja erst mal nur so ein paar Ideen von mir. Mach weiter mit der guten Arbeit.

Gruss
Thomas

[John]

Der stellt auch eine "Doppelklick"-Funktion zur Verfügung, hat also schon prinzipbedingt eine Verzögerung bis die Info 1x/2x geklickt bei FHEM ankommt. Jetzt noch die Verzögerung zur Logo dazu, dann sind wir schon in einem Bereich bei dem der Nutzer denkt "habe einmal gedrückt, es passiert aber nichts")

In diesem Fall müsste die Information möglichst schnell in die Logo geschrieben werden.
Da kann ich mir eine Art "writeFast" vorstellen, was die Daten umgehend an die Logo sendet, um die Latenzzeiten zu minimieren.

John

[John]

Man kann das Modul auch dazu verwenden an eine S7 zu koppeln.

Im Wiki sind hierzu Details nachzulesen.
http://www.fhemwiki.de/wiki/LOGO_-_Das_Logikmodul#Kann_man_mit_dem_Modul_auch_auf_eine_S7_zugreifen_.3F

Ich habe dies mit einem S7-Simulator (mangels eigener Hardware) getestet.

Vielleicht findet sich jemand, der dies an einer echten S7 bestätigen kann.


John

[John]

Das noch fehlende Modul LOGO_ANALOG ist nun integriert.

Das Wiki wurde entsprechend erweitert.

http://www.fhemwiki.de/wiki/LOGO_-_Das_Logikmodul#Define_f.C3.BCr_einen_analogen_Datenpunkt

Anbei noch die Darstellung zum neuen Modul.

John

[thmarx]

Hier die fehlenden Dateien für ARM7

Gruß
Thomas

[John]

Dank der Zuarbeit von Thomas, nun die neue Logo.tar.gz, die auch auf dem Cubietruck einfach zu installieren ist.
John

[John]

Mein LOGO-Projekt ist nun abgeschlossen. Mit den Ergebnissen bin ich zufrieden.

Probleme:

• A. während der Lade-Phase für den Warmwasserspeicher wurde die Pumpe für den Heizkreislauf inaktiv.
  Dies führte zu einer unangenehmen Absenkung der Raumtemperatur vor allem an kalten Tagen
• B. Zu viele Brenner-Starts

Lösung:
Lade-Pumpe (LP), wie auch Heizkreispumpe (HKP) werden nicht mehr direkt von der Brenner-Steuerung angesteuert, sondern über die LOGO!8.

Diese bedient sich im wesentlichen folgender Signale der Brennersteuerung:
* Steuersignal Ladepumpe
* Steuersignal Heizkreispumpe
* Meldesignal Brenner-EIN

Ergebnis:

Problem A konnte durch pulsierenden Betrieb von HKP während der Lade-Phase des Brauchwasserspeichers gut gelöst werden.
Dies führt automatisch zu einer Verbesserung von Problem B, da nun die Ladephase deutlich länger dauert.

Durch permanente Aktivierung der Ladepumpe wird das im Heizkreislauf zirkulierende Wasservolumen erhöht,
so daß diese Maßnahme wie ein kleiner Pufferspeicher wirkt. Eine Abkühlung des Brauchwasserspeichers konnte ich nicht feststellen.

Nach der bisherigen Beobachung sind damit die Starts des Brenner qualitativ halbiert worden.

Im Anhang noch einige Bilder zum Projekt:
Im ersten Bild die Online-Darstellung der LOGO innerhalb der Entwicklungsumgebung. Rote Linien bezeichnen Pfade, die logisch TRUE sind.

Im zweiten Bild ein Überblick der Datenpunkte in FHEM und die Logik-Darstellung im Chart.

John

[thmarx]

Hallo John,

A. während der Lade-Phase für den Warmwasserspeicher wurde die Pumpe für den Heizkreislauf inaktiv.

Diese feature hat meine Steuerung auch. Nennt sich "Kesselanfahrentlastung" und soll bewirken, dass der kritische Temperaturbereich mit Abgaskondensation im Brennraum möglichst rasch durchfahren wird. (Bei Erdgas bis 55°C, Flüssiggas 51°C, Heizöl 47°C). Hoffentlich gammelt Dir der Kessel/Brennraum nicht vorzeitig weg...

Zum Modul:
Gute Arbeit! Läuft bei mir bisher ohne Probleme. Vielen Dank dafür!

Gruss
Thomas

[John]

Hallo Thomas,

Diese feature hat meine Steuerung auch. Nennt sich "Kesselanfahrentlastung" und soll bewirken, dass der kritische Temperaturbereich mit Abgaskondensation im Brennraum möglichst rasch durchfahren wird.

Man kann optional auch das Gegenteil in der Brennersteuerung einstellen, nämlich daß die Heizkreispumpe auch während des Ladevorgangs nicht abschaltet, daher gehe ich davon aus daß das Pulsieren unschädlich ist.

Die Anwahl der Option hat den Nachteil, daß die Max-Thermostatventile sporadisch eine sehr hohe Vorlauftemperatur verkraften müßten, was denen gar nicht "schmeckt" (adaptive Regelung ist verwirrt), das Laden des Speichers braucht eine Ewigkeit und die Räume überhitzen.

..Läuft bei mir bisher ohne Probleme.

Das ist auch meine Erfahrung. Hab beim Umbau der Heizung das Modul LOGO arg gestresst, da ich ja die Heizung immer wieder stromlos schalten mußte.
Das Modul hat klaglos alles mitgemacht. Ich hab ein gutes Gefühl damit.

John

[goerdi]

Hi John !

einen "feature request" haette ich da noch... wie im thread bereits angesprochen waere es nicht schlecht wenn die writes sofort ausgefuehrt werden wuerden (wenn z.B. Lich oder Rollos damit angesteuert werden)
evtl. hast du noch die muse das zu implementieren...

gruss gerd

[John]

Hallo Gerd,
du hast wohl noch eine alte Version.

Für alle 3 Module ist Version 1.01 die aktuelle.
Das Feature ist schon implementiert.

John

[goerdi]

Hi  !

Sry das hatte ich verpeilt.... grad getestet.... ich hatte noch ein 2tes Fhem am laufen das hat anscheinend die Logo durcheinander gebracht...

Gruss Gerd